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@xxxxxxxxxx> 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@xxxxxxxxxx>
> > > ---
> > > 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
Attachment:
signature.asc
Description: PGP signature
