Re: For the AdaOS folks

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

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

> Mach's migrating threads do in fact cross into other "tasks". Instead of a
> caller thread stopping when a message is queued, and the receiving thread
> starting (from a blocked state), a migrating thread continues from the
> caller, works through the server code, and then returns back to the caller
> (in the caller's "task"). This is a simplification of what happens,
> because there are "activations" and stack games that must happen to make
> this work - but it is a migrating thread.

I'm not quite sure what you're getting at, Warren. I don't think it's very
surprising that Mach has capabilities that are similar to Bachar, since they
are both aimed at doing roughly the same thing. But there are significant
differences in the details. I did begin designing (what has become) Bachar a
long time ago (pre-1990s).

> > They take the attitude that the C interface must remain the same,
> > regardless of the machine. I think that's impractical.
> 
> In what way?

There are sufficient differences between some architectures (e.g. a CISC
such as the IA-32 and a RISC such as the PowerPC) to warrant a difference in
the interface between a microkernel intended for one and a microkernel
intended for the other, even if the software on top is intended to be the
same. Some of these differences cannot be hidden by C (more of them can be
hidden by Ada, in fact).

> > I've designed the Bachar interface so that it will use real machine
> > registers, rather than pretend registers.
> 
> But don't forget the MRs are immediately loaded into registers after all
> of your "deposits" are made. I don't think you can level valid efficiency
> arguments against L4. AFAICS, it is the best performing microkernel
> available.

One of the advantages of using real registers that an Ada compiler's ability
to optimise register usage can be brought into play when calling kernel
services. Admittedly, this might not be important in practice, but
theoretically it is an advantage. The L4 people don't seem to have
considered the issues concerning the use of a language other than C.

As for performance, I suppose ultimately the proof of the pudding will be in
the eating. I suspect that Bachar will do quite well against L4. It won't be
as fast, but it does more anyway.

> I think L4 has done a nice job of saving the programmer from the hassle of
> potential processor differences. They've apparently done a good job of it,
> because it performs quite well in the benchmark tests compared to the
> others.

Yes, but AdaOS will do a much better job of saving the programmer from the
hassle of potential processor differences, but the simple token of allowing
the programmer to program in Ada!  Most such differences will vanish from
the programmer's horizon, because they are taken care of by the Ada
compiler, in a way that a C compiler cannot achieve.

> > > But if you look at the Mach paper above, you can do the very same
> > > thing with ports. Even without thread-migration, you can interpose
> > > proxies. With thread-migration enabled RPC, you achieve both and
> > > provide the OS designer a nicer interface.
> > 
> > But if we did that, what would be the advantage?
> 
> Its cheaper. To have 1000 send rights, costs near nothing. 1000 send
> rights in one task costs nothing (just increments ref count). 1000 in a
> 1000 different tasks, costs one pointer in each task. Nothing further.
> 
> 1000 threads OTOH, costs you state information for each of those 1000
> threads (same task or different). The amount of state information needed
> will vary with platform.

I have to guess somewhat, Warren, at the point you are making (maybe it's my
fault). Are you suggesting that if I have 1000 client processes (or
threads?) performing trans-network IPC, it will be necessary to have 1000
(or 2000?) proxy processes (or threads)? On AdaOS, in practice, there will
only be one proxy process (the program Avarus, running once on each
workstation).

> > I don't see the point in making the microkernel /that/ minimalist, to be
> > honest. Whatever the upper layer did, it would have to be dependent upon
> > intimate details of the kernel. So why not just lump them together?
> 
> But in your answer:
> 
> > I have taken the approach of local IPC being supported by the
> > microkernel (and lower levels of TCB software), and network IPC being
> > supported by a higher layer of TCB software (Avarus).
> 
> If I understand correctly, you are saying that your network "layer" is
> already built on top of lower levels (like microkernel).

Yes, that's correct.

> > > To make this work, as I envision it, requires that all participating
> > > nodes in a cluster see the file system the same way. IOW, there can
> > > only be one root file system, which obviously is only local to one
> > > node. To all other nodes, root will be access NFS-like (ie. over the
> > > network cable).
> > 
> > This is a fundamental precept of fully distributed networking.
> 
> It would seem so, but I think there is room for creative thinking here.
> Perhaps a "context sensitive view" is also possible.

Indeed, for legacy software it may be necessary to do that sort of thing. I
think I will attempt to organise the canonical file hierarchy according to
the FHS. However, for a program written to be run on a Windows computer, for
example, it may be necessary to translate '\' into '/', as well as drive
letters into the appropriate mounted drive names, and so on.

> > > SQL databases are designed to deal with large volumes of similar data,
> > > in SELECTs, joins etc. However, when you look at what goes into the
> > > registry, a lot of it is custom, hierarchically structured
> > > information.
> > 
> > No, the kind of data that goes into the Registry would be naturally
> > organised in many complex ways. For example, many different applications
> > store their own font information, but a font disinstaller may well wish
> > to be able to 'cut across' this font data, to make appropriate
> > adjustments (for all the applications). As another example, some
> > applications may wish to store data for several different users, but an
> > adminstrative program may wish to change all the data (across many
> > applications) for a particular user.
> 
> The same argument can be made for changing file systems into databases. So
> far, the filesystems approach seems to be the clear winner for that kind
> of data.

On the contrary, the database approach has been used by IBM (on their
mainframes and minis) for decades, and appears to be a clear winner over
using files. Microsoft have had plans for quite a long time now to introduce
a database-based OS as a replacement to Windows.

-- 
Nick Roberts