Message-ID: <Zaex_fkKcui7QZd7@codewreck.org>
Date: Wed, 17 Jan 2024 19:54:53 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Jan Lübbe <jlu@...gutronix.de>
Cc: Michael Grzeschik <m.grzeschik@...gutronix.de>,
	Latchesar Ionkov <lucho@...kov.net>, linux-usb@...r.kernel.org,
	Jonathan Corbet <corbet@....net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	v9fs@...ts.linux.dev,
	Christian Schoenebeck <linux_oss@...debyte.com>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel@...gutronix.de, Eric Van Hensbergen <ericvh@...nel.org>
Subject: Re: [PATCH 0/3] usb: gadget: 9pfs transport

Jan Lübbe wrote on Tue, Jan 16, 2024 at 04:51:41PM +0100:
> > So I didn't have time to look at everything through, just want to make
> > sure, this series allows sharing data from an usb gadget (e.g. some
> > device with storage) over 9p as an alternative to things like MTP ?
> 
> It's the other way around. :) The USB host exports a filesystem, while the
> gadget on the USB device side makes it mountable. Our main use-case is to use it
> as an alternative to NFS root booting during the development of embedded Linux
> devices. NFS root works in many cases, but has some downsides, which make it
> cumbersome to use in more and more cases.

Oh!
Okay, this makes a lot more sense. And that'll need a bit more
explanations in the commits & Documentation/ as you've concluded :)


> NFS root needs correctly configured Ethernet interfaces on both the development
> host and the target device. On the target, this can interfere with the network
> configuration that is used for the normal device operation (DHCP client, ...).
> For the host, configuring a NFS (and perhaps DHCP) server can be an obstacle.
> 
> For target devices which don't have a real Ethernet interface, NFS root would
> also work with the USB Ethernet gadget, but this increases the complexity
> further.
> 
> As many embedded boards have a USB device port anyway, which is used during
> development for uploading the boot-loader and to flash filesystem images (i.e.
> via the fastboot protocol), we want to just reuse that single data cable to
> allow access to the root filesystem as well. 
> 
> Compared to flashing images, using a network filesystem like NFS and 9P reduces
> the time between compiling on the host and running the binary on the target, as
> no flash and reboot cycle is needed. That can get rid of many minutes of waiting
> over a day. :)

My other hat is on embedded development (dayjob at Atmark Techno[1], the
only english page linked is about 4 years out of date but I guess it's
better than no page at all), so I can understand where you're coming
from -- thanks for the background.

[1] https://www.atmark-techno.com/english

That means I'll actually want to test this, but kind of always busy so
it might take a few weeks...
Or better, do you happen to know if qemu can create a USB controller
that supports OTG so it'll be easy to test for folks with no such
hardware?
We've got enough 9p protocols that aren't actually tested on a regular
basis, it'd be great if we could have something that can run anywhere. 


> diod (9pfs server) and the forwarder are on the development host, where the root
> filesystem is actually stored. The gadget is initialized during boot (or later)
> on the embedded board. Then the forwarder will find it on the USB bus and start
> forwarding requests.
> 
> It may seem a bit unusual that in this case the requests come from the device
> and are handled by the host. The reason is that USB device ports are normally
> not available on PCs, so a connection in the other direction would not work.

Right, most host PCs won't have OTG available...
I was also perplexed by the linux foundation (0x1d6b):0x0109 id, that
might be clearer once it's properly documented -- I'll let someone from
the usb side chime on this as I have no idea what's appropriate.


> In the future, the functionality of the forwarder could be integrated into the
> 9pfs server. Alternatively, an improved forwarder could also react to udev
> events of gadgets showing up and forward them to different 9PFS server over the
> network (when you have multiple target devices connected to one USB host).

Plenty of potential work ahead :)
Frankly at this stage I don't think it's much simpler than e.g. CDC
ethernet gadget and mounting nfs over tcp, but with further improvements
it can definitely get simpler.


> Perhaps, the inverse setup (9PFS server on the USB gadget side, mounted on a PC)
> also would be useful in the future and could share some of this code. Then,
> you'd have an alternative to MTP.

(Yeah, I'm not actively looking for that -- was just asking because MTP
has been kind of dead lately and I'm not aware of any potential
alternative, but I didn't go looking for them either -- let's leave that
to later)

-- 
Dominique Martinet | Asmadeus

Powered by blists - more mailing lists