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

[Michael Grzeschik]

On Mon, Feb 19, 2024 at 09:13:03AM +0100, Greg Kroah-Hartman wrote:
> 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?

Because out of convenience and to make it just work as simple as
nfsrootfs. With this we now need to maintain an full initramfs,
that has to come from somewhere.

> > 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.

Hmm, okay.

> > 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".

When you mean this "soon" is in the near future, you are probably right
then.

> > > > +/*
> > > > + * 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.


Okay, What about the rest of the series? Can you just skip this patch
then for? Or do you want me to send the series again without this
legacy driver. There are no dependencies to this in that series.

Michael

--
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Attachment: signature.asc
Description: PGP signature