Re: For the AdaOS folks

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

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 is an interesting question. I think that the kernel should be able to
>>>>tunnel its requests through higher order protocols.
>>>
>>>Yes, they can be provided on top of the microkernel, as you seem to
>>>be suggesting.
>> 
>> Yes, but networking should be known to the kernel as something it can work
>> with. So you cannot completely throw it away.
> 
> 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. 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.

> I view "impossible" as a strong word. It may have been true
> with certain kinds of constraints imposed upon you that
> it was impossible, but I have trouble generally accepting
> "immpossible", if enough time and effort is permitted.

Of course.
 
>> The problem is not an ability to backup, in UNIX one can backup /etc, /var
>> ... The problem is complexity. There are dependencies between repository
>> objects, which cannot be mapped to a simple tree structure, whether that be
>> chaotic files or registry. 
> 
> 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.

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

> This is impractical with little text files, all in different
> formats. The registry approach is a very practical solution
> to this problem.

The very first tiny step, in my view.

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

>>>I don't believe it need be treated any differently than a file
>>>system. To support a registry on the RieserFS for example, one
>>>merely need to add a nice programming API to make it easier for
>>>programs to query and set values. You can still use links/symlinks
>>>(if you must) etc.
>> 
>> In my view there should be no file systems at all. OS should be fully
>> memory-mapped with persistent objects. A FS would be just a "low-level"
>> format then. (Kind of data base discussion again! (:-))
> 
> 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!

> In the meantime, file systems provide a very useful
> solution as a hierarchical database ;-)

(:-))

Happy New Year!

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