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!news1.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks Date: Wed, 5 Jan 2005 11:19:37 +0100 Organization: cbb software GmbH Message-ID: <2tsp1psz9462$.1f29l3v513cke$.dlg@40tude.net> References: <1PTAd.1218$0y4.421@read1.cgocable.net> <1vemlj8wqr9ea$.qyecszhsmtqa$.dlg@40tude.net> <1b48kdfqsk3mw.7gajq12fsa82.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: individual.net EP/y82UolAHAkZucTEVdRAP74UxjzytgnzxLPT+bz4fUrx8OA= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:7467 Date: 2005-01-05T11:19:37+01:00 List-Id: On Tue, 4 Jan 2005 20:09:00 +0000, Nick Roberts wrote: > "Dmitry A. Kazakov" 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