> However, the second solution does have some advantages. Here they are,
> along with my objections to them. First, it allows arbitrary
> interesting things to be done in user space at mount time. However,
There are cases where this won't work. For instance, let's say my superFS
mount call requires some public-key authorization, using my personal
authentication daemon on my secure machine (look at ssh).
I do NOT think it's be a good idea to pass what's essentially an open file
descriptor (ssh can do it that way) through a mount program and kerneld to
a mountd thing which doesn't have access to the user's environment and thus
may not be able to determine whether the user is authorized to access that
particular file system.
> using kerneld, this can be achieved anyway. Second, if each fs type
Since mount is the only program which does this, kerneld is unnecessary.
-- If practice makes perfect, and nobody's perfect, why practice?-- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click <A HREF="http://info.noris.de/~smurf/finger">here</A>. 42