On Mon, Sep 9, 2019 at 9:00 AM Stefan Hajnoczi <stefanha@xxxxxxxxxx> 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: > > 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? -- Thanks, //richard
