Alexander Viro writes:
> Alan, if we are talking about that sort of races we are in for a lot of
> fun with mount(8) and /etc/mtab. Not that it was that critical (personally
> I'ld rather see /etc/mtab dead), but the same arguments re legacy programs
> apply nicely.
Heh...
mount -t bind /proc/mounts /etc/mtab
> Yes, MNT_NOT_IF_ROOT makes sense. However, I'ld rather postpone that one
> until the decision on mount(2) interface (or the interface of whatever new
> syscall(s) will be used). I mean, just look at mount(8) syntax:
>
> We have -t <type> argument. Depending on the type we have different sets
> of -o <option> arguments available. -t is mandatory, unless there is a
> magical -o option - remount. If it's present -t _may_ be present, but is
This is indeed crap. If -t is the mount type (not fs type),
then it is obvious that "-t remount" should be used. This seems
much cleaner than ignoring -t and mixing remount in with the
regular filesystem options.
> ignored (in all honesty, wrong type should cause error). Set of -o options
> contains some that are translated into flags; the rest is passed to
> filesystem. The latter is fs-dependent and opaque both for mount(8) and
> sys_mount(). To add more fun, we'll need some syntax for loopbacks and
> unions, right? What with them - -t <fake_type>, -o <magic_option>? What on
> the kernel side - should they be turned into flags by caller?
There should be an option parser shared by all the filesystems.
Either the kernel tells mount about name-to-number mappings,
or the kernel accepts text.
There is no need to let "uid" mean "unique inode directory" for
some really sick filesystem.
> To add more fun to that - here's the situation with parsing the mount
> options:
> -o remount => flag, magic changes of syntax.
-t remount
> -o sync => flag, per-fs and pretty common.
> Otherwise VFS doesn't care much.
No, per-fs is not really good. Access via the async mount must
be sync if it interacts with access via the sync mount.
> -o mand => flag, per-fs and only VFS cares.
> -o noatime,nodiratime => flag, per-fs
Same as above: interaction between the mounts can force one
behavior as needed.
> -t bind => magic changes of syntax (my fault)
Don't think "bind is the filesystem type". Instead, think
"bind is the type of mount". Then this makes sense.
> crapload of fs-specific (and not-too-specific - e.g. -o uid=...)
> options, all parsed by fs drivers in all sorts of kludgy ways.
We need a shared parser.
> -o ???? => flag, allows multiple mounts
> -o ???? or -? => flag, gives you union mount (two of them,
> actually - depending on where we add a new component - head or tail).
Eeew, gross. Use -t for this.
> -o ???? (or nothing) => flag, gives you mount-trap.
Huh?
> NFS mount => opaque data containing a binary structure.
> ditto for other network filesystems, some of them with really
> kinky tricks since connection is passed unauthorized.
So, you want DNS in the kernel?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:17 EST