Hi Simon, Sorry for the delayed reply, and thanks for the thorough review and suggestions.
On Wed, Jul 15, 2026 at 12:42:37PM -0600, Simon Glass wrote: > Hi Kuan-Wei, > > On 2026-07-06T21:54:42, Kuan-Wei Chiu <[email protected]> wrote: > > > It allows U-Boot to directly mount host directories in virtualization > > environments via virtio. > > Thanks for working on this - a nice feature which has been missing for a > while. > > My main concern is the overall design. The transport driver registers > a single global client which the filesystem layer picks up, so there > can only ever be one 9P device and the QEMU mount tag is ignored. > Since the transport is already a driver-model device, please can you > attach the client state to the udevice and have the filesystem layer > look up the device, rather than using a global? That would let the > user select a particular device (or mount tag) in the ls and load > commands instead of passing a dash, and would fit better with the rest > of U-Boot. Thanks. I plan to introduce UCLASS_9P in DM to manage 9P transport devices. The virtio driver will bind as a UCLASS_9P device, with struct p9_client managed automatically in uclass private data. For device selection, I plan to have the virtio driver negotiate VIRTIO_9P_MOUNT_TAG and store the tag during probe, and pass the device argument through the fs layer. So users could select devices by mount tag ('ls 9p rootfs /'), device index ('ls 9p 0 /'), or default to the first device ('ls 9p - /'). > > Related to this, intercepting the 9p interface name in the generic > filesystem code feels like a hack. It would be better to integrate > with the existing device/partition handling, perhaps along the lines > of semihosting. Ack. I'll remove the interception in fs/fs.c and integrate 9p into disk/part.c blk_get_device_part_str() to match semihosting. > > > The functionality has been verified on qemu arm64 by successfully > > loading a Linux kernel image and an initramfs image via 9P, and booting > > to the Linux shell. > > For the tests Tom asked for, one option would be a sandbox transport > driver (see the existing sandbox virtio support) so the protocol and > filesystem code can be exercised in CI without QEMU, plus a pytest for > the QEMU side. A doc/usage page showing the QEMU flags and U-Boot > commands from this cover letter would be a good start for the docs. I'll add the doc. Since my current development re all based on qemu, I prefer adding the qemu arm64 pytest for v2 to test against a real 9p server. I think the sandbox mock transport can be added later once the core driver lands. Regards, Kuan-Wei
