[cap-talk] Capability levels

[David Hopwood]

Jed at Webstart wrote:
> 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 is not clear to me whether you're talking about the language
in which the OS itself is implemented, or the language in which an
API binding to the OS within a given process is implemented. (Even
if they are the "same" language, they are different instances of it.)

The structure is something like:


  |            Process 1                 | ... Process n  |
  |           /         \                |                |
  | (high level code)    \               |       ...      |
  |------------------.    \              |                |
  |  language impl.  | (low level code)  |                |
 -----------------------------------------------------------
  |                                                       |
  |          operating system implementation              |
  |              /                      \                 |
  |    (high level code)                 \                |
  |----------------------------------.    \               |
  |  system language implementation  |  (low level code)  |
 -----------------------------------------------------------
  |         hardware (or emulation of hardware)           |


I.e. the layering is "hardware \ language1 \ OS \ language2 \ application",
where "\" means "is below". From an application programmer's point of
view, and from the point of view of OS design rather than implementation,
however, "language1 \ OS" can be viewed as a single layer.

(The OS may be implemented in more than one language. Also, some of what
appears as "the OS" to application programmers may in fact be implemented
in per-process libraries, rather than in the kernel. But these are just
implementation details.)

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

Yes. Isn't that the most important point?

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

Can we agree on

  1. Hardware
  2. System language
  3. OS
  4. Application language
  5. Network

?

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