[cap-talk] Capability levels

[Jed at Webstart]

At 06:00 PM 8/11/2006, David Hopwood wrote:
>Jed at Webstart wrote:
> > At 01:27 PM 8/11/2006, David Hopwood wrote:
> >>Jed Donnelley wrote:
> >>
> >>> We've seen capabilities discussed (e.g. on this list) and implemented
> >>> at what I believe are three distinct levels, language (I'll refer
> >>> to as "low" level), OS (I'll refer to as "mid" level), and network
> >>> (I'll refer to as "high" level).  The Mach implementation seems to
> >>> fall into the mid category.
> >>
> >>That's an odd way of ordering the levels. OS is below language, normally.
> >
> > Here's my reasoning:
> >
> > 1.  Languages generate and ultimately execute direct machine instructions.
>
>Are you sure? ;-)
>
>These "machine" instructions are actually instructions in the virtual
>machine presented by the operating system. (This is true of any OS, not
>just a VMM-based OS.)
>
>The fact that *most of the time*, the instructions in this virtual machine
>correspond to hardware instructions and can be executed directly by the
>hardware, is simply an optimization.

It's an interesting point that you raise.  I think we both fully understand
the technical issues involved.

Let me put my position/argument this way:

The methods/modules/services that go into the operating system
implementation are typically made up of modules based on the
language abstraction level.  It may also be true that some of the
language methods/modules/services are based on abstractions
provided by the operating system.  However, I argue that even when
language methods are based on abstractions provided by the
operating system, they quickly become language level methods
that in some sense "incidentally" use higher level abstractions
(as you say virtual instructions) from the OS level.  The fact
that there is a protection domain change required to get to
the OS level (which has more "power") seems to me to be
pretty much irrelevant to the activities of the modules at the
language level.

I guess you're basing your argument on the issue of who's in
control?  I agree that the operating system is in control.  However,
I don't think that's particularly relevant to the level discussion.  You
could also say that the hardware level has yet a more over arching
level of control (e.g. microcode, etc.), but if I were to place the hardware
level into my suggested set of capability levels, I would do so as:

1.  Hardware,
2.  Language,
3.  OS,
4.  Network

e.g. rather than, say:

1.  OS,
2.  Hardware,
3.  Language,
4.  Network.

or even (anticipating a point below):

1.  Hardware,
2.  OS,
3.  Language,
4.  Network.

For me the most relevant factor is what level is closer to the 'bare metal.'
This in turn defines which abstractions (generally) are build on which others.

However, I think your argument is a good one and I'd like to hear more from
you and possibly others with their thoughts on this topic.  Maybe it really
doesn't make sense to try to "force" a hierarchy here where it can't be
well enough defined to make sense, or maybe I do just have the sense
inverted in this case.

>...the implementation of an OS runs on a lower-level virtual machine than
>the user code it supports (not necessarily bare hardware, but always one
>level lower than user code).

Perhaps I'm a bit unclear on the concept of "OS" in this discussion, and
maybe I shouldn't have used the term.

 From my perspective, the "OS" is just whatever's on the other side
of the invocation boundary (in capability terms), whether part of the
TCB (whatever that means in a capability sense) or not.  Among
Alice, Bob, and Carol, one might say that Carol is the more OS-like
(Carol provides a service for Alice and Bob).  In this sense the "OS"
is much like any other method that Alice or Bob might use.

On the other hand if you think of the "OS" as software/hardware that
implements the basic infrastructure for supporting invocations in general
(e.g. providing the basic IPC), then I think I would tend to fall into your
camp and argue that such a mechanism (micro kernel?) is indeed down
with the hardware level as being part of the base virtual machine.

Sorry if this seems a bit muddled.  If so, that's because it is for 
me.  Perhaps
others can add some clarity.

>I don't see why latency/overhead is relevant here.

Functionally I agree.  I was only using them as indicative of closeness
to the bare metal - as per my criteria above.

>Conceptually (which is
>what is most important, not the implementation), *every* instruction executed
>by a user program is mediated by the OS, not just the instructions that
>happen to cause a trap or context switch.

That's where I don't think I agree - though as I argue above I think it depends
on what one means by "OS".

> > 3.  Networks deal with objects in terms of systems of communicating
> > processes (active objects)...
>
>Network facilities are supported in terms of operating system and language
>abstractions; that's why they're at a higher level.

It seems we agree on that part of the level hierarchy.

> > Still seem odd?  Why do you suggest that OS is 'normally' below language?
>
>I qualified this with "normally" only because there are language-based
>operating systems, where language and OS abstractions are at the same level,
>roughly speaking. (At least, there is no difference in level visible to user
>code.)
>
>A more conventional OS implementation is always below the language level,
>as I argued above.

It still seems to me this depends on what one means by "the OS".  I agree that
any visible manifestations of a micro kernel seem to be "below" the language
level, but there are no capabilities in any such manifestations.  As far as
any capabilities provided at "the OS" level (by that I mean at the IPC between
processes/active object/domains level), for me those seem to fit in better
above the language level - as their inner parts are likely language 
level objects.

Just where "the OS" fits into the scheme of capability abstraction is a bit
unclear to me I admit.  Contributions welcome.

>[...]
> > I'm hopeful that we eventually get to a very small number of "standard"
> > object representations at the network level, as those have to be shared
> > across all systems, and languages --- below them.
>
>Notwithstanding the need for a small number of representations to reduce
>implementation complexity, it is more important to have common semantics
>than to have common representations.

I agree wholeheartedly.

--Jed http://www.webstart.com/jed/