From: jmcmullan@linuxcare.com
Date: 22 May 2000 05:37:03 GMT
The primary UNIX tradition is "Everything's a File(tm)". This
architectural guideline has helped UNIX stay (internally) pretty
clean for the last 25 years. We should stay with that principle,
but we should look at what UNIX has gathered to itself over the
years, as we may want to ``prune the tree'' for Linux 3.0.
That's certainly not the only Unix tradition, and I'm very doubtful it's
even the primary tradition. A much more important one IMO is "minimize
what's done in the kernel", and "don't put policy in the kernel".
For example, just because you *can* put something as a file doesn't mean
that you should. I assume --- I *hope*! --- everyone understands why it
would be insane for "ls -lR /ipv4/mit.edu" to make the kernel do a DNS
Zone transfer, and then display all 100,000+ hosts at MIT as a directory
listing.
First of all, DNS resolution belongs in user space. It doesn't belong
in the kernel. And if that means that we can't expose it as a
filesystem. And secondly, that's probably just as well, since
supporting readdir() on a domain --- causing massive zone transfers all
the time --- would probably not be good for the state of the internet's
nameservers.
So just because you *can* put something in the kernel or access it via a
filesystem, doesn't mean that you *should*. Minimizing what has to be
implemented in the kernel is just as important a Unix tradition, if not
more important. Only put what has to be in the kernel into the kernel
--- and no more!
Device drivers should present, through a consitient API
(my preference being a filesystem) everything that an
application needs to use the device in a manner that is
consistient, and safe to the integrity of the system.
Repeat after me. Filesystems are not API's. It's a really, really,
really bad idea to tie an API to a filesystem.
It's much better to design a well-crafted library abstraction which
provides the functionality which it needs. That way, you get OS
portability, and it makes it a lot easier to deal with changing
functional requirements. You can much more easily make changes to a
library interface --- keeping old interfaces around for backwards
compatibility --- than you can with a filesystem API. (We're now on our
what, 2nd or 3rd devfs namespace at this point?)
Backwards compatibility simply far easier to support when using a C
library than when you try to use a filesystem to support it. One of the
things which a filesystem abstraction was not designed to do well is to
support changing interfaces.
By adding this library layer, it means that we can make changes to the
kernel interface without having to make changes to every single user
program in existence --- an almost impossible task. Instead, we simply
only have to make changes in a singe place --- the library --- and all
the rest follows.
- 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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:21 EST