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"
v3:
o rebase.
v2:
o use pr_err instead of printk.
o ROOT_DEV is only set after checking.
o cleanup DEFAULT_MNT_OPTS.
o do not retry mount for fd and virtio transport.
Changbin Du (3):
9p: add support for root file systems
9p: doc: move to a new dedicated folder
9p: doc: add v9fsroot description
Changbin Du (3):
9p: add support for root file systems
9p: doc: move to a new dedicated folder
9p: doc: add v9fsroot description
Documentation/filesystems/index.rst | 2 +-
Documentation/filesystems/{ => v9fs}/9p.rst | 0
Documentation/filesystems/v9fs/index.rst | 12 ++++
Documentation/filesystems/v9fs/v9fsroot.rst | 52 +++++++++++++++++
MAINTAINERS | 8 ++-
fs/9p/Kconfig | 6 ++
fs/9p/Makefile | 1 +
fs/9p/v9fsroot.c | 64 +++++++++++++++++++++
include/linux/root_dev.h | 1 +
init/do_mounts.c | 55 ++++++++++++++++++
10 files changed, 199 insertions(+), 2 deletions(-)
rename Documentation/filesystems/{ => v9fs}/9p.rst (100%)
create mode 100644 Documentation/filesystems/v9fs/index.rst
create mode 100644 Documentation/filesystems/v9fs/v9fsroot.rst
create mode 100644 fs/9p/v9fsroot.c
--
2.30.2
Later we will add another documentation for v9fs.
Signed-off-by: Changbin Du <[email protected]>
---
Documentation/filesystems/index.rst | 2 +-
Documentation/filesystems/{ => v9fs}/9p.rst | 0
Documentation/filesystems/v9fs/index.rst | 11 +++++++++++
MAINTAINERS | 2 +-
4 files changed, 13 insertions(+), 2 deletions(-)
rename Documentation/filesystems/{ => v9fs}/9p.rst (100%)
create mode 100644 Documentation/filesystems/v9fs/index.rst
diff --git a/Documentation/filesystems/index.rst b/Documentation/filesystems/index.rst
index d4853cb919d2..e53992636a49 100644
--- a/Documentation/filesystems/index.rst
+++ b/Documentation/filesystems/index.rst
@@ -63,7 +63,7 @@ Documentation for filesystem implementations.
.. toctree::
:maxdepth: 2
- 9p
+ v9fs/index
adfs
affs
afs
diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/v9fs/9p.rst
similarity index 100%
rename from Documentation/filesystems/9p.rst
rename to Documentation/filesystems/v9fs/9p.rst
diff --git a/Documentation/filesystems/v9fs/index.rst b/Documentation/filesystems/v9fs/index.rst
new file mode 100644
index 000000000000..a1e45b89e2a2
--- /dev/null
+++ b/Documentation/filesystems/v9fs/index.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====
+v9fs
+====
+
+.. toctree::
+ :maxdepth: 6
+ :numbered:
+
+ 9p
diff --git a/MAINTAINERS b/MAINTAINERS
index 35b2c8f614d0..3da44eef1471 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -232,7 +232,7 @@ W: http://swik.net/v9fs
Q: http://patchwork.kernel.org/project/v9fs-devel/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git
T: git git://github.com/martinetd/linux.git
-F: Documentation/filesystems/9p.rst
+F: Documentation/filesystems/v9fs/
F: fs/9p/
F: include/net/9p/
F: include/trace/events/9p.h
--
2.30.2
This documentation is modified from cifs/cifsroot.rst.
Signed-off-by: Changbin Du <[email protected]>
---
Documentation/filesystems/v9fs/index.rst | 1 +
Documentation/filesystems/v9fs/v9fsroot.rst | 52 +++++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 54 insertions(+)
create mode 100644 Documentation/filesystems/v9fs/v9fsroot.rst
diff --git a/Documentation/filesystems/v9fs/index.rst b/Documentation/filesystems/v9fs/index.rst
index a1e45b89e2a2..65e1ceb04c9c 100644
--- a/Documentation/filesystems/v9fs/index.rst
+++ b/Documentation/filesystems/v9fs/index.rst
@@ -9,3 +9,4 @@ v9fs
:numbered:
9p
+ v9fsroot
diff --git a/Documentation/filesystems/v9fs/v9fsroot.rst b/Documentation/filesystems/v9fs/v9fsroot.rst
new file mode 100644
index 000000000000..ce6b3c85e301
--- /dev/null
+++ b/Documentation/filesystems/v9fs/v9fsroot.rst
@@ -0,0 +1,52 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==========================================
+Mounting root file system via v9fs (9p.ko)
+==========================================
+
+:Author: Changbin Du <[email protected]>
+
+The CONFIG_9P_FS_ROOT option enables experimental root file system
+support for v9fs.
+
+It introduces a new kernel command-line option called 'v9fsroot='
+which will tell the kernel to mount the root file system by
+utilizing the 9p protocol.
+
+
+Kernel command line
+===================
+
+::
+
+ root=/dev/v9fs
+
+This is just a virtual device that basically tells the kernel to mount
+the root file system via 9p protocol.
+
+::
+
+ v9fsroot=<path>[,options]
+
+Enables the kernel to mount the root file system via 9p specified in this
+option.
+
+path
+ Could be a remote file server, Plan 9 From User Space applications
+ or mount tag of virtio transport.
+
+options
+ Optional mount options.
+
+Examples
+========
+Test it under QEMU on a kernel built with CONFIG_9P_FS_ROOT and
+CONFIG_IP_PNP options enabled::
+
+ # 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"
+
+The above example mounts v9fs with tag 'r' as rootfs in qemu guest via
+virtio transport.
diff --git a/MAINTAINERS b/MAINTAINERS
index 3da44eef1471..dfcee6dfe182 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -243,6 +243,7 @@ F: net/9p/
R: Changbin Du <[email protected]>
S: Supported
F: fs/9p/v9fsroot.c
+F: Documentation/filesystems/v9fs/v9fsroot.rst
A8293 MEDIA DRIVER
M: Antti Palosaari <[email protected]>
--
2.30.2
Changbin Du wrote on Mon, Jun 07, 2021 at 07:09:19AM +0800:
> 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"
Thanks for rebasing -- I haven't forgotten, just been otherwise busy.
Will make time for this and the netfs rework over the next couple of
weeks.
Just a couple of notes:
linux-fsdevel@vger is still not in Cc of the patches, and they weren't
for any other version except for one of my replies, so it might be worth
resending just for them as it touches do_mounts.c / root_dev.h
> MAINTAINERS | 8 ++-
I don't think it's worth adding yourself as MAINTAINERS for this, will
likely strip it out (I know I'm the one who asked for your help if
people have problems with this, but we should keep contacts simple)
I'll forward you requests when they come if it's not trivial and you're
not subscribed to the v9fs-developer@sf list
--
Dominique
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.
- Josh Triplett
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/[email protected]/
My preferred approach right now would be to go with their approach, and
adjust the documentation Changbin Du wrote here, to have the best of
both worlds.
--
Dominique
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/[email protected]/
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.
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/[email protected]/
>
> 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
Changbin Du wrote on Sun, Jun 20, 2021 at 11:36:59AM +0800:
> The main problem is we lack a generic handing for non-block rootdev. I think
> maybe we can unify all of above.
We're already going in that direction, please have a look at the threads
on fsdevel:
(new patch by Christoph)
https://lore.kernel.org/linux-fsdevel/[email protected]/
(older threads I linked earlier)
https://lore.kernel.org/linux-fsdevel/[email protected]/
I think it's getting there, Christoph should send a v2 addressing Vivek
remarks that will likely get picked up.
--
Dominique