Re: For the AdaOS folks

["Marven Lee" <mehs60@dsl.pipex.com>]

Warren W. Gay VE3WWG wrote:
> Marven Lee wrote:
>> In Mach it's called "migrating threads".
>
> Yes, I've seen references to this in the Mach
> literature.

Yes, and from your other post you've already found the
paper on migrating threads in Mach.

http://www.brynosaurus.com/pub.html

It is interesting to note that he wrote some libraries and
apps on AmigaOS.  I think he works for Microsoft now.



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

It would be a bit like Ingo Molnar's 4GB kernel / 4GB user
patch for Linux.

http://lkml.org/lkml/2003/7/8/246

This moved the kernel from the top 1GB of every process
into a 4GB address space of its own.  a 16MB trampoline
(microkernel) exists at the top of every address space
to transfer syscalls and interrupts into the address space
that the Linux kernel resides in.

In some ways this is similar to a single server Linux personality
running on a microkernel like L4Linux. I think the difference
between the trampoline and L4Linux can be summed up as
L4 uses an active object model and the trampoline/migrating
threads uses a passive object model.

I'm not sure if or why the 4G4G in Linux needs 16MB, it
can be done in less than a page of code and a few bytes of data.
The trampoline should take up something in the region of 8KB
of the address space.

You could replace Linux with Mach as the personality.  Yes,
it sounds a bit wierd having Mach run on top of a microkernel
or trampoline.   Although Mach would be running as a single
server personality this doesn't stop multiple servers existing, they
just have to make cross-domain calls into the Mach personality
to make use of Mach's IPC.  It is single server only from the
point of view of cross-domain calls through the trampoline
microkernel.

So you can think of this trampoline/microkernel as a fancy
syscall redirection mechanism that moves a kernel from
kernel-mode in all address spaces to its own address space.

The trampoline copies small messages in registers, if
you want to copy more then you have to change functions
in the personality such as copy_to_user() and copy_from_user()
to map pages from the application process into the personality
and copy the data from there.



By using a more sophisticated trampoline that keeps track
of what protection domains a thread has permission to
migrate to you can have a multiserver cross-domain call
mechanism.  The trampoline would require more storage
space than the simple single server approach.

I've dug up an old thread from alt.os.development where
KVP describes a single server trampoline and I follow
up with a rough idea of how to implement a
trampoline-microkernel that supports multiple servers.

http://tinyurl.com/6gb5b

That was an old posting of mine and I'd probably change the
"activation" structure around a bit.  I'd more likely use
array indices to reference other activations instead of pointers.
I'd also change some of the needed system calls as well.



Onto AmigaOS.  Let me make this clear from the outset
to any Amigans reading that what I'm about to write below isn't
about  how to add memory protection to AmigaOS, it's only
about how the structure of AmigaOS relates to microkernels
that make use of cross-domain calls / migrating threads.

I always think of migrating threads in terms of AmigaOS.
AmigaOS didn't have any protection and divided everything
into shared libraries.  But the libraries weren't like those
in other operating systems, they were more like the subsystems
of a kernel.  Ideally they should have been placed in their
own address spaces/protection domains and a cross-domain
call should have been used to access them.

The core library of AmigaOS, exec.library would become
a server, just like Mach in the above single server example.
All other libraries, including devices which are more or less
libraries with their own thread would also become servers.

It would be as if the a trampoline microkernel had replaced
the library jump tables it used.  In an earlier post in this
thread Dennis Lee Bieber said everything was done with
message ports, from my point of view I'd say everthing
was done with library calls.  After all the message passing
was done by library calls to exec.library.

In effect what they should be is, "Protected Shared Libraries."  *

I had wondered if anyone in the Amiga community had come up
with similar ideas and found this in a 1997 newsgroup posting
entitled  "p-OS & Multiprocessing"...


Michael van Elst wrote:
> Jeroen T. Vermeulen wrote:
>> One major problem is that the Amiga's shared libraries act as
>> OOP-style objects, matching responsibilities to context much more
>> elegantly than other OSs do (where process ID is everything).  A
>> process conceptually switches to a different protection domain when
>> it calls a library function.
>
> Correct. That's why a protected AmigaOS must support protection
> domains not only for processes but also for libraries. That's a
> generalization of the UNIX model. There you have protection domains
> for each process plus one protection domain for the kernel which is
> mainly a huge library. In AmigaOS every library would need its own
> protection domain and context switches must be as lightweight as
> possible.


I also like the way each thread in AmigaOS has access to exec.library.
Each thread could call the exec.library functions OpenLibrary() and
CloseLibrary() to load a library into memory and obtain a handle to
access it.  A similar way could be used for loading modules in a
system that uses cross-domain calls/migrating threads except that
it would need to create a stack in a server for a thread to use when
it has called into the server.

These "protected shared libraries" (PSLs from now on) needn't be
global to the entire system.  You could have global PSLs for
the memory manager, the filesystem, networking and GUI.  Per-
user PSLs for things like a clipboard and desktop.  Finally you
could have per application private PSLs so as to decompose
an application into a number of PSLs.



> I've never been too keen on the single address space systems.

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.




Now for some suggested reading...

"High Performance Cross Address Space Communication"
and "Lightweight Remote Procedure Call" by B.Bershad.
One of the older papers that other papers cite.

"Evolving Mach 3.0 to a Migrating Thread Model" and
"Microkernels Should Support Passive Objects" by
B.Ford & J.Lepreau.  The second one puts forward
some reasons why microkernels should use migrating
threads.

Sun's "Spring nucleus, A Microkernel for Objects"
by G. Hamilton.  They took the idea of Doors from
Spring and later added them to Solaris.


The "Pebble Operating System"
http://www.bell-labs.com/project/pebble/

has a few papers, "The Pebble Component-Based Operating
System" is the main one.

"The Mungi Single-Address-Space Operating System"
by G.Heiser.  Although I think it runs on top of L4
it has a "protected procedure call" mechanism called PDX.

There is also the Grasshopper kernel but I'm not sure
what the main research papers on it are called.

* "Protected Shared Libraries" by A.Banerju and D.L. Cohn.

Then there are kernel-less systems that have some
similarities to cross-domain calls.

"Anonymous RPC" by C.Yarvin et al.  Imagine the Amiga's
shared libraries randomly scattered around a 64-bit address
space.  Imagine also that the Amiga library jump tables
are execute-only and not readable, and that it was running
on a RISC chip with instruction-alignment constraints.
Then you've got a idea of what "Anonymous RPC" and
probablistic memory protection is about.

"Implementing Operating Systems without Kernels" and
"Efficient Cross-domain Mechanisms for Building
Kernel-less Operating Systems" by D.Probert and J.Bruno.
I read it some time ago, I think it is more or less about
the trampoline/microkernel being implemented in hardware.




Marv