Re: For the AdaOS folks

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

On Tue, 4 Jan 2005 20:09:00 +0000, Nick Roberts wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>
>>> 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.

Kernel. Warren and I agreed on hooks for networking. But it seems that we
meant different consequences. Especially because of security issues. I
suppose he tend to move them far away to the upper abstraction layers.
Firewall is a relatively high level. I wished to see them already in the
kernel. In this case "hooks" might become very fat.

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

Yes, I think it is a very important pattern, not only for an OS, but also
for any complex layered system.

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

That sounds really great.

The other means would be by mapping everything to L/DSM. The problem is how
to achieve different views on the same storage. As I mentioned in
discussion with Warren, I would like to have something like Ada protected
object with protection enforced by memory mapping.

Then there is of course the issue of reset/restart/upgrade. System objects
have to be organized in a way which would allow restart failed system
parts. One would never be able to restart the whole [distributed] system
once it runs.

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