It's happened before, it will happen again. However, you had better come
up with a better argument before I believe it happened this time.
>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").
The system call may be turned into a message later if that turns out to
be a good idea, but it's nothing inherent. AND IT SHOULD NOT BE.
>So: even if you think that message passing is not the way you wish to implement
>things, object based APIs offer greater flexibility of implementation, and this
>is generally a good thing.
Object-based API's are a completely different issue (I removed your
argument, because I think it is completely irrelevant to "messages").
I don't think object-based approaches are bad. A lot of libraries
("stdio" in C) are based on that notion, and it's often the right way to
encapsulate information in user space.
HOWEVER: that is not an OS boundary, and should not be considered to be
one. The _definition_ of a OS boundary is the boundary of protection
domains: the OS takes over where the library no longer has the
appropriate privileges to access the object any more. Because if the
library could do the operation, it should - instead of bothering the OS
with it.
So in effect, at the OS boundary the object has to be pretty much
completely opaque, or it shouldn't be considered an OS boundary in the
first place. QED.
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?
Linus
-
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/