Theodore Y. Ts'o wrote:
> When you create /home/ftp/dev/null, etc. you are not creating a limited
> "view" of some database; you are created a directory of special files
> which are required for user programs to function correctly in a chroot
> jail. Again, nothing more, nothing less.
>
> This idea that /dev should be a "database" is not a traditional Unix
> view, and given that files in the /dev directory do have user state,
> such as permissions, user and group ownerships, etc. that need to
> survive device insertion and deletion, it drives this point home quite
> forcefully.
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.
On the other hand, after about 10 minutes, someone will want to
implement a configuration file which says that disc should be spelled
disk, allowing better control over what actually gets done. Time for
a perl script.
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.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of * ****** prejudices acquired by age eighteen. -- Albert Einstein ********- 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:16 EST