Re: devfs

[Steven Pritchard <steve@silug.org>]

On Tue, Jun 03, 2003 at 03:08:02PM -0500, john doe wrote:
> im actually starting the process of writing that automounter deal i was 
> talking about earlier.  someone told me devfs has a userspace daemon that 
> can flag another process when devices are added/removed/etc...

That's what hotplug is for.  See the hotplug(8) man page and the
scripts in /etc/hotplug.

> what i know of devfs (other than having heard its name tossed around) is 
> that nodes are only created when something is actually there.  dont know 
> about any problems with it, but i do think that having thousands of device 
> nodes in /dev that are attached to nothing is a bad thing (but not knowing 
> all that much about devfs i dont knwo if its the correct solution either).

You have all those device nodes in order to support a ton of random
hardware that you *might* want to use.  It's the same reason you have
30MB of modules on a current Red Hat system...

BTW, you aren't exactly wasting a lot of space with all those device
files...

    osiris:~$ du -hs /dev
    432K    /dev

I'm in the camp that thinks devfs is just a mistake...  It moves
policy into the kernel that doesn't belong there.  That's besides the
problems with the implementation...

Now that's not to say that I think the concept is *all* bad...  If
devfs-enabled kernels would work correctly with non-devfs systems, I
could see having a /devices or something, similar to /proc, but with
information about what devices actually exist on a system, without any
of the silly naming issues that calling it /dev come with.  (I mean
really, do you need the kernel to remember to create /dev/null,
/dev/zero, and all the other random devices that a Linux box *will*
have?)  I get the impression that this is what sysfs/driverfs in 2.5.x
is about, but I haven't looked at it enough yet to know for sure...

Steve
-- 
steve@silug.org           | Southern Illinois Linux Users Group
(618)398-7360             | See web site for meeting details.
Steven Pritchard          | http://www.silug.org/

-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.