Re: For the AdaOS folks

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

Dmitry A. Kazakov wrote:
> On Fri, 31 Dec 2004 06:30:51 -0500, Warren W. Gay VE3WWG wrote:
>>The problem then is that the drivers add to the code in "real-mode",
>>which is one thing that the mk tries to avoid (for additional safety
>>and modularity).
> 
> I am still not sure what you mean here. If you mean modular kernel design
> and more fine-grained system of modes than all-or-nothing, then yes, sure.
> There is no reason, why a driver should not be treated as an application. 

That's right. Just remember that the purpose of the mk is to keep the
"priviledged-mode" code to a bare minimum (hence the "micro").

>>The kernel only needs to be able to provide "hooks". It is the
>>user land OS modules that neeed the networking, not the mk. This
>>discussion is basically a disagreement on "core functionality"
>>for the mk. I just don't see networking as being "core", IMO.
> 
> But how could it become distributed? That "hook" should be there. 

The hook can forward message requests to a networking "module", which
is run outside of the mk. As far as the mk is concerned, it need not
worry about more than tasks, threads, ports and perhaps mk "memory
objects" (for paging).

Don't forget that you can play amazing "port tricks" using Mach
styled message ports. To get a flavour of this, read about the Hurd
"Translator Mechanism" concept as described at:

   http://www.cs.pdx.edu/~trent/gnu/hurd/hurd-paper.html

As long as you can insert a "networking module" between the
two endpoints, the mk itself may never need to know about TCP/IP
(or whatever you choose) to network between the two. All it needs
to care about are message ports (internally message queues).

Obviously applications need to worry about networking details,
but the mk itself may never need to. The inserted "networking module"
can take care of that (acting as a proxy).

> An
> implementation could be a module, no problem, but all system objects,
> synchronization mechanisms, queues etc, should be designed in a way that
> would allow distributed behavior (no matter would it be local symmetric, in
> a cluster, random networking). This is what I would define as "true"
> networking. From this perspective neither Windows nor Unix are networking.

There is an "application view" and a "microkernel view". I think you
are mixing the two.

All of the infrastructure that you talk about is built outside of
the mk. The mk's purpose is to provide the basic needs for an OS, but
_not_ be the OS itself. In fact, using a mk approach, application and
OS modules conceptually run beside each other, perhaps only differing
in the privileges they have (ports that they have rights to).

>>This is a different problem (complexity). No amount of registry/
>>database/repository design is going to change that for you. You
>>have complexity because of the applications -- not because of the
>>registry. At best, you might organize away some of the complexity,
>>but storage of registry values and the complexity of the same
>>are two different problem domains.
> 
> Right, but if registry does not help much you to organize, and it does not,
> then it means that registry provides too low abstraction level. Technically
> it is the same level of abstraction as raw files. So you cannot get here
> much more support than from a file hierarchy. It only adds a bit type
> safety (one can query the type of a key). This means that registry is
> unsuitable to serve as an interface for any complex object persistence, as
> carrier, yes, as an interface no.

Well, there are two general approaches to API development, that I
can think of:

  1. Develop a general API to leave flexibility in the hands of the designer
  2. Develop a strict API to "straight-jacket" the users into a certain
     set of "policies".

I tend to shy away from #2, if there is no good reason for it. But in
either case, the user can choose to use it wisely or abuse it. It becomes
more difficult to abuse in #2, but abuse is usually always possible.

The point I make is that software cannot organize things for you, unless
some person has worked it out for you ahead of time. That person can't
do that for my software, and I doubt he/she can for yours either.

To date, the registry idea has gone further than the /etc/file approach,
and I have yet to see a better practical solution proposed. Of course I
would be glad to hear a better approach if one exists.  ;-)

>>My point is simply that programs (including installers), need a
>>programmatic way of testing what is installed etc. on a system.
> 
> Yes, but I would formulate it in more general way:
> 
> 1. object persistence (must be)
> 2. object containers. An application can be viewed as a container for its
> "mortal" instances and "immortal" persistent data. 

What does "object persistence" have more than a "set of values"? How
is an "object container" any different than a directory/subdirectories
containing "values"?

>>>Consider a simple diamond diagram. Application A
>>>uses B and C, they in turn use D. This cannot be represented by a tree. So
>>>you need a folder to keep them all. Let's name it "/etc". Welcome to back
>>>to chaos.
>>
>>I don't see any unsolvable problem here. Links and symlinks can
>>create any kind of network you need.
> 
> Compare it with a network of pointers in C (memory~files, pointers~links).
> Not an unsolvable problem, right, but...

But you have not proposed any solution.  You keep saying that
"I don't want to be responsible", but there is nobody/nothing
left to fill that void.

Not everything manifests itself as a diamond (obviously). If a
hierarchy or "node network" doesn't satisfy your needs, then
I'd like to hear just what other structure can.  You can't
just close your eyes and say "just make it happen". We don't
enjoy that luxury! 8->

>>All it becomes is just different terminology, but you'll still have
>>similar levels of abstraction (short-term memory vs long-term etc.
>>for example).
> 
> Yes, but I do not want to expose it in API. It is comparable with evolution
> of programming languages: from assemble with clear distinction between
> registers and memory, modern languages which hide it. Caching should be
> OS's business, down with files and I/O!

So you don't want an API, and yet you want it to happen somehow. Somehow,
some piece of software/hardware/system is supposed to know what pieces
of information are configurable elements, know how to organize it,
know how to identify it and share it in a safe way with other processes
and users on the same system/network?

Well, its ok to consider these kinds of questions, but if you really expect
that to happen any time soon, I think you're more of a dreamer
than I!

> Happy New Year!

Happy New Year to yourself, and users of Ada everywhere.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg