| Message ID | 20190906100324.8492-1-stefanha@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | init/do_mounts.c: add virtiofs root fs support | expand |
On Fri, Sep 6, 2019 at 1:15 PM Stefan Hajnoczi <stefanha@redhat.com> wrote: > > Make it possible to boot directly from a virtiofs file system with tag > 'myfs' using the following kernel parameters: > > rootfstype=virtiofs root=myfs rw > > Booting directly from virtiofs makes it possible to use a directory on > the host as the root file system. This is convenient for testing and > situations where manipulating disk image files is cumbersome. > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> > --- > This patch is based on linux-next (next-20190904) but should apply > cleanly to other virtiofs trees. > > init/do_mounts.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/init/do_mounts.c b/init/do_mounts.c > index 9634ecf3743d..030be2f1999a 100644 > --- a/init/do_mounts.c > +++ b/init/do_mounts.c > @@ -554,6 +554,16 @@ void __init mount_root(void) > change_floppy("root floppy"); > } > #endif > +#ifdef CONFIG_VIRTIO_FS > + if (root_fs_names && !strcmp(root_fs_names, "virtiofs")) { > + if (!do_mount_root(root_device_name, "virtiofs", > + root_mountflags, root_mount_data)) > + return; > + > + panic("VFS: Unable to mount root fs \"%s\" from virtiofs", > + root_device_name); > + } > +#endif I think you don't need this, you can abuse a hack for mtd/ubi in prepare_namespace(). At least for 9p it works well: qemu-system-x86_64 -m 4G -M pc,accel=kvm -nographic -kernel arch/x86/boot/bzImage -append "rootfstype=9p rootflags=trans=virtio,version=9p2000.L root=mtdfake console=ttyS0 ro init=/bin/sh" -virtfs local,id=rootfs,path=/,security_model=passthrough,mount_tag=mtdfake If this works too for virtiofs I suggest to cleanup the hack and generalize it. B-)
On Fri, Sep 06, 2019 at 09:16:04PM +0200, Richard Weinberger wrote: > On Fri, Sep 6, 2019 at 1:15 PM Stefan Hajnoczi <stefanha@redhat.com> wrote: > > > > Make it possible to boot directly from a virtiofs file system with tag > > 'myfs' using the following kernel parameters: > > > > rootfstype=virtiofs root=myfs rw > > > > Booting directly from virtiofs makes it possible to use a directory on > > the host as the root file system. This is convenient for testing and > > situations where manipulating disk image files is cumbersome. > > > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> > > --- > > This patch is based on linux-next (next-20190904) but should apply > > cleanly to other virtiofs trees. > > > > init/do_mounts.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/init/do_mounts.c b/init/do_mounts.c > > index 9634ecf3743d..030be2f1999a 100644 > > --- a/init/do_mounts.c > > +++ b/init/do_mounts.c > > @@ -554,6 +554,16 @@ void __init mount_root(void) > > change_floppy("root floppy"); > > } > > #endif > > +#ifdef CONFIG_VIRTIO_FS > > + if (root_fs_names && !strcmp(root_fs_names, "virtiofs")) { > > + if (!do_mount_root(root_device_name, "virtiofs", > > + root_mountflags, root_mount_data)) > > + return; > > + > > + panic("VFS: Unable to mount root fs \"%s\" from virtiofs", > > + root_device_name); > > + } > > +#endif > > I think you don't need this, you can abuse a hack for mtd/ubi in > prepare_namespace(). > At least for 9p it works well: > qemu-system-x86_64 -m 4G -M pc,accel=kvm -nographic -kernel > arch/x86/boot/bzImage -append "rootfstype=9p > rootflags=trans=virtio,version=9p2000.L root=mtdfake console=ttyS0 ro > init=/bin/sh" -virtfs > local,id=rootfs,path=/,security_model=passthrough,mount_tag=mtdfake That is worse because: 1. The file system must be named "mtd*" or "ubi*". 2. When mounting fails you get confusing error messages about block devices and partitions. These do not apply to virtio-fs or virtio-9p. > If this works too for virtiofs I suggest to cleanup the hack and > generalize it. B-) Why mtd and ubi block devices even have a special case? Maybe this code was added because ROOT_DEV = name_to_dev_t(root_device_name) doesn't work for "mtd:partition" device names so the regular CONFIG_BLOCK code path doesn't work for these devices. Given the ordering/fallback logic in prepare_namespace()/mount_root() I don't feel comfortable changing other code paths. It's likely to break something. If you or others have a concrete suggestion for how to generalize this I'm happy to try implementing it. Stefan
On Mon, Sep 09, 2019 at 09:00:39AM +0200, Stefan Hajnoczi wrote: > On Fri, Sep 06, 2019 at 09:16:04PM +0200, Richard Weinberger wrote: > > On Fri, Sep 6, 2019 at 1:15 PM Stefan Hajnoczi <stefanha@redhat.com> wrote: > > > > > > Make it possible to boot directly from a virtiofs file system with tag > > > 'myfs' using the following kernel parameters: > > > > > > rootfstype=virtiofs root=myfs rw > > > > > > Booting directly from virtiofs makes it possible to use a directory on > > > the host as the root file system. This is convenient for testing and > > > situations where manipulating disk image files is cumbersome. > > > > > > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> > > > --- > > > This patch is based on linux-next (next-20190904) but should apply > > > cleanly to other virtiofs trees. > > > > > > init/do_mounts.c | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/init/do_mounts.c b/init/do_mounts.c > > > index 9634ecf3743d..030be2f1999a 100644 > > > --- a/init/do_mounts.c > > > +++ b/init/do_mounts.c > > > @@ -554,6 +554,16 @@ void __init mount_root(void) > > > change_floppy("root floppy"); > > > } > > > #endif > > > +#ifdef CONFIG_VIRTIO_FS > > > + if (root_fs_names && !strcmp(root_fs_names, "virtiofs")) { > > > + if (!do_mount_root(root_device_name, "virtiofs", > > > + root_mountflags, root_mount_data)) > > > + return; > > > + > > > + panic("VFS: Unable to mount root fs \"%s\" from virtiofs", > > > + root_device_name); > > > + } > > > +#endif > > > > I think you don't need this, you can abuse a hack for mtd/ubi in > > prepare_namespace(). > > At least for 9p it works well: > > qemu-system-x86_64 -m 4G -M pc,accel=kvm -nographic -kernel > > arch/x86/boot/bzImage -append "rootfstype=9p > > rootflags=trans=virtio,version=9p2000.L root=mtdfake console=ttyS0 ro > > init=/bin/sh" -virtfs > > local,id=rootfs,path=/,security_model=passthrough,mount_tag=mtdfake > > That is worse because: > 1. The file system must be named "mtd*" or "ubi*". > 2. When mounting fails you get confusing error messages about block > devices and partitions. These do not apply to virtio-fs or > virtio-9p. > > > If this works too for virtiofs I suggest to cleanup the hack and > > generalize it. B-) > > Why mtd and ubi block devices even have a special case? Maybe this code > was added because ROOT_DEV = name_to_dev_t(root_device_name) doesn't > work for "mtd:partition" device names so the regular CONFIG_BLOCK code > path doesn't work for these devices. > > Given the ordering/fallback logic in prepare_namespace()/mount_root() I > don't feel comfortable changing other code paths. It's likely to break > something. > > If you or others have a concrete suggestion for how to generalize this > I'm happy to try implementing it. Ping Stefan
On Mon, Sep 9, 2019 at 9:00 AM Stefan Hajnoczi <stefanha@redhat.com> wrote: > On Fri, Sep 06, 2019 at 09:16:04PM +0200, Richard Weinberger wrote: > > On Fri, Sep 6, 2019 at 1:15 PM Stefan Hajnoczi <stefanha@redhat.com> wrote: > > I think you don't need this, you can abuse a hack for mtd/ubi in > > prepare_namespace(). > > At least for 9p it works well: > > qemu-system-x86_64 -m 4G -M pc,accel=kvm -nographic -kernel > > arch/x86/boot/bzImage -append "rootfstype=9p > > rootflags=trans=virtio,version=9p2000.L root=mtdfake console=ttyS0 ro > > init=/bin/sh" -virtfs > > local,id=rootfs,path=/,security_model=passthrough,mount_tag=mtdfake > > That is worse because: > 1. The file system must be named "mtd*" or "ubi*". > 2. When mounting fails you get confusing error messages about block > devices and partitions. These do not apply to virtio-fs or > virtio-9p. This is the current situation, I'm not saying it is perfect. But before we add another special case for a filesystem we should at least try to consolidate this stuff. > > If this works too for virtiofs I suggest to cleanup the hack and > > generalize it. B-) > > Why mtd and ubi block devices even have a special case? Maybe this code > was added because ROOT_DEV = name_to_dev_t(root_device_name) doesn't > work for "mtd:partition" device names so the regular CONFIG_BLOCK code > path doesn't work for these devices. ubi and mtd are not block devices, they are character devices. That's why the hack with name matching was added a long time ago. > Given the ordering/fallback logic in prepare_namespace()/mount_root() I > don't feel comfortable changing other code paths. It's likely to break > something. > > If you or others have a concrete suggestion for how to generalize this > I'm happy to try implementing it. mtd, ubi, virtiofs and 9p have one thing in common, they are not block devices. What about a new miscroot= kernel parameter?
On Tue, Sep 17, 2019 at 08:19:55PM +0200, Richard Weinberger wrote: > mtd, ubi, virtiofs and 9p have one thing in common, they are not block devices. > What about a new miscroot= kernel parameter? How about something like xfs!sda5 or nfs!foo.local.net/bar, etc.? With ubi et.al. covered by the same syntax...
* Al Viro (viro@zeniv.linux.org.uk) wrote: > On Tue, Sep 17, 2019 at 08:19:55PM +0200, Richard Weinberger wrote: > > > mtd, ubi, virtiofs and 9p have one thing in common, they are not block devices. > > What about a new miscroot= kernel parameter? > > How about something like xfs!sda5 or nfs!foo.local.net/bar, etc.? With > ubi et.al. covered by the same syntax... Would Stefan's patch work if there was just a way to test for non-block based fileystsmes and we replaced !strcmp(root_fs_names, "virtiofs") by not_block_based_fs(root_fs_names) Or is there some magic that the other filesystems do that's specific? Dave > _______________________________________________ > Virtio-fs mailing list > Virtio-fs@redhat.com > https://www.redhat.com/mailman/listinfo/virtio-fs -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On Tue, Sep 17, 2019 at 07:34:25PM +0100, Dr. David Alan Gilbert wrote: > * Al Viro (viro@zeniv.linux.org.uk) wrote: > > On Tue, Sep 17, 2019 at 08:19:55PM +0200, Richard Weinberger wrote: > > > > > mtd, ubi, virtiofs and 9p have one thing in common, they are not block devices. > > > What about a new miscroot= kernel parameter? > > > > How about something like xfs!sda5 or nfs!foo.local.net/bar, etc.? With > > ubi et.al. covered by the same syntax... > > Would Stefan's patch work if there was just a way to test for non-block > based fileystsmes and we replaced > !strcmp(root_fs_names, "virtiofs") by > not_block_based_fs(root_fs_names) > > Or is there some magic that the other filesystems do that's specific? I will try this. Stefan
diff --git a/init/do_mounts.c b/init/do_mounts.c index 9634ecf3743d..030be2f1999a 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -554,6 +554,16 @@ void __init mount_root(void) change_floppy("root floppy"); } #endif +#ifdef CONFIG_VIRTIO_FS + if (root_fs_names && !strcmp(root_fs_names, "virtiofs")) { + if (!do_mount_root(root_device_name, "virtiofs", + root_mountflags, root_mount_data)) + return; + + panic("VFS: Unable to mount root fs \"%s\" from virtiofs", + root_device_name); + } +#endif #ifdef CONFIG_BLOCK { int err = create_dev("/dev/root", ROOT_DEV);
Make it possible to boot directly from a virtiofs file system with tag 'myfs' using the following kernel parameters: rootfstype=virtiofs root=myfs rw Booting directly from virtiofs makes it possible to use a directory on the host as the root file system. This is convenient for testing and situations where manipulating disk image files is cumbersome. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> --- This patch is based on linux-next (next-20190904) but should apply cleanly to other virtiofs trees. init/do_mounts.c | 10 ++++++++++ 1 file changed, 10 insertions(+)