> > - 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 /devb) use devfs and don't agree w/ naming/perms so choose to manually modify /dev;use rc.whatever or devfsdc) don't use devfs and run MAKEDEV and don't need to mangle /devd) don't use devfs and run MAKEDEV and don't agree w/ naming/perms and modrc.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 thatdoes a certain thing that the point is moot. i am a somebody that does thatcertain thing; hot swap all day long. two nifty and very handy things associatedwith swapping pcmcia cards and usb devices.

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

> > - 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 tomove drives, in my case, removable media and non-powered media on scsi chainschanges 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.

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

> > - 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/minorfor my widgets. i don't have to go update MAKEDEV and make a big notice toeveryone. /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 makea large action list for the kernel and devfsd to talk and update confs. looktoward quota and see how it interacts with on disk files and in core. start upand shut down are your disk factor. nothing else unless you choose to sync. idon'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 timeshas 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 devfsis ultimately perfect and it never need be changed again. heck, look at thefirewalling. we have iptables now. in the last five years we have had threemajorly different and incompatible ways of dealing with firewalling. all of itis made easy for userland by scripts and whatnot, and in core is made moreextensible and easy to manipulate. the majority of people are probably satisfiedwith their permissions in /dev and won't use devfsd. for those who aren't likeyourself, there are options. permissions can be easily set in the kernel make aswell. just like cpu selection is or ethernet card is or etc. one can be courseabout it and have "open" and "paranoid" permission groups or can be fine grainedlike soundcard and say specify precise perm values. you can even have a rangeinbetween 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 worldwidethat we manage. devfs has enabled me to save a few minutes here and therefrequently and not worry about /dev updates. over time, that translates to a lotof saved time. i've been using devfs for over a year now and i honestly saythat i don't worry about /dev and my troubles with adding devfs to the kernel areby 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 costsinvolved 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 personallyand a significantly lower accumulated load for that one class of servers thatstats /dev/ a lot.

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

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

-d

-- 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" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/