linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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