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: Thu, 30 Dec 2004 16:27:37 +0100 Organization: cbb software GmbH Message-ID: <1vemlj8wqr9ea$.qyecszhsmtqa$.dlg@40tude.net> References: <1PTAd.1218$0y4.421@read1.cgocable.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: individual.net f+IgCemV+WkWam0waSXe/wiupp4OMy1uCA7TyjcFZOneGQnIM= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:7324 Date: 2004-12-30T16:27:37+01:00 List-Id: On Thu, 30 Dec 2004 08:58:23 -0500, Warren W. Gay VE3WWG wrote: > Nick Roberts wrote: >> However, I intend to design the microkernel so that it compromises on >> minimality (unlike some other microkernel designs) > > Yes. Mach is too fat. They shouldn't have included device drivers > for example. Implementations of or the generic interface for? I think the latter would be a mistake. DOS->Windows tried this path. MS consistently refused to specify device classes other than hard drive and keyboard. >> to achieve reasonable >> efficiency (whilst removing much of unnecessary detritus that bogged down >> experimental microkernels), and I intend to ensure that administrative >> division of the network is fully supported, as well as network partioning >> robustness (if some workstations go down, the rest still work). > > I wonder if networking really belongs in the microkernel. This is > necessary for example if like Mach, you say that ports can speak > to other Mach machines on the network/cluster. That is an interesting question. I think that the kernel should be able to tunnel its requests through higher order protocols. > However, you might want to take the tact that networking is done > outside of the microkernel. This way, in situations where you don't > want networking (embedded systems), it need not be there. There are lot of embedded systems which need networking, starting from boards interconnected through dual ported RAM, to various sensors and actors devices attached via Ethernet. > Leave the > networking up to the user of the microkernel. This would be my > preference anyway. It also leaves it up to the OS designer what > type of networking will be supported. > > Reading below, perhaps you are speaking collectively for AdaOS, for > microkernel and OS. > >> For a very long time, IBM mainframes have supported (very efficient) >> programmatic access to a system database, as an alternative to file-based >> data storage. I would like provide both forms of storage in AdaOS, in >> addition to 'persistent objects' in some form. > > I always get scoffed at for suggesting this, and I have no love for M$, > but the one idea they have had, which is useful, is the registry. It might look attractive and is definitely better than Unix chaos, but the concept of registry is not good. Try to reformat an Windows box and restore all settings of say MS VC back. Registry makes program's settings a property of the local machine or user. The problem is that tree view. It should be at least relational. But better would to have different views. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de