Ricky Beam writes:
> 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."
No, that's your opinion.
> 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.
You missed the planning I did over 2 years ago.
> 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.
Correct so far.
> BUT, on the macro scale, isn't not so clean. It doesn't scale very
> well.
Incorrect.
> 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.
The key factor you're missing is that the in-kernel inodes are
directly proportional to the amount of hard plugged in. A system with
a large number of devices plugged in will have a large amount of
memory. To do otherwise (devfs or no devfs) would be to construct an
extremely unbalanced system. Thus, devfs scales perfectly.
Furthermore, devfs is quite lightweight. It's memory consumption is
very low. It's only a few pages of code and a few pages of data on a
modest system (i.e. a couple of drives, sound card and about a dozen
other drivers).
> You have the same hash overhead in directory lookups (ok, devfs is
> faster as all of it always in memory.)
You ignore the fact that hash lookups will be faster because there are
far less inodes to deal with.
> 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.]
There is more than one method to have persistence. It's not just
tar. And using devfsd provides far more power and flexibility in
persmissions management than otherwise. You may see "kludge" but
others see a powerful system.
> 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?
Do avoid doing something fundamentally pointless.
> 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.]
Because they're really stupid. They require multiple independent
database to be kept in sync (the kernel sources, devices.txt,
MAKEDEV.sh, MAKEDEV.C and all the /dev directories out there).
Duplication of data like this always leads to errors.
> Umm, would someone please enumerate _exactly_ what devfs brings to
> the table, what we're trying to "fix" and why?
Try to grok the FAQ, and start listening instead of just being opposed
to it.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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:26 EST