Re: For the AdaOS folks

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

"Warren W. Gay VE3WWG" <ve3wwg@NoSpam.cogeco.ca> wrote:

> Its too bad that the L4 microkernel is not very secure yet. Apparently,
> they are trying to fix that in L4ng, but it appears that they got so
> focused on efficiency that they didn't get security. The efficiency of L4
> otherwise makes it very attractive. 

The major problems with L4 that stopped me using it (or its interface) were
its security problems, and the fact that it does not support process
migration. Of course, that support could be added on top, in an extra layer;
but obviously I felt there's no point in having that extra layer, I might
just as well design a microkernel that supports it directly. There are a
number of other minor problems with L4, too.

There are other problems. I want to write the microkernel (mostly) in Ada,
so I would have to rewrite L4 anyway. It might have still been attractive to
use the L4 interface, but since there is only a binary interface and a C
interface (no published Ada interface), this doesn't turn out to be such an
advantage. Similar comments apply to other kernels, including Mach.

> I also don't like the way that L4 ties communications to threads. The Mach
> approach is much easier to work with, with its single receiver and
> multiple send and send-once rights.

This issue is related to the problem of process migration. Mach supports it
by not tying communications to threads. But this creates all sorts of
communications routing complexity inside the kernel. I think Bachar does
much better: communications are thread-addressed, but a mechanism permits
proxy threads (which can be in separate processes) to be transparently
interposed when non-local communication is required (and removed when it is
not). This way, you get simplicity and efficiency, but process migration is
still properly supported. Note that there are some other subtleties: all
Bachar resources can be addressed (identified) in a way that can be exactly
reproduced in the target machine when a process is migrated; most
microkernels do not seem to support this functionality. Bachar provides
functionality that allows any process to be frozen, dissected, reconstructed
(on the target machine), and then reanimated. These functions can be done by
a higher layer, but it makes more sense for them to be supported directly by
the kernel.

> I've been mulling this over myself. Unfortunately, as soon as you say that
> all computers must work together, you introduce all sorts of problems and
> overheads. Endianness and page size are two issues, between two computers.
> I have been wondering if this shouldn't be tiered:
> 
>    1. Clustered systems with all the same endianness and page size
>    2. "Networked Clusters" of #1 groupings
> 
> In this way, it would be efficiently possible to cluster similar
> equipment, and yet still provide "one-ness" in the different computer
> cases, with the necessary overhead and complexity. This would also permit
> a tiered development approach.

Interesting idea. But I am assuming a network made up entirely of
workstations sufficiently similar in architecture that a process can be
migrated from any one to any other. In practice, to start with, that means a
set of PCs.

Obviously we will support heterogeneous networking, but I think we might as
well use IP to do this, and all the existing (reliable) technologies built
on top of it. I'd like to support both IPv4 and IPv6.

A widely-distributed (heterogeneous architecture) filesystem and database
system would be a very nice idea, however. I'm hoping that once we get a
core AdaOS working, people will develop all sorts of nice ideas for it.

> I wonder if networking really belongs in the microkernel. This is
> necessary for example if like Mach, you say that ports can speak to other
> Mach machines on the network/cluster.

I'm sorry, I didn't mean to imply that Bachar will do any networking. It
won't. It really will be a microkernel (maybe not as tiny as L4).

Networking will be implemented in device drivers and layers just above the
kernel, especially in the ORB engine (called Avarus).

> I always get scoffed at for suggesting this, and I have no love for M$,
> but the one idea they have had, which is useful, is the registry. I think
> there are better ways of doing this however, but the general idea is good.
> You can see that GNOME and Mozilla both use it, so it obviously satisfies
> a need. I think any OS today that is going to support point and click
> administration, is going to need some sort of a registry, even if it is
> just layering it on a RieserFS.

Exactly. The main problem with the Registry is that it is not a proper
database system.

-- 
Nick Roberts