On Tue, 2024-01-16 at 20:45 +0900, Dominique Martinet wrote: > Michael Grzeschik wrote on Tue, Jan 16, 2024 at 02:49:40AM +0100: > > This series is adding support to mount 9pfs exported filesystems via the > > usb gadget interface. It also includes tools and descriptions on how to > > translate an tcp 9pfs and use it via the usb interface. > > 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. 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. :) > I don't quite understand what the forwarder and diod have to do with > this; you're emulating a fake usb device with the forwarder that just > transmits requests to diod as backend implementation? > But 'usb.core.find(idVendor=0x1D6B, idProduct=0x0109)' looks like it's > searching for a real device not creating one, so that doesn't seem to > match up... 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. 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). 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. > If you have any background information on where you're coming from and > where this is headed it'd be great to include in the cover letter. Yes. Probably also in Documentation/. Thanks, Jan
