Re: For the AdaOS folks

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

Dmitry A. Kazakov wrote:
> On Sat, 01 Jan 2005 19:31:56 -0500, Warren W. Gay VE3WWG wrote:
>>Dmitry A. Kazakov wrote:
>>>On Fri, 31 Dec 2004 11:24:40 -0500, Warren W. Gay VE3WWG wrote:
>>>>Dmitry A. Kazakov wrote:
>>>>>On Fri, 31 Dec 2004 06:30:51 -0500, Warren W. Gay VE3WWG wrote:

> Yes, because Ada's protected objects are local and cooperative. It'd like
> to see system services exposed as protected objects, with entry queues and
> data fully memory protected. Same with tasks. I like OO interface to OS, no
> compromises.

If you use Mach ports, you already get all of that (just
think of the port as the handle to the object).

> Where is any problem? If the kernel provides persistence and your
> application needs, say an integer parameter. Derive from the base
> Application_Data_Type add a field, here you are.

The problem is where is the improvement over the registry
API that says create/delete an integer? Put your own OO
framework around it if that's what you want.

>>Of course. But when you want to know where GNAT is installed, it
>>is very easy in Windows to lookup a registry key and get the
>>pathname for it. If I want to know where APQ should be installed
>>as an Ada binding, I can do another registry query and get the
>>top level GNAT directory for bindings.
>>
>>Is that so complicated?
> 
> Yes it is. You have to know the names you are looking for! The first step
> is of course to define some naming convention. This is a bad way, because
> it is not enforced. See what happens with /etc and HKEY_LOCAL_MACHINE. So
> the second step is to provide API to query that names from an application.
> But that is still not good. A better way, as I said, is OO. You ask an
> application: give me your settings and the result is an object of those.
> The last step is to ask yourself what for? There is GNAT, an object why
> cannot I talk to it directly?

And how do your identify your GNAT object? At the end of the day,
you still have to grapple with "names" and "identities". Only
the details change.

> Why there should be any pathnames? A name is used only to get an object
> from a text map, provided that there should be one. 

So just how do you expect to identify what piece of software
you want to know about, without using a name (or identity if
you prefer)? OO doesn't do away with this requirement.

 > Once you have the
 > object forget about its name. It has a type and so the methods to call.

Sure, like an open file you use its handle or file descriptor. Under
Mach you use a port. So where's the problem? But when you open a
file system object, you still have to specify which object to
open by name. And a pathname is actually just a fancy composite
name, because you are naming several objects all at once (from
root directory down to the actual object).

> Yes, this is the real source of our disagreement. As long as OS API are
> non-OO you will fall back to bits and bytes or String and Unbounded_String,
> if you want.

Every strongly typed Ada entity is based upon bits, bytes, words and
arrays of such as base types. Ie. every type has a base type. OS RTL
libraries can strengthen the typing of the Ada interface. For a
C interface, not much really changes.

The O/S itself can present things in basic terms (registers and software
interrupts for example), but the OS RTL can present it in any form
you want. A binding. It is just that for an Ada based O/S, you
want the RTL to support it in a first class citizen manner.

> Did UNIX care much about Ada? We'll make them see! (:-)) 

The only problem with that is that you can make things hard for
yourself. For example, I have no grand plans that I or anyone
else I know, is going to convert the X-Window system to MyOS
anytime soon. The best compromise is to allow an optional POSIX
module on top of the mk, working with MyOS, to make it easy to
port the X-Window system, if that's what I want. GNAT/GCC is
another motive in that direction.

> Call it service, that's no matter. I use the word OO only because it is a
> known buzz word. Actually I meant ADT. The service should be a typed
> object. Its entry points should have typed parameters. Type checks have to
> be enforced both by the language and by the kernel. Further most of the
> calls to the entry points have to be dispatching. Dispatching tables should
> be memory-protected.

Well, maybe I lack vision on this point, but I don't see it. The
RTL can provide anything you lack at the O/S interface.

>>And that is largely what the operating system
>>provides. But if you say you must have OO interfaces, then
>>the Ada RTL is there to let you model any way you see it.
>>You could even write packages for this, or if you don't like
>>the one you have write alternatives.
> 
> No, I cannot. The problem is that tasks and protected objects are not
> tagged. 

So? Have the RTL put a tagged face on it. Call it a binding.
Essentially even traditional UNIX uses a thin libc binding
for O/S services for C programs.

> As you probably saw, I do not want to build a fat sandwich
> OO-interface->procedural API->OO-kernel. It clumsy, ugly, buggy and
> inefficient. I want to directly talk to OS. 

A couple of things. First of all, most microkernels that I am
aware of (or at least the ones I plan to use), all use a
procedural API (albeit with handles, if you want to call
them that).

Using a Mach type of approach, you write a bunch of executables
that behave as "servers". Application programs become "clients"
of these. This leaves the interface between the client user
mode program and the server(s), as a RPC API interface set.

Now MyOS (I'll just use that for example), would then of
course sport a nice native Ada interface for application
programs. However, underneath this "binding" (which is what
it really is), it will be calling an RPC message API that is
supported by the procedural API microkernel.

User-mode-client-OO->Ada Binding->RPC->Server(s)->microkernel

Can native objects be exported from operating systems? A
quick survey produces this list:

   - integer file descriptor (POSIX)
   - handles (Windows)
   - ports (Mach)
   - identities (L4)
   - ipc ID (UNIX SysV) for message queues, shared mem etc.

These are all fancy "handles" of one sort or another. You won't
get much more than that from any O/S. Why? How do you share an
object in protected-mode with a user-mode process? You can't.
Even if you could, there would be parts of objects that the
O/S wouldn't want you to mess with, or perhaps even look at.
Maybe you can't because the object is just a Mach port.

The best API answer seems to be to just provide a handle that
can be used to refer to the object (like an Ada access type),
or in the case of a Mach port, be the object metaphore. Then
you call varied API set (effectively methods) on that object,
using the given handle(s).

Then if you want it to look different than that, you provide
a binding. The general idea however, is that an Ada based
O/S will have native bindings. The packages won't be
adaptations of C header files etc.
--
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg