From: Dominique Martinet <asmadeus@codewreck.org>
To: "Jan Lübbe" <jlu@pengutronix.de>
Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>,
Latchesar Ionkov <lucho@ionkov.net>,
linux-usb@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
v9fs@lists.linux.dev,
Christian Schoenebeck <linux_oss@crudebyte.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@pengutronix.de, Eric Van Hensbergen <ericvh@kernel.org>
Subject: Re: [PATCH 0/3] usb: gadget: 9pfs transport
Date: Wed, 17 Jan 2024 19:54:53 +0900 [thread overview]
Message-ID: <Zaex_fkKcui7QZd7@codewreck.org> (raw)
In-Reply-To: <0aba51a8be0fb165b44ec956bec7a9698a9518a2.camel@pengutronix.de>
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
next prev parent reply other threads:[~2024-01-17 10:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 1:49 [PATCH 0/3] usb: gadget: 9pfs transport Michael Grzeschik
2024-01-16 1:49 ` [PATCH 1/3] usb: gadget: function: 9pfs Michael Grzeschik
2024-01-16 3:17 ` Alan Stern
2024-01-16 4:04 ` Dominique Martinet
2024-01-16 15:45 ` Alan Stern
2024-01-16 11:34 ` kernel test robot
2024-01-16 12:04 ` kernel test robot
2024-01-16 19:51 ` kernel test robot
2024-01-16 21:14 ` Christophe JAILLET
2024-01-17 0:02 ` kernel test robot
2024-01-16 1:49 ` [PATCH 2/3] usb: gadget: legacy: add 9pfs multi gadget Michael Grzeschik
2024-01-16 18:05 ` kernel test robot
2024-01-16 1:49 ` [PATCH 3/3] tools: usb: p9_fwd: add usb gadget packet forwarder script Michael Grzeschik
2024-01-16 11:45 ` [PATCH 0/3] usb: gadget: 9pfs transport Dominique Martinet
2024-01-16 15:51 ` Jan Lübbe
2024-01-17 10:54 ` Dominique Martinet [this message]
2024-01-26 19:47 ` Andrzej Pietrasiewicz
2024-01-26 21:57 ` Michael Grzeschik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zaex_fkKcui7QZd7@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=corbet@lwn.net \
--cc=ericvh@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jlu@pengutronix.de \
--cc=kernel@pengutronix.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=m.grzeschik@pengutronix.de \
--cc=v9fs@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).