[cap-talk] Capability levels

[David Hopwood]

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.

> The "object" abstractions they deal with are direct data structures that
> they manipulate directly.

No, they're also structures in the virtual machine.

> -> Languages deal with objects on a machine instruction basis.
> 
> 2.  Operating systems manage resources that are generally external
> to running programs (executing at the "language" level).  Operating
> systems can deal with and accept a bit more latency/overhead, etc.
> because they have to already get "called"/invoked at some overhead
> (a domain change) before they even get into the act.  Operating systems
> support object abstractions for running processes.
> 
> -> Operating systems deal with objects on a system call (extended
> virtual instruction - higher level) basis.

But 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).

I don't see why latency/overhead is relevant here. 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.

> 3.  Networks deal with objects in terms of systems of communicating
> processes (active objects).  Here the overheads and latencies are again
> probably at least an order of magnitude higher.
> 
> -> Networks deal with objects on a network message basis.

Network facilities are supported in terms of operating system and language
abstractions; that's why they're at a higher level. Again, I don't consider
latency/overhead to have anything to do with this.

> 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.

[...]
> For me it seems that it could work out if we have some number of language
> level object representations (with translations/conversions - sort of like
> subroutine calling conventions).

Note that you don't need as many such representations as "surface languages".

In fact, you'd better not have very many capability representations (in
total, over all levels) if you want the whole system to be simple enough
to have any confidence that it is correct and secure.

> I would hope that we have fewer OS level
> representations, one for any system presumably running multiple languages.
> 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.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>