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.
- Ted
-
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:17 EST