Re: [PATCH] 9p/xen: Use flexible array for data rings

[Rosen Penev]

On Sun, Sep 13, 2026 at 2:52 AM Dominique Martinet
<asmadeus@xxxxxxxxxxxxx> wrote:
>
> Jürgen Groß wrote on Wed, May 27, 2026 at 07:39:07AM +0200:
> > On 19.05.26 03:57, Rosen Penev wrote:
> > > Store the fixed set of Xen 9p data rings in the frontend private
> > > allocation instead of allocating a separate rings array.
> > >
> > > This keeps the data ring storage tied to the frontend lifetime and
> > > simplifies the allocation and cleanup paths.
> > >
> > > Assisted-by: Codex:GPT-5.5
> > > Signed-off-by: Rosen Penev <rosenp@xxxxxxxxx>
> > > ---
> > >   net/9p/trans_xen.c | 68 ++++++++++++++++++++--------------------------
> > >   1 file changed, 30 insertions(+), 38 deletions(-)
> > >
> > > diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> > > index f9fb2db7a066..5a110d71d18c 100644
> > > --- a/net/9p/trans_xen.c
> > > +++ b/net/9p/trans_xen.c
> > > @@ -55,7 +55,7 @@ struct xen_9pfs_front_priv {
> > >     char *tag;
> > >     struct p9_client *client;
> > > -   struct xen_9pfs_dataring *rings;
> > > +   struct xen_9pfs_dataring rings[];
> >
> > Any reason not to use rings[XEN_9PFS_NUM_RINGS] instead of a flex array?
>
> Rosen, do you intend to resend with this fixed number?
Sent
>
> Given that's just a two line diff from your patch (just changing the
> type and keeping kzalloc_obj instead of kzalloc_flex) I can do it myself
> but I also don't have any direct merit from it, so if I don't hear back
> I'll forget about this
> (unless Jürgen says he actually read the whole diff and it's worth
> taking for simplification, I don't have time...)
>
> Thanks,
> --
> Dominique Martinet | Asmadeus