Messages in this thread | | | Date | Sun, 20 Jun 2021 11:36:59 +0800 | From | Changbin Du <> | Subject | Re: [PATCH v3 0/3] 9p: add support for root file systems |
| |
On Mon, Jun 14, 2021 at 02:19:38AM -0700, Josh Triplett wrote: > On Mon, Jun 14, 2021 at 06:01:44PM +0900, Dominique Martinet wrote: > > Josh Triplett wrote on Mon, Jun 14, 2021 at 01:57:54AM -0700: > > > On Mon, Jun 07, 2021 at 07:09:19AM +0800, Changbin Du wrote: > > > > Just like cifs and nfs, this short series enables rootfs support for 9p. > > > > Bellow is an example which mounts v9fs with tag 'r' as rootfs in qemu > > > > guest via virtio transport. > > > > > > > > $ qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \ > > > > -virtfs local,path=$rootfs_dir,mount_tag=r,security_model=passthrough,id=r \ > > > > -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \ > > > > -append "root=/dev/v9fs v9fsroot=r,trans=virtio rw console=ttyS0 3" > > > > > > Rather than inventing a pseudo-device /dev/v9fs for this, would it > > > potentially work to use the existing rootfstype and rootflags options > > > for this? rootfstype already determines what filesystem should be used > > > to mount the root, and rootflags already provides options for that > > > filesystem. > > > > > > For instance, for the above example: > > > rootfstype=9p root=r rootflags=trans=virtio > > > > > > That would require a bit of fiddling to make rootfstype=9p allow a root > > > that's just the mount_tag. If that isn't an option, then even with > > > root=/dev/v9fs I think it still makes sense to use the existing > > > rootflags for "trans=virtio" rather than creating a new "v9fsroot" > > > option for that. > > > > This doesn't work as is because of the way the code is written, if > > there's no block device associated with a root=x option right now it > > will lead to kernel panic. > > > > I replied with folks in Cc but there's another thread on linux-fsdevel@ > > with a more generic approach that will build a list of filesystems which > > don't require such a block device (either hardcoded with virtiofs and 9p > > or based on FS_REQUIRES_DEV), thread started there but there's a second > > patch hidden an more discussion below: > > https://lore.kernel.org/linux-fsdevel/20210608153524.GB504497@redhat.com/ > > The patch later on in that thread (either using a list of > non-block-device filesystems or the version referenced elsewhere that > uses a flag in the filesystem definition) looks really appealing! That's > exactly what I was hoping for. That gets us closer to directly > translating `mount -t type -o options rootdesc` into `rootfstype=type > rootflags=options root=rootdesc` in the general case, rather than having > special cases for different filesystems. Bellow is all the parameters of non-block rootfs support. nfs: nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>] cifs: cifsroot=//<server-ip>/<share>[,options] v9fs: v9fsroot=<tag/ip>[,options] mtd: root=mtd:<identifier> or root=ubi:<identifier> virtiofs: root=fstag:<tag>
The main problem is we lack a generic handing for non-block rootdev. I think maybe we can unify all of above. non-block: root=<type>:<identifier> blockdev: root=<bock-dev-path> or root=<blockdev major/minor>
Then: nfs: root=nfs:[<server-ip>:]<root-dir> rootflags=[nfs-options] cifs: root=cifs://<server-ip>/<share> rootflags=[options] v9fs: root=9p:<tag/ip> rootflags=[options] mtd: root=mtd:<identifier> rootflags=[options] ubi: root=ubi:<identifier> rootflags=[options] virtiofs: root=virtiofs:<tag> rootflags=[options]
And maybe we can also remove all the special fs code out of init/do_mounts.c.
-- Cheers, Changbin Du
| |