Message ID | 20240116-ml-topic-u9p-v1-0-ad8c306f9a4e@pengutronix.de |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-26911-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2614:b0:101:6a76:bbe3 with SMTP id mm20csp2051186dyc; Mon, 15 Jan 2024 17:56:22 -0800 (PST) X-Google-Smtp-Source: AGHT+IGYnJ3v4HnFl/oJt5bXVHkKCZCbG6rWCIvP5I0GtcSyIGNadpXbBQsonPa5mkP+8WjFzS/G X-Received: by 2002:a05:620a:2414:b0:783:1ecd:bfd1 with SMTP id d20-20020a05620a241400b007831ecdbfd1mr8940311qkn.66.1705370182708; Mon, 15 Jan 2024 17:56:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705370182; cv=none; d=google.com; s=arc-20160816; b=t/TTwYf1Dyr8V8vH69Od5dbJ0WdOg5V9Rf2n8sd/K2oYkDwqMAgLdpV1Av+nQ699Ow anJrmwC+hmJA7udrWv6eY3wO5vBMTSAz+VrGArXA9mT54jYcn+6HcSAHcKcgTdVyDDWc 21dfwRpBcavX3PmwWXBnjaktoAYnvQkMUyF1KfixsHKtYXpoF3HsoDj7NXXfpHKSur+6 4YR9eWG5fsWX/lrVjnh4aGUtaUTY4WaVeBiVWFIrHPF4SYZFLKhA3L2fhKo9pqc3ZouS usI6dSSRS/s+e8+3fBHM/ZUX6nkb1G5VpGjEH2qtCUoE/IpsL5HqbOMGGvF3IIMf2++5 dR7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:from; bh=4Ak2yBb++1ZsHFkm1QjXKAz2uPVy+P8qbCepmiUy4V0=; fh=j4kDYto2y5txw4kIsFBJWe3oUIncnYU+0HsCYPolsxs=; b=G59577B9oA1t4K7hadPMAfXwdb6iIUMnkKX0eg60g/83vqkKQ2QTacAn2r2qdNNZKY haRxrcWwxluy7rPT9y+ekW1j9zStPOU3pQikKl1c9vZiK2Lr9qJAJ8r9YeeZKJg9wyHY RqPYYkE7Yg7LxR9IT8XkP6+RFFrpdQwduEGsbvOLIYAvQiND66YLr/NJLbpl0CfTgsuM 6JjT34YrWy9YXc6X0Y+bPI+R8y8JzGekWVqmd28spA0K79IJmkiTFDmE3EplHp0xgn5G UsoY+M90jQpjc9lTjAG9fLTZphaqrKSVWXYHhIrIRnLSMEOCftgiGivW4OH2Cts6PrqO LIhQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-26911-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-26911-ouuuleilei=gmail.com@vger.kernel.org" Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id t21-20020a170902b21500b001d3e11cf5ebsi10079538plr.34.2024.01.15.17.56.22 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jan 2024 17:56:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-26911-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-26911-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-26911-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 2AEBBB20AEC for <ouuuleilei@gmail.com>; Tue, 16 Jan 2024 01:56:10 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3D423125C2; Tue, 16 Jan 2024 01:49:56 +0000 (UTC) Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD7F811738 for <linux-kernel@vger.kernel.org>; Tue, 16 Jan 2024 01:49:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <m.grzeschik@pengutronix.de>) id 1rPYaJ-0000ky-8h; Tue, 16 Jan 2024 02:49:47 +0100 Received: from [2a0a:edc0:0:1101:1d::ac] (helo=dude04.red.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <m.grzeschik@pengutronix.de>) id 1rPYaI-0008V6-1W; Tue, 16 Jan 2024 02:49:46 +0100 Received: from localhost ([::1] helo=dude04.red.stw.pengutronix.de) by dude04.red.stw.pengutronix.de with esmtp (Exim 4.96) (envelope-from <m.grzeschik@pengutronix.de>) id 1rPYaI-001Ipo-2l; Tue, 16 Jan 2024 02:49:45 +0100 From: Michael Grzeschik <m.grzeschik@pengutronix.de> Subject: [PATCH 0/3] usb: gadget: 9pfs transport Date: Tue, 16 Jan 2024 02:49:40 +0100 Message-Id: <20240116-ml-topic-u9p-v1-0-ad8c306f9a4e@pengutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-B4-Tracking: v=1; b=H4sIALTgpWUC/x2NQQ6DIBAAv2L27Eag2mq/0ngAuuomgARa08T49 6LHSWYyO2RKTBme1Q6JNs68hgKyrsAuOsyE/C4MSqhWSHlH7/CzRrb4HSL2Q6cebXcTZCSUxOh MaJIOdjkj77xrLrsp9inERBP/rt9rPI4/3O10p38AAAA= To: Eric Van Hensbergen <ericvh@kernel.org>, Latchesar Ionkov <lucho@ionkov.net>, Dominique Martinet <asmadeus@codewreck.org>, Christian Schoenebeck <linux_oss@crudebyte.com>, Jonathan Corbet <corbet@lwn.net>, Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: v9fs@lists.linux.dev, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, kernel@pengutronix.de, Michael Grzeschik <m.grzeschik@pengutronix.de> X-Mailer: b4 0.12.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=1093; i=m.grzeschik@pengutronix.de; h=from:subject:message-id; bh=yz02KOmKzCnyEnnJvy2TSYDyudqgNT9HDEHjky0bkZg=; b=owEBbQKS/ZANAwAKAb9pWET5cfSrAcsmYgBlpeC4eGnIeVv6q2r2za78NnD4LRJcDemS2iPCo ZjmU2vhwsCJAjMEAAEKAB0WIQQV2+2Fpbqd6fvv0Gi/aVhE+XH0qwUCZaXguAAKCRC/aVhE+XH0 q63ZEACXBcFZ+eKSrlX1JwFTf2fPMxfzw6hTh/SKjMP4mmR6xEiCgpOBas6tL1IJKNEB389Hw6S bV0Xl5VoTBmf2EtCfMkJWsbnpfcgCXQAmAIys7gDqXY+jIzElxosH5sZnljJJv/qgQkz96Afxof gGkHkU4He560W1YWA4FCb7xTt4uFjGxhBg9zK+6wNGY+tf8scpkztkwvWhSf+HPBuxK1OotOgur B3qes3ZJUIraZnC1gj49LAQc3+DnnJWcpq0vgGblRZQTM/MW4m3WWGO2rHnmhGaHScaxVDRQ3kH m4DnRksRDY4eaYWeJ0YSM8LzaubZwzur/3QhBr6s/lkaO6VSSAQO6PbnotIlh2Hm937nFXE0G5v NGl1V4qIlaq/9txAwVJBzKOemP/TRcqxdcjHm8UVLj6hc5RmyKxw842CoEIqOr8kOqHBFEC8ygv NNbnkS9VfNPfwYP0tApK8F6U2FdJ+l/nYIbYOUBWB3I/plYZq/DPja4JBqmzCmkcvWRFkToGcLm h1pqCZZasDgADhBIjl0C1BFx0MYeGZS/rVhJhucGBCbrIpJE47VzDCj/nQwbgTaNP6jngP9WYgu XtLs6LVyt+Lkqo5Sz0ECwt50uACWgKgswFcLRsNZeyufO8qt5viZcD3/i8T5Uq0WOavfjMM7Gw2 mKRita8UMrLLqMA== X-Developer-Key: i=m.grzeschik@pengutronix.de; a=openpgp; fpr=957BC452CE953D7EA60CF4FC0BE9E3157A1E2C64 X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: m.grzeschik@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788210244665839997 X-GMAIL-MSGID: 1788210244665839997 |
Series | usb: gadget: 9pfs transport | |
Message
Michael Grzeschik
Jan. 16, 2024, 1:49 a.m. UTC
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.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
---
Michael Grzeschik (3):
usb: gadget: function: 9pfs
usb: gadget: legacy: add 9pfs multi gadget
tools: usb: p9_fwd: add usb gadget packet forwarder script
Documentation/filesystems/9p.rst | 12 +
drivers/usb/gadget/Kconfig | 11 +
drivers/usb/gadget/function/Makefile | 2 +
drivers/usb/gadget/function/f_9pfs.c | 849 +++++++++++++++++++++++++++++++++++
drivers/usb/gadget/legacy/9pfs.c | 260 +++++++++++
drivers/usb/gadget/legacy/Kconfig | 15 +
drivers/usb/gadget/legacy/Makefile | 2 +
tools/usb/p9_fwd.py | 194 ++++++++
8 files changed, 1345 insertions(+)
---
base-commit: 052d534373b7ed33712a63d5e17b2b6cdbce84fd
change-id: 20240116-ml-topic-u9p-895274530eb1
Best regards,
Comments
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 ? 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... 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. While I had a quick look I'll spare you a second mail for the first patch: Michael Grzeschik wrote on Tue, Jan 16, 2024 at 02:49:41AM +0100: > +static struct p9_trans_module p9_usbg_trans = { > + .name = "usbg", > + .create = p9_usbg_create, > + .close = p9_usbg_close, > + .request = p9_usbg_request, > + .cancel = p9_usbg_cancel, > + .owner = THIS_MODULE, > +}; This is missing a MODULE_ALIAS_9P("usbg") if you want the module to auto-load on `mount -t trans=usbg` -- assuming this can build as a module. I'm also a bit worried that this net/9p-centric code is now also split with drivers/usb/gadget/function/f_9pfs.c and I'll bet you the build will break once in a while when we update global 9p client.c or similar -- I'd be more comfortable having a net/9p/trans_usbg.c or equivalent if possible. Is there a reason this has to be in the usb gadget tree? (Well, I assume from the usb gadget point of view, it's reasonable to similarily prefer this code to stay close to drivers/usb/gadget..) Thanks,
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 (ie. 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
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)
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) >
On Fri, Jan 26, 2024 at 08:47:22PM +0100, Andrzej Pietrasiewicz wrote: >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? I did a lot of testing with dummy_hcd. So this should work. But of course testing the special case of rootfs is tricky. Since you will have to share the gadget with qemu to boot the rootfs from somewhere else. Regards, Michael >>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) >> > >