On Thu, Apr 20, 2000, Theodore Y. Ts'o <tytso@MIT.EDU> wrote:
> Date: Thu, 20 Apr 2000 11:15:05 +0200 (MEST)
> From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
>
> Building on this, shouldn't devfs (which then shouldn't be called
> devfs) just publish a list of attached devices, node numbers and
> "recommended permissions"?
>
> From that you can write a simple bash script that will read all the
> devices and create nodes for them.
>
> After 30 more minutes, the number of feature requests for this program
> is enough to warrant a C implementation. Fine.
>
> As we've come to the conclusion that a devfsd is a necessity, the
> "extra" deamon cannot be considered a problem. Moreover, this is just
> a "at boot time" thing that needs to run. You get back your process
> slot once it is done.
>
> Looking at it this way, to me feels like everything suddenly clicks
> into place.
>
> At first, the kernel publishing the attached devices sounds like a
> good idea. And a "filesystem" sounds like the obviously correct way to
> export that info. However, the permissions issue complicates it to the
> point where the "publish as a filesystem" policy should be
> reconsidered.
>
> That's basically right (as far as I'm concerned), although the daemon
> does have to be continuously running, to deal with hot-swap devices.
> It's the design I've always thought was the right one.
>
> People kept on saying that using a filesystem was the right approach,
> because the using a user-mode daemon "was too complicated", and then
> when people started pointing out shortcomings, the answer was "use
> devfsd". But after kludge after kludge started getting poured into
> devfsd (or into the VFS, which was Richard Gooch's latest attempt to
> work around this problem) to deal with the fact that there really is
> persistent state in /dev that needs to survive device insertion and
> removal, not to mention reboots ---- you have to start wondering which
> approach is really the more complicated one.
It's much more straightforward to save permissions somewhere and then
restore them when the system reboots than creating a solution to use
major/minor cookies or some other kludged solution around the
major/minor problem.
JE
-
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:18 EST