Date: Mon, 22 May 2000 09:07:11 -0400 From: "Theodore Y. Ts'o" <tytso@MIT.EDU> To: jmcmullan@linuxcare.com Subject: Re: devfs - the missing link 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/