Re: For the AdaOS folks

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

> I think only a native OO design *exposed* in the kernel interface can
> help.

As I currently have it, AdaOS is very OO from the level just above the
microkernel -- device drivers -- upwards, making full use of Annex E and
remote access types.

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

Do you really mean the (micro)kernel, Dmitry, or the TCB (Trusted Computing
Base)?  In Linux and BSD, for example, the kernel /is/ the TCB, but this is
not the case with AdaOS.

> Agree. Protocols must be decoupled from the system, though that is easier
> to do, than to remove networking as a whole. Though it is related to an
> interesting OO problem. When protocol implementation is buried somewhere
> in an inheritance path, then it becomes difficult to switch from one
> protocol to another. It looks like abstraction inversion.

This is why I think the introduction of interfaces in Ada 2005 will be
important. Not only will this help support multiple inheritance, but it will
also help decouple interface hierarchies from implementational hierarchies.

> > You base your registry criticisms upon M$ _implementation_ of a
> > registry. But consider this:
> > 
> > If each registry item were a file (on a RieserFS so there is little or
> > no waste), then you can backup, secure and restore settings just like
> > any other file. You can do so with all of those familiar tools,
> > including tar and cpio.
> 
> 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. 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.

Dmitry seems to be echoing what I was saying in another post in this thread.

> > 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! (:-))

As I currently have it, that is how AdaOS is designed, in essence. A program
classed as a 'local storage manager' (LSM) provides a way to cause a memory
region to be stored on the hard disk, each such 'store' identified by a
number. At a low level (device drivers) a simple namesystem maps names to
stores, providing an elementary file system.

A programs classed as a 'distributed storage managers' (DSM) will provide
'distributed stores'. A distributed store is identified by a number that is
the same across the whole network, and the pages of a store are
automatically moved (or copied, for R/O pages) to workstations upon demand.
Distributed programs use DSMs (only) to provide their memory regions and
stores.

At a higher level (including application programs), files are organised as
objects (records) in database tables; the 'data' of a file will be stored in
a field of type 'binary large object' (BLOB); each large BLOB will be kept
in a separate distributed store (small ones will be agglomerated, together
with other 'small' database data). However, nothing will prevent stores
being accessed by other means, if necessary. 

-- 
Nick Roberts