On Thu, Sep 26, 2019 at 10:57:48AM +0800, Ian Kent wrote:
> > Ok, so I'm not terribly familiar with the core mount code in the
> > first
> > place. Can you elaborate a bit on the where the whole "source" thing
> > comes from and why/how it's necessary to boot?
device name. And there's nothing special about boot.
> Your not alone.
>
> I've pondered over the VFS mount code fairly often over the years
> and I've not seen it before either.
>
> About all I know is it's needed for rootfs, so I guess it's needed
> to resolve the boot device when no file system is yet mounted and
> a normal path walk can't be done.
Bollocks. Absolute root is ramfs or tmpfs and we do have mknod done
there.
Root filesystem is a complete red herring.
> Maybe an additional fs_context_purpose needs to be defined, maybe
> FS_CONTEXT_FOR_ROOTFS for example.
NO. ->purpose should go away, not be extended. And again, that
has fuck-all to do with rootfs.
> That's probably the cleanest way to handle it, not sure it would
> properly cover the cases though.
>
> That wouldn't be an entirely trivial change so David and Al would
> likely need to get involved and Linus would need to be willing to
> accept it.
> > BTW, this all implies there is some reason for an fs to handle the
> > "source" option, so what happens if one actually does? ISTM the
> > ->parse_param() callout would return 0 and vfs_parse_fs_param() would
> > skip its own update of fc->source. Hm?
>
> As I understand it that's not a problem because the file system
> will need to have converted the parameter value to some "source"
> value usable by the kernel.
For fsck sake... It's where the first argument of mount(2) goes.
As in, "/dev/sda4" when you say mount -t xfs /dev/sda4 /mnt
Or "10.1.1.18:/srv/nfs/mirrors" in
mount -t nfs4 10.1.1.18:/srv/nfs/mirrors /home/mirrors/public \
-o rsize=8192,wsize=8192,proto=tcp,ro
Note that it's not in any real sense different from any other
option - its interpretation is entirely up to fs type. The
only reason why it's separate is historical - way, way back
there had been no filesystem types and mount(2) got just
a block device pathname + mountpoint + one flag (ro/rw).
No (string) options either. There has been a long and nasty
history, considerably older than Linux, including such things
as magical binary structures (each for its own fs type - check
how e.g. OSF is doing that).
But accidents of calling conventions aside, device name is just
another fs option. And device name is a misnomer - witness
what e.g. NFS is doing. Keeping it special for new API
was pointless, so we have this in vfs_kern_mount():
fc = fs_context_for_mount(type, flags);
if (IS_ERR(fc))
return ERR_CAST(fc);
if (name)
ret = vfs_parse_fs_string(fc, "source",
name, strlen(name));
if (!ret)
ret = parse_monolithic_mount_data(fc, data);
if (!ret)
mnt = fc_mount(fc);
else
mnt = ERR_PTR(ret);
put_fs_context(fc);
and sys_mount() ends up passing the first argument as 'name' to
vfs_kern_mount(). That's it - nothing more to it.
