Hi,
W dniu 17.01.2024 o 11:54, Dominique Martinet pisze:
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?
Maybe dummy_hcd is what you want?
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)
Attachment:
signature.asc
Description: PGP signature