Re: For the AdaOS folks

[Nick Roberts <nick.roberts@acm.org>]

"Marven Lee" <mehs60@dsl.pipex.com> wrote:

> > > You can end up with a microkernel that only handles cross-domain
> > > calls.  Everything else, including what you normally think a
> > > microkernel should at least include,
> >
> > I'm glad you said "normally" here. ;-)
> >
> > > such as memory management, scheduling and IPC can be implemented
> > > outside of the microkernel.
> >
> > Exokernel?
> 
> No, I'd still call it a microkernel or perhaps a trampoline.

Bachar has cross-domain calls (I think ;-) although I've called them 'IPC
service calls', and describe them in terms of the client-server model.

A process that provides a service (the server process) obtains a kernel
resource called an 'IPC service', and publishes it somehow (how is a long
story). A process that wants to use the service (the client process) obtains
a kernel resource called a 'service key', whose target service is the
required IPC service. The client then calls the service key to obtain the
service. The server receives calls to its IPC service, performs the service,
and returns. The (calling thread of the) client remains blocked until this
is complete.

> I like the way you can pass areas of memory between address spaces without
> having to search for a suitable place to stick it in the destination
> address space, they can use the same region of the address space in each
> address space.  This might also be useful when copying data through a
> series of address spaces.  I don't think having pointers meaning the same
> thing in different address spaces is a benefit though, especially in
> messages where a pointer could point outside a message without any error
> checking.

AdaOS provides multiple memory 'regions'. A process can map multiple regions
into its address space at one time. Several processes can share a memory
region by obtaining kernel resources called 'region keys', and using those
keys to map the region. Again, a mechanism of publishing provides the means
for processes to co-ordinate this.

The idea is that one or more shared regions can be used to pass parameters
between processes in accompaniment to IPC service calls.

Because the regions for doing this are genuinely shared memory areas -- if
the the client and server both reside on the same workstation -- there is no
copying involved (although there may be marshalling on both sides, where the
format of data is generally changed).

However, the exact same IPC calls can be made trans-network, completely
transparently to both client and server, by the insertion of 'agent' (proxy)
processes: the client calls a client agent; the client agent communicates
the call across the network to the server agent; the server agent calls the
server; when the server finishes, the server agent communicates the reply to
the client agent; the client agent returns the reply to the client.
Distributed memory regions are used, so that pages of data get automatically
pulled around the network as they are used by client and server.

An asynchronous form of call is also supported (the client thread is not
blocked, and there is no reply).

This scheme is completely secure: no process can ever gain access to data it
is not permitted to access (it is prevented from getting a region key), and
no client can call a service it is not permitted to (it is prevented from
getting a service key).

-- 
Nick Roberts