Re: For the AdaOS folks

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 02 Jan 2005 17:04:29 -0500, Warren W. Gay VE3WWG wrote:

> Dmitry A. Kazakov wrote:
>> On Sat, 01 Jan 2005 19:31:56 -0500, Warren W. Gay VE3WWG wrote:

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

What if my application needs My_Fancy_Type, soundtrack of James Bond and
another application? 

> Put your own OO framework around it if that's what you want.

It is Turing complete, I know! (:-))

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

The "detail" is that you identify not some GNAT installation file #1534,
but GNAT. GNAT itself is easy to find, its components are not. They may
vary from version to version. It is GNAT's responsibility to know them, not
of GNAT user.

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

ADT allows to organize it in a proper way. We are using types to forget
about bytes. In OSes we are still using "bytes" = files.

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

X11 and GCC are just applications. GNAT needs text files. Let you have an
Ada_Source object derived from what I know. Somewhere you will also have
Abstract_Text_Stream. If Ada_Source is not already a descendant of
Abstract_Text_Stream then derive a new type from both. End of story.

Ada run-time is another issue. I suppose you'd better have OS-native
tasking than tunnel it through POSIX. After all, it was you who started APQ
instead of using ODBC, did you? (:-))

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

It is not like Ada access type, because handle is not a pointer. It is a
key in some associative array. To "dereference" it you have to switch to
supervisor mode. Then you have to check it, because somebody could mess
with its value etc. It is very inefficient. You have to do all this even if
you call a function of a protected object, which could be safely performed
in user-mode. BTW, the very notion of user-mode is also of old procedural
fashion. A protected object is passive. You should be able to access it in
any "mode". But when you want to queue to its entry or to call its
procedure, only then you have to switch the context to make the object data
available to write. It is not kernel business anymore.

Your RPC services is another model. They are monitors. These can be exposed
in API as tasks to have rendezvous with. Again OO/ADT could bring great
advantages here. Imagine extensible tasks. Presently, if you have some
sequence of actions to be performed on one service, you have to care about
locking, serializing, then you implement it as separate inefficient RPCs to
the server. Service extensions would be sort of stored procedures in DB
terms.

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

OK, but that is more like C programming in Ada to me. This new OS will not
become a breakthrough. It will be a stable decent OS, but who needs that?
See what happened with VMS? The only way to kill the Windows/UNIX monster
to offer something really revolutionary.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de