I hope you don't feel I'm a fanatic. Yes, I strongly believe in the correctness of the idea. And I've not yet heard of practical solutions to all of the problems devfs fixes.

No, but certain devfs "cheerleaders" have been responsible for at least20 or 30 messages to linux-kernel just in the last 18 hours. Most ofthe messages say the same thing over and over again, as they feelcomprelled to reply to any argument that might say anything vaguelynegative about devfs, even if they've already tried to make theidentical point twenty times before. This is why I had originally givenup trying to debate the issue on linux-kernel, and why think devfs is alot like GGI in terms of the type of discussion it inspires.

1) devfs doesn't have to be mounted onto /dev if you don't like. The essential thing is that devfs provides a unique, logical namespace. You can always mount devfs elsewhere and make symlinks to it if you don't like the names

We already have a unique, logical namespace; it's called minor and majordevice numbers. I know you (and others) don't like them, but many ofthe arguments against them are strawman arguments --- such as assumingthat you will create all possible device files in /dev, whether or notthe devices exist, and then complaining about the speed problem. Or bydismissing the reality that the dcache really does make the speed lookupproblem pretty much irrelevant. (Yet in the last 18 hours, I can'tcount how many times I've just hit 'd' to messages which made the sameflawed arguments over and over again.)

2) which hacks are these? You mean using tar to save and restore the permissions? Would you prefer a C programme (something I'm contemplating doing)

Precisely. In Unix we have a very well developed abstraction for savingthis kind of state: permissions, user/group ownership, modtimes, etc.It's called a filesystem. Tar is an unmitigated hack; using a C programhelps hide the fact that what you're doing is a hack, but it's still ahack.

What about the problem of when we move to 16 bit majors and the major table is dropped and we go to searching a list when we open a device node? How do you suggest we solve that?

Going to 32-bit device numbers can be easily done during Linux 2.3; theglibc interface already supports it. We know where to store the 32-bitdevice in the ext2 filesystem, and how to do so in a backwardscompatible way; we have abstractions in place that should make it moreor less painless to go to using 32-bit device numbers. It's a merematter of programming, and it isn't a lot of programming at that.

As far as searching a list when we open a major number, again this is aextremely flawed and weak argument. First of all, the vast majority ofsystems out there will only have less than 16 major devices. A typicalsystem has less than 10 major devices. (cat /proc/devices and see!) Sosearching the list is simply not a problem. If searching the list werean issue, there are plenty of ways of solving this problem internal tothe kernel, without needing to make any user-visible changes --- suchusing hash table.

We use hash tables for searching the inode cache --- you're not going totell me that inode caches are bad just because a stupid implementationwould have to sequentially search the entire list, are you?!? :-) Thisis what I call a strawman argument, and many of the devfs cheerleedershave been using such strawmans to argue their case.