On Thu, 13 Apr 2000, Richard Gooch wrote:
>Peter Samuelson writes:
...
>> I will not get draw into another devfs flamewar.
>> Sh*t.
>
>Tell me about it. You know, whatever happened to accepting the
>umpire's decision?
Because the umpire is wrong. I'm calling for an "instant replay."
devfs fixes some things and introduces a bunch of new problems. We need
a clear enumeration of what's wrong with the existing device name space
so that a clean, clear, and proper solution can be agreed upon. A little
PLANNING is a Good Thing. Spend some time think about the problem before
laying down code to make the problem, on the whole, worse. This is very
much the "jogging juggler" problem -- the solution is to learn to juggle
standing on the edge of a cliff.
There's a microscopic problem and a macroscopic problem. On the micro
scale, devfs deleted the static array of pointers to tables of pointers
to functions and maps the virtual file directly to the table of functions.
And it does so dynamically. So, in the case of a serial port, /dev/ttyS0
becomes /dev/ttys/0. The major and minor numbers no longer matter (or
even need to exist) and the previous static lookup tables are no more.
It's a faster method to reach the underlying serial.o working code. And
it uses kernel space less wastefully.
BUT, on the macro scale, isn't not so clean. It doesn't scale very well.
Previously, you'd be wasting a large number of on disk inodes. Now, you
waste a medium number of virtual inodes in non-swappable kernel memory.
You have the same hash overhead in directory lookups (ok, devfs is faster as
all of it always in memory.) Now that everything is in core, it's all
volatile and you have to resort to userland tricks (you actaully suggest
TAR!), kernel event messaging, and overlay filesystems to get the any
persistance or user control. [Can you say "kludge"? I knew that you could.]
Correct me if I'm wrong, but the multiple indirections to the operations
structure only occurs with open() and the function addresses are attached
to the file descriptor from that point on. So, what's the point in such an
expensive optimization? So the directory lookup returns a pointer into kernel
space instead of static major/minor numbers? There are far better ways to
get rid of major/minor numbers. [Tell me again why we don't want major
and minor numbers.]
Umm, would someone please enumerate _exactly_ what devfs brings to the table,
what we're trying to "fix" and why?
--Ricky
-
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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:25 EST