lkml.org 
[lkml]   [1999]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.082 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site