Message-ID: <80c4e788-65df-4a82-8453-74683289abcb@collabora.com>
Date: Fri, 26 Jan 2024 20:47:22 +0100
From: Andrzej Pietrasiewicz <andrzej.p@...labora.com>
To: Dominique Martinet <asmadeus@...ewreck.org>,
 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

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?

Regards,

Andrzej


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

Powered by blists - more mailing lists