Re: [PATCH v2 3/4] usb: gadget: legacy: add 9pfs multi gadget

[Greg Kroah-Hartman]

On Mon, Feb 19, 2024 at 02:48:43AM +0100, Michael Grzeschik wrote:
> On Sat, Feb 17, 2024 at 04:59:28PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Feb 02, 2024 at 01:05:12AM +0100, Michael Grzeschik wrote:
> > > Add the newly introduced 9pfs transport gadget interface with an new
> > > multi composed gadget together with acm and eem.
> > > 
> > > When using this legacy module, it is also possible to
> > > mount the 9PFS usb dir as root filesystem. Just follow the
> > > instrucitons from Documentation/filesystems/9p.rst
> > 
> > Why are we adding new "legacy" gadgets?  What's wrong with the "correct"
> > api instead?  You need a lot of justification here to add something to
> > an api we want to one day just delete.
> 
> Without the legacy gadget there is no real solution to mount
> the 9pfs via the gadget as rootfs. The "correct" api is configfs
> which will need the user to have some filesystem to mount it to.

That's what your initramfs is for.  Why can't you just use that?

> There is the relatively new concept of bootconfig which sounds
> promising to describe an complete configfs tree from system boot.

Great, but until that happens, again, just use initramfs.

> However this is some future talk for now, so we would like to
> stick with the legacy setup to be able to mount the 9pfs rootfs.

I'd prefer to NOT add new legacy gadget drivers, and do everything
possible to delete them all from the tree "soon".

> > > +/*
> > > + * Gadget usb9pfs only needs two bulk endpoints, and will use the usb9pfs usb
> > > + * transport to mount host filesystem via usb gadget. This driver will
> > > + * also add one ACM and NCM interface.
> > 
> > Why "also"?  What are those interfaces going to be used for and what do
> > they have to do with 9pfs?
> 
> They are not necessary to be used with 9pfs. But since we introduce an
> new legacy module which is fully claiming the UDC, it would make sense
> to leave the other endpoints unavailable but instead add some common
> interfaces like ecm and acm.

But if no one needs/wants them, why make this complex?  Again, configfs
can handle the composition of this if you need it, which is why that
"new" interface was created.

thanks,

greg k-h