shap 01/01/26 15:51:51
Modified: src/doc/www/devel/ProgGuide Cover.html capidl.html
Log:
Capture differences between CapIDL and CorbaIDL
Revision Changes Path
1.12 +10 -3 eros/src/doc/www/devel/ProgGuide/Cover.html
Index: Cover.html
===================================================================
RCS file: /cvs/eros/src/doc/www/devel/ProgGuide/Cover.html,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- Cover.html 2001/01/26 19:14:50 1.11
+++ Cover.html 2001/01/26 20:51:50 1.12
@@ -28,8 +28,7 @@
<br><a href="hll-key.html">Capability Support in High-Level
Languages</a>
<br>
- <br><a href="idl.html">Capability Support in High-Level
- Languages</a>
+ <br><a href="capidl.html">Capability IDL</a>
<br>
</td>
<td width="5%"> </td>
@@ -99,9 +98,17 @@
handle large numbers of capabilities.
</p>
</li>
+ <li>
+ <p>
+ <a href="capidl.html"><em>Capability IDL</em></a>
+ Describes the EROS Interface Definition Language,
+ which is used to define capability types and object
+ interfaces.
+ </p>
+ </li>
</ol>
<hr>
- <em>Copyright 1998 by Jonathan Shapiro. All rights
+ <em>Copyright 2001 by Jonathan Shapiro. All rights
reserved. For terms of redistribution, see the <a
href="../../legal/license/GPL.html">EROS License
Agreement</a></em>
1.2 +98 -378 eros/src/doc/www/devel/ProgGuide/capidl.html
Index: capidl.html
===================================================================
RCS file: /cvs/eros/src/doc/www/devel/ProgGuide/capidl.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- capidl.html 2001/01/26 19:15:29 1.1
+++ capidl.html 2001/01/26 20:51:50 1.2
@@ -1,4 +1,4 @@
-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Strict//EN">
EPG: Capability IDL
@@ -38,20 +38,19 @@
be dated or incomplete.
- CapIDL is the interface description language used
- to describe object interfaces in the EROS system. CapIDL
- is derived from the CORBA IDL (version 2.4.1), but has
- been modified to meet the particular needs of capability
- systems. Several features of the CORBA IDL have been
- removed, and a small number of features (and syntax)
- specific to capability systems have been added.
+ CapIDL is the interface definition language used to
+ describe objects in the EROS system. Most programs in EROS
+ export one or more object types. Each of these types of
+ object has an associated capability type. CapIDL provides
+ a uniform way of describing the methods, attributes, and
+ behavior of these objects.
- Developers who are already familiar with CORBA IDL
- specifications may find that the sections An IDL For Capabilities and How CapIDL differs from CORBA IDL
- provide enough information to get productively started.
+ provides enough information to get productivelystarted.
An IDL for Capabilities
@@ -68,426 +67,146 @@
The usual purpose of an IDL is to specify interfaces
- between components subsystems in a language-neutral way. Typically,
- IDLs make no assumptions about how these components are
+ between components subsystems in a language-neutral
+ way. Typically, IDLs make no assumptions about how these
+ components are ...
How CapIDL differs from CORBA IDL
- because they are inappropriate in capability
- systems. A few have been added because we needed
- particular support for something that CORBA did not
- consider. In almost all cases the added facilities are
- ``optional,'' and will
-
-
-In
- particular, a client implemented in one language
- (e.g. Java) should be able to invoke a service implemented
- in another (e.g. C) by invoking the service according to
- an interface that is specified in a common neutral
- language. CapIDL is such a neutral language.
-
-
- An IDL ``system'' consists of a
-
-
- CapIDL is an interface description language that is
- particularly targeted at capability systems.
- In other
- IDLs, and ``interface'' is merely a description of the
- protocol supported by a given service. Clients and servers
- might communicate over a number of transports
-
-CapIDL, an
- ``interface'' describes
+ CapIDL is derived from the OMG/CORBA IDL version 2.4.1,
+ but it has been specialized in various ways to meet the
+ needs of capability systems. This section briefly
+ summarizes the differences. We first describe the one
+ major conceptual differences, and then identify various
+ minor changes.
+
+ Interfaces are Types
+
+ The biggest difference is that in CapIDL the notion of an
+ "interface" has been unified with the notion of a
+ capability. In conventional IDLs, an interface is merely a
+ set of entry points that are published by a service
+ program. In capability systems, service programs can
+ export several different interfaces as different
+ capabilities, and each of these interfaces is associated
+ with a particular capability type. Another way to say this
+ is that interface boundaries in capability systems are
+ strongly enforced.
-
- reading the sections features in the CORBA IDL are absent
- in CapIDL. a few have been regularized in a more sensible
- form. have been removed
-
- If you are trying to
- write real programs, it's useful to know what the state
- of the world is when the program begins excution. This
- page provides a description of how the usual EROS
- runtime mechanism works. The EROS kernel is not
- responsible for process construction; it is therefore
- not a party to any startup conventions about these
- programs. It is possible to build many different
- startup conventions. This is useful primarily for the
- sake of environment emulation.
The description
- given here describes the startup and shutdown
- conventions for native EROS programs. More
- specifically, this page describes the convention that is
- assumed by the EROS Constructor.
- There are a few primordial processes that implement
- these conventions a bit differently.
Briefly, the
- programmer's view of process startup is fairly
- straightforward. When the program's main()
- procedure is entered, the program has a well-defined set
- of initial capabilities in it's capability registers.
- The program performs any necessary initialization and
- becomes available for requests. At some later time, the
- process will be told to destroy itself, and will return
- a final result code. The following notes walk through
- the initialization and teardown of processes.
-
1. Process Fabrication
EROS programs are
- usually built by constructors, and the construction
- process if typically recursive. In the common case, even
- the process address space is constructed by another
- constructor. This leads to apparently conflicting
- objectives:
+
+ There are two corollaries to this:
- The constructor cannot recursively invoke these - constructors, because their runtime is potentially - long, and it is undesirable for the process's - constructor to be busy for long periods of time - (principle: make the customer pay for it). + Because there is no common supertype between + capabilities and data, CapIDL does not include an + ANY keyword. The Object type remains, + and means ``any interface type.'' That is: ``any + capability type''
- The program cannot initialize itself without an - address space. + An interface identifier is now a type + name. Specifically, it is the type name for the + capability type corresponding to that interface.
- To resolve this conflict, process fabrication is done by a - temporary program known as the protospace - from within the new process itself. -
-- To minimize confusion, imagine that the program we are - trying to fabricate will be called foo, - and the address space for this program will be called - foospace. -
-- The first stage is to construct the shell of the new - process and populate it with the protospace program. This - proceeds as follows: -
-- The foo constructor buys a new process from it's - process creator. This process is unpopulated, so it's - really just the framework for a process. -
-- The foo constructor populates the key registers of - this nascent process as follows: -
-| KR0 | -A zero number key. Key register zero always - holds a zero number key. This value is hard-wired, and - cannot be changed by the program. | -
| KR1 | -A read-only capage key to the - process's initial services. | -
| KR2 | -A process key to the process - itself. | -
| KR3 | -A start key to the process's process - creator. | -
| KR4 | -A start key to the process's space - bank. | -
| KR5 | -A duplicate of the process's schedule - key. | -
| KR6 | -A constructor key to the constructor for the - process's keeper. | -
| KR7 | -A constructor key to the constructor for the process's - address space, or the address space key itself. | -
| KR8 | -A number key containing the initial program counter for - the foo program. | -
| KR9..KR14 | -Zero number keys. | -
| KR15 | -A resume key to the process that - caused this process to be started. | -
- This initial process image runs under the schedule - designated by the requesting process. It's address - space is a read-only page key to an immutable - address space known as the - protospace. -
-- The initial process has no keeper. -
-- Control is now transferred to the - protospace program. Protospace is - most reasonably thought of as part of the constructor - logic. The proper protospace entry point is well - known to the constructor. -
-- Protospace must now construct the initial address space - and keeper for the new process: -
-- Protospace Fabricates the program's address space - segment by invoking the address space constructor key - (in this case the foospace constructor). -
-- Protospace then overwrites the keys in slots KR7..KR8 - with zero number keys; these keys will not be passed - to the foo program unless they are included in the - initial services capage. -
-- Finally, the protospace invokes the process key with - the "swap space and PC" invocation, setting the - address space of the process to the real address space - (the foo address space) and the real entry point (the - foo entry point). -
-- Execution of the real program begins. -
-- On entry, the new process inherits the key register state - that was left by the protospace. This is identical to the - initial key registers described above, except that - register KR7 and KR8 - hold zero number keys. -
-- Depending on the type of address space used for this - process, the process may have no stack. Three options are - supported by the current run-time libraries: + In CapIDL, all constant computations are performed using + arbitrary precision two's complement integer + arithmetic. The results are then truncated apropriately + for the destination type.
- ++ In practice, this has very little impact. It can, however, + lead to surprises in a few specific circumstances: +
- The address space is immutable, in which case having - no stack is appropriate. A small number of primordial - programs run from an immutable address space. + Arithmetic operations between signed and unsigned + types are always performed using signed arithmetic.
- The address space is a small space (i.e. one that does - not have a keeper). In this case the space is - initially immutable, but the runtime startup code - immediately constructs a mutable stack. The process - destruction logic assumes that a mutable space is 16 - pages or less, with the stack at the top. Small - spaces are provided primarily as a convenience for - small utility domains, and are not suited to the - construction of large service programs. + Casts to unsigned depending on bit representation + don't work. In particular, the preferred way to + specify the most negative value of an integer type' is + to use the new min and max operators:
++min(long) /* minimum signed 32-bit quantity */ +max(unsigned short) /* max unsigned 16-bit quantity */ +min(integer<8>) /* minimum signed 8-bit quantity */ ++
- The address space is a virtual-copy space, in which - case the stack will be automatically filled in as page - faults occur. -
-
- The run-time library determines the type of the address
- space by examining the global variable
- __rt_StackPages. This variable should be a
- read-only variable initialized at compile time, and
- contains the total number of stack pages that should be
- allocated. Immutable spaces should simply set this value
- to zero. Demand-allocated spaces should set it to some
- value greater than 15.
-
- Once the stack is allocated initialized, the run-time
- library branches to __rt_start(), which is
- intended to give the high-level language runtime a chance
- to perform further initialization before invoking
- main().
-
- If necessary, the process must arrange to call on it's own - behalf any constructors whose products it may need. -
-- Just as the process must arrange to initialize itself, it - must arrange to destroy itself if it honors the - OC_Destroy request. Since the process - created it's own address space, it must destroy it. - careful look at the object reference manual will show that - the destroy operation is expected to - return. The question is, ``How can a program that no - longer has an address space return to anyone?'' -
-- A process that wishes to honor the - OC_Destroy order code must hang on to - it's process creator key. If the process runs in a kept - address space, it must also retain access to the - protospace page. -
-
- When asked to destroy itself, the process should first
- destroy (recursively) any services it has built. It
- should then arrange to jump back into the protospace
- address space for the last phase of the destruction by
- calling DestroyMyself().
-
- On entry to DestroyMyself(), the process key
- registers should hold the following values:
-
| KR1 | -A process key to the process itself. | -
| KR15 | -A resume key to the process that - requested the destruction of this process (if any). | -
- How shutdown is accomplished depends on the process - address space: + The following features of CORBA IDL are missing in CapIDL:
-
- The DestroyMyself() library routine first
- sells back any process-allocated stack space, and then
- examines the process address space key to decide how
- shutdown should be performed:
-
- If the address space is immutable, or if the address - space consists of a single page, the process can - simply invoke it's process creator with the - DestroyCallerAndReturn order code. + There is no support for specifying + inheritance. (Possible future)
- If the address space is a more complex space, the - process must first switch to a teardown address space - (usually just protospace). The teardown space issues - an OC_Destroy request on the - process's address space and then invokes the - DestroyCallerAndReturn request on the - process creator. + Valuetypes are absent. (Possible future)
- The process creator now gets control, and demolishes the - process structure. Finally, it returns to the designated - resume key, confirming to the original caller (the one who - asked the foo process to self-destruct) that the foo - process has been successfully destroyed. -
-- Note that protospace itself is a shared resource that does - not get destroyed. -
-- There are some circumstances under which the destroy - request may fail: -
-+ There is no support for fixed-point constants or + types. (Possible future) +
+- The space bank from which the process was purchased - has been destroyed. + Constant arithmetic is currently + unimplemented. (Implementation expedience; this is a + bug).
- The process creator from which the process was - purchased has been destroyed (this happens when the - associated constructor is destroyed). + The notions of abstract and local interfaces is + removed.
- The process itself has altered the state needed by the - destruction logic. + The entire notion of ``context'' is incompatible with + capabilities (and for that matter with any enforceable + sort of security), and is gone. (No, we will not add + this. Not ever. Really!)
- Destruction is therefore done on a ``best effort'' basis. - A client who wishes to unconditionally ensure that it's - space can be reclaimed should arrange to fabricate its - services under a separate subspace bank, and destroy the - entire subspace. Note that doing so does not permit the - services to perform finalization, and should be viewed as - a way of recovering from buggy or pernicious services - rather than as a way of tearing down programs in general. + The following changes and additions have been made to the + OMG/CORBA IDL language:
++ In CapIDL, a discriminated union must specify an + identifier corresponding to the discriminator value. +
+