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/