On 17 Apr 2000, david parsons wrote:
> I'd think it would be somewhat better to patch devfs so that it can
> only be mounted once (as a quick fix to the technical issues that
> are now being mentioned; if there are other technical issues with
Erm... David, unfortunately Richard wants to be able to have subsets of
the tree to be mounted in chroot jails. It's trivial if we just
union-mount pieces (each piece shared between all mountpoints where it's
going to be visible) and it's a huge PITA if we keep them as parts of one
fs. Notice that all _code_ may be very well shared - just that you want to
have a separate struct super_block and a dentry tree for each piece.
Basically that's the how Richard had managed to piss me off _big_ _way_ -
he had heard about that problem many times and he just keeps ignoring it.
[union-mount]
> This, on the other hand, is a non-ick, since a working union-mount
> would be a Good Thing, and perhaps a larger body of code that
> requires it would shake it out. (Though if Al Viro is the only
> person working on it, me might not appreciate the extra stress.
> Hopefully RH is keeping his office well stocked with devfs voodoo
> dolls)
union-mount (as opposed to unionfs) is the part of these changes. As for
voodoo dolls - nah. Not needed. That's what lusers are for.
> david parsons \bi/ automount. Shudder.
Shudder, indeed. Now, guess what devfs _already_ contains? Right-o. Close
analog of automount, complete with the userland daemon, yodda, yodda. IOW,
it's the same kind of problem, same kind of gotchas and these beasts
really ought to be joined - autofs misses several pieces of functionality
needed for the stuff wanted by devfs. Easier to merge them than to keep
two independent pieces of code that do subsets of the same thing, each
with its own warts.
_If_ we are getting a unform facility that would pass
lookups/revalidations on given dentries/in given directories/etc. to the
userland daemon and provide the list of non-busy filesystems (doable
without tree-walking, BTW) - then both autofs and relevant pieces of devfs
become trivial. And I can easily see dozen of other applications for the
same thing.
Then devfs can really forget about directory-related code - it
will be the same as for devpts/kernfs/shmfs/ramfs/etc. Literally the same,
I mean.
-
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 : Sun Apr 23 2000 - 21:00:12 EST