Messages in this thread | | | Date | 22 Jun 1999 23:18:00 +0200 | From | (Kai Henningsen) | Subject | Re: Some very thought-provoking ideas about OS architecture. |
| |
torvalds@transmeta.com (Linus Torvalds) wrote on 21.06.99 in <7klv72$kgh$1@palladium.transmeta.com>:
> In article <85256797.005DDAA9.00@D51MTA03.pok.ibm.com>, > <shapj@us.ibm.com> wrote: > >> Linus Torvalds wrote:
> >Moving a message from hither to yon *does* accomplish something: it moves a > >unit of work from one protection/encapsulation domain to another. > > Ehh.. In real operating systems, we call that event a "system call". > No message necessary or implied, unless you want to call the notion of > switching privilege domains "messages" (and some people do: they call > them messages just to prove that messages are as fast as system calls. > In logic, that's equivalent to proving that liver tastes as good as ice > cream by calling ice cream liver, and is in real life called "lying").
Personally, I'd call it confusing and inconsistent terminology. Or maybe confusing OS terminology and OO terminology. But anyone familiar with some of it should be able to understand which is meant from the context.
> That's why the OS boundary HAS to be equivalent to > > read(handle, buffer, size) > > and NOT be equivalent to > > handle->op(READ, buffer, size); > > because by definition, if you can do the "handle->op" lookup, then it's > not a OS boundary any more - or at least it is a very BAD one. See?
However, that's not how most OS boundaries actually look. Typically, they look like
syscall(SYS_read, handle, buffer, size)
but could just as easily look like
syscall(handle, OP_read, buffer, size)
It's not as if the idea of asking the handle about the operations were foreign to Linux, after all. That's what the VFS interface does (this time, with
file->f_op->read(file, buf, count, pos)
), and a number of other kernel-internal interfaces as well.
That is, asking a kernel object for a certain operations (also called "calling the object's method" or "sending the object a message" in various circles, but then those don't often seem to say "message passing") from user space, should mean doing a syscall(object handle, operation code, arguments).
There are actually good arguments for doing it this way, very similar to the Unix "everything is a file" idea - for example, you need just *one* end-this-object operation that can work to close files, drop semaphores, drop shared memory, what-have-you. (NT actually does this, it's called CloseHandle IIRC.)
It's not even that far from the Unix model. Just call everything a file handle, though it might be a funny kind. The real benefits, of course, come when you wonder "could I implement this operation for this kind of handle, too?". If you don't look at handles as objects, you might never think of it.
I've thought for a while I'd like to experiment with an OS where you had an OS boundary like this, but you could actually do IPC where you see an object in another process as such an OS handle. Of course, you'd need some kind of information on what the arguments look like so that the OS can actually move them to the other process, and it should still be efficient. Doing transparent remote communications from this model is fairly easy, just set up a proxy process. Nothing new there. You could of course do it in-kernel, but in-kernel RPC is not all that funny.
Well, someone probably has done it before. But still, an OS with built-in, efficient OO IPC would be interesting. And I see no reason why one couldn't build a perfectly compatible POSIX environment on top of that.
MfG Kai
- 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/
| |