[lkml]   [1999]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[OT] DEVFS, pros, cons, how it makes life better
[Offtopic tag added for reader convenience]

> > - it doesn't impact drivers unless the developer chooses to use devfs
> If the _user_ uses devfs, the _developer_ has to provide it. A halfway
> system is worse than each alternative on its own.

yes, just like SMP. and the impact is very trivial.

> > - it doesn't impact system adminstration unless you enable the feature
> But does when enabled. One more variable to consider on each support call.

four options:

a) use devfs and don't need to mangle /dev
b) use devfs and don't agree w/ naming/perms so choose to manually modify /dev;
use rc.whatever or devfsd
c) don't use devfs and run MAKEDEV and don't need to mangle /dev
d) don't use devfs and run MAKEDEV and don't agree w/ naming/perms and mod
rc.whatever or /dev

ab and cd are very similar save that ab has one less step. consider that you
_know_ in each support call that the naming and major/minor are current.

> I've never said that everybody is like me. I'm careful to talk about my
> experience, and what I have seen. As far, nobody at all has stepped forward
> telling the grueling story of his machine with hundreds of devices that
> change minute by minute, so I'd have to assume that this doesn't exist, or
> in any case is so marginal that any impact at all on the kernel used by
> millions that don't have any use for the feature is out.

in an earlier email you point out that because you have never met anyone that
does a certain thing that the point is moot. i am a somebody that does that
certain thing; hot swap all day long. two nifty and very handy things associated
with swapping pcmcia cards and usb devices.

> > - gives sensible names to devices (c1t3d0s2 instead of sde)
> Change MAKEDEV, be my guest.

c1t3d0s2 will always be c1t3d0s2 whereas sde will change depending on how many
other drives come before it. and UUID is not a workable solution for non-RW

> > - eliminates scsi ordering problems because of sensible names
> /dev/c1t3d0s2 becomes /dev/c2t3d0s2 when you move the controller, and
> adding a new disk gets you to /dev/c2t4d0s2. How does this solve the "sdc is
> now sdb" problem?

moving the controller is one issue that remains, however most people appear to
move drives, in my case, removable media and non-powered media on scsi chains
changes the continuity of my drives.

> Check mount(8), options -L, -U for a solution to this.

cdroms have different labels and no uuid. devfs cleanly keeps it ordered.

> > - completely eliminates major/minor number problems
> Can't do that, because it is deeply ingrained into the kernel's way of
> handling devices.

and devfs is a direction away from them.

> > - moves naming complexity INTO USER SPACE (good for usb)
> MAKEDEV is user space.

manual v.s. automatic

> > - user space scripts ran on insertion (just like cardmgr/PCMCIA)
> Can be done (sort of) with modules and pre- post- scripts. Not nice.

similar to kmod, no? devfsd again can be like quota utils and update an incore

> > - UNIX-like /dev without UNIX-like rw fs (good for embedding on romfs)
> ROMFS is designed to be _small_, not full-Unix. I'd guess adding device
> nodes to ROMFS won't make it much larger. Surely much less than devfs and
> its bloat in all devices by itself.

devfs is not bloated.

> > - provides a proper namespace (no need for recent rash of /proc/*/dev)
> If you can't provide a proper namespace in /dev, then doing it as a fake
> filesystem is out anyway.

let's wonder for a bit. i am a developer of a widget. i change my major/minor
for my widgets. i don't have to go update MAKEDEV and make a big notice to
everyone. /dev will always have the naming constructs that i use in my code.

> > Notice that all of these problems can be solved in other ways (for example
> > you can solve the sde -> c1t3d0s2 problems using a startup script, similar
> > to how Solaris populates /dev) but devfs solves ALL of the problems in one
> > fell swoop.
> That isn't exactly right. As said above, it does not solve all problems.
> Plus the naming problem is still there, it is just shifted from MAKEDEV
> (yuck!) to either another configuration file (same yuck!) or the driver

in my case, i have never needed devfsd. in an earlier email you managed to make
a large action list for the kernel and devfsd to talk and update confs. look
toward quota and see how it interacts with on disk files and in core. start up
and shut down are your disk factor. nothing else unless you choose to sync. i
don't know of many people that lmbench startup and shutdown.

> unless you prefer to live in a vacuum. Also, if something solves several
> problems in one fell swoop _without_ adding strange klugdes and needing
> extra machinery, it's an elegant solution (the conception behind Unix is a

how many iterations of the F00F bug solution did we run through? how many times
has the way SMP been done in the kernel been changed, or VM, or VFS?

"version 1" normally leads to "version 2". we would be silly to think that devfs
is ultimately perfect and it never need be changed again. heck, look at the
firewalling. we have iptables now. in the last five years we have had three
majorly different and incompatible ways of dealing with firewalling. all of it
is made easy for userland by scripts and whatnot, and in core is made more
extensible and easy to manipulate. the majority of people are probably satisfied
with their permissions in /dev and won't use devfsd. for those who aren't like
yourself, there are options. permissions can be easily set in the kernel make as
well. just like cpu selection is or ethernet card is or etc. one can be course
about it and have "open" and "paranoid" permission groups or can be fine grained
like soundcard and say specify precise perm values. you can even have a range
inbetween these.

> fine example). If not, it's just exchanging one mess for another one. My
> fear here is that devfs exchanges an acknowledged mess, which we know and
> over time learned how to handle in a reasonable way; with a much larger
> mess, one with unknown quirks that will have to be worked around. All for
> no real gain.

i compile new kernels several times a day for the hundreds of systems worldwide
that we manage. devfs has enabled me to save a few minutes here and there
frequently and not worry about /dev updates. over time, that translates to a lot
of saved time. i've been using devfs for over a year now and i honestly say
that i don't worry about /dev and my troubles with adding devfs to the kernel are
by large "patch -p1 < devfs...". that's a trouble i can sleep with most easily.

> Yes, I did. But if the costs involved are smaller than the benefits, go for
> it. If not, leave it alone. In this case, as no pressing need has surfaced,
> and no clear benefits have been shown, leave it alone.

many of my peers use devfs and none of us have issues to deal with. the costs
involved to date are a small amount of time during the week for one man,
Richard. for the work that he has done, my benefits mean saving time personally
and a significantly lower accumulated load for that one class of servers that
stats /dev/ a lot.

for you the benefits aren't clear and for me the benefits are very clear. it
solves a variety of little issues. little issues compounded by numerous systems
makes for a lot of frustration and time.

we have a bunch of stuff in the kernel such as AX.25 and IPX because it benefits
someone. i'm probably correct in that they don't benefit you. nor do they
benefit me. but i will staunchly support them just as i do devfs.


This is Linux Country. On a quiet night, you can hear Windows NT reboot!
Do you remember how to -think- ? Do you remember how to experiment? Linux
__ is an operating system that brings back the fun and adventure in computing.
\/ for linux-kernel: please read linux/Documentation/* before posting problems

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:54    [W:0.086 / U:4.924 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site