Re: For the AdaOS folks

["Warren W. Gay VE3WWG" <ve3wwg@NoSpam.cogeco.ca>]

Nick Roberts wrote:
> "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.

How is this "IPC service key" different than a Mach port? What you
describe sounds just like Mach RPC (with or without migrating-threads).

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

How does this differ from Mach using its ports to map in regions
of memory?

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

Mach has been doing this with its "out-of-line" data as an optional
RPC feature (the rtmk microkernel that I am using does this for
example - it was inspired by Mach).

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

In some Mach literature this is referred to as External Memory
Management (EMM). The most easiest version of this is the
1-writer + n-readers case. > 1 writers leads to a number of
problems and significant overhead, depending upon the sequence
of events. You'll find a 1992 example of the 1-writer EMM
in the book "Programming under Mach".

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

Mach of course, supports this out of the box.

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

It sounds pretty much deja-Mach to me, which is ok. What I have
trouble understanding is the need for new names.
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg