Messages in this thread | | | Date | Thu, 24 Jun 1999 12:37:34 -0400 (edt) | From | Sam Roberts <> | Subject | Re: Some very thought-provoking ideas about OS architecture. |
| |
Previously, Linus Torvalds wrote in list.linux.kernel: > > [snip] > In short: message passing as the fundamental operation of the OS is just > an excercise in computer science masturbation. It may feel good, but > you don't actually get anything DONE. Nobody has ever shown that it > made sense in the real world. It's basically just much simpler and > saner to have a function call interface, and for operations that are > non-local it gets transparently _promoted_ to a message. There's no > reason why it should be considered to be a message when it starts out. > > Linus >
and > [snip] > The issue is not how you get the data from one place to the other: > "read()" is as good as way as "rcv()". Message passing is not the issue. > > The real issue is _naming_, and that's not going away. The name space has > always been the difficult part. And that's where I agree that UNIX could > do better: I think we do want to move into a "web direction" where you can > just do a open("http://ssss.yyyyy.dd/~silly", O_RDONLY) and it does the > right thing.
QNX4 is not an excercise of any kind, it is hugely popular (outside of the server (dominated by Unix) and desktop(...) markets) and used by people whos interest is in getting there work done well, now, not in O/S theory. BeOS and Plan9 are less commercially successful, but do their jobs well. The days when micro-kernels were university toys are past, as are the days when Unix was university toy.
You and most of the posters are assuming that message passing means *asynchronous* message passing. What about synchronous message passing?
QNX4 is based on synchronous send/receive/reply messaging. The synchronicity means that message buffer management doesn't need to be done anymore, the source process is blocked until the message is delivered, processed and replied to. The source location of the message *is* the buffer, safely (because that process can't run). Asynchronous messaging is easy to build on top of this, but not all message passing has to pay its performace price.
That these messages map simple to Unix style system calls is good, it makes it easy to support the POSIX API, and port software and programmers.
That these messages are naturally routed over a network is great, but you can do this in-kernel by translating system calls to messages (ioctls are always a problem, of course).
That they're not as unidirectional as pipes and make it easy to implement systems as groups of co-operating processes is great, but that can be done by implementing a message passing library (either in-kernel, like I have for Linux, or as a library).
The *real* advantage of message passing is that you no longer have to bind *independent* subsystems into the kernel, the immediate target of all system calls in a system-call based OS. Why does serial device I/O have to thread through the same code and locks as file I/O, as networking?
The *real* issue is "naming" and implementing of services such as an http file system (which you mention), such as a CODA fs, drivers, etc. outside of the kernel.
IMO, micro-kernel message-passing systems make doing this *easy* and *natural*. That doesn't mean you can't do it in a a macro-kernel, but when the OS supports what you want to do, your life becomes easier.
Is it slower? I've only started working with Linux (as opposed to running file/mail servers) recently, so I haven't benchmarked it. I can say that QNX is very fast, and has put the work into optimization of message passing and context switching thats necessary for a system that makes them the basis of everything.
Linux is moving this way, but could do so more agressively. Devfs is a start.
Notice how there are two classes of appication in Linux? Theres user-space apps, and kernel-space apps (knfsd, sound drivers, etc.). Because if you want something to be fast, or if you want to implement the open/write/read/... API you *must* be a kernel-app, thus more and more kernel code gets written (and nobody can stop it, Linux is open-source, and programmers do what gets the job done).
People keep arguing about whether or not you can do it in user-space. This is the wrong debate. The question is "can I export my services so is available are available using an open/read/write/..?". If the answer is yes, then you should, because thats one of the unifying principles in the Unix API/architecture, and it works really well. And if you should, then you need to put your app/servicer/call-it-what-you-will in kernel space.
There is not now, and never will be, a one true O/S architecture. Like good languages, each architecture facilitates certain types of design models, and make possible others. However, that there are more shipped macro-kernels right now has more to do with marketing, and company inertia, than technical merits.
Sam
-- Sam Roberts (sam@cogent.ca), Cogent Real-Time Systems (www.cogent.ca) "News is very popular among its readers." - RFC 977 (NNTP)
- 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/
| |