lkml.org 
[lkml]   [1998]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [from the cache]
©2003-2011 Jasper Spaans