Messages in this thread | | | Date | Thu, 6 Aug 1998 13:55:14 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???) |
| |
Date: Thu, 6 Aug 1998 10:43:19 +1000 From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU>
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 least 20 or 30 messages to linux-kernel just in the last 18 hours. Most of the messages say the same thing over and over again, as they feel comprelled to reply to any argument that might say anything vaguely negative about devfs, even if they've already tried to make the identical point twenty times before. This is why I had originally given up trying to debate the issue on linux-kernel, and why think devfs is a lot 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 major device numbers. I know you (and others) don't like them, but many of the arguments against them are strawman arguments --- such as assuming that you will create all possible device files in /dev, whether or not the devices exist, and then complaining about the speed problem. Or by dismissing the reality that the dcache really does make the speed lookup problem pretty much irrelevant. (Yet in the last 18 hours, I can't count how many times I've just hit 'd' to messages which made the same flawed 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 saving this kind of state: permissions, user/group ownership, modtimes, etc. It's called a filesystem. Tar is an unmitigated hack; using a C program helps hide the fact that what you're doing is a hack, but it's still a hack.
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; the glibc interface already supports it. We know where to store the 32-bit device in the ext2 filesystem, and how to do so in a backwards compatible way; we have abstractions in place that should make it more or less painless to go to using 32-bit device numbers. It's a mere matter 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 a extremely flawed and weak argument. First of all, the vast majority of systems out there will only have less than 16 major devices. A typical system has less than 10 major devices. (cat /proc/devices and see!) So searching the list is simply not a problem. If searching the list were an issue, there are plenty of ways of solving this problem internal to the kernel, without needing to make any user-visible changes --- such using hash table.
We use hash tables for searching the inode cache --- you're not going to tell me that inode caches are bad just because a stupid implementation would have to sequentially search the entire list, are you?!? :-) This is what I call a strawman argument, and many of the devfs cheerleeders have been using such strawmans to argue their case.
- Ted
- 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.altern.org/andrebalsa/doc/lkml-faq.html
| |