From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b95a522100671708 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Nick Roberts Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks Date: Tue, 4 Jan 2005 20:09:00 +0000 Message-ID: References: <1PTAd.1218$0y4.421@read1.cgocable.net> <1vemlj8wqr9ea$.qyecszhsmtqa$.dlg@40tude.net> <1b48kdfqsk3mw.7gajq12fsa82.dlg@40tude.net> Content-Type: text/plain; charset=us-ascii X-Trace: individual.net dHqtaLWDhNQvfefHLvZXDADGetNc657Ooek39qDrZj9l6O034= X-Orig-Path: not-for-mail User-Agent: Gemini/1.45d (Qt/3.3.2) (Windows-XP) Xref: g2news1.google.com comp.lang.ada:7439 Date: 2005-01-04T20:09:00+00:00 List-Id: "Dmitry A. Kazakov" 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