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
