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: Fri, 31 Dec 2004 18:47:48 +0000 Message-ID: References: <1PTAd.1218$0y4.421@read1.cgocable.net> Content-Type: text/plain; charset=us-ascii X-Trace: individual.net MxqDBzNZmcJhGU6omx6lEgapLS1+B0TEARC+GWXyN3NymVtd0= X-Orig-Path: not-for-mail User-Agent: Gemini/1.45d (Qt/3.3.2) (Windows-XP) Xref: g2news1.google.com comp.lang.ada:7351 Date: 2004-12-31T18:47:48+00:00 List-Id: "Warren W. Gay VE3WWG" wrote: > Its too bad that the L4 microkernel is not very secure yet. Apparently, > they are trying to fix that in L4ng, but it appears that they got so > focused on efficiency that they didn't get security. The efficiency of L4 > otherwise makes it very attractive. The major problems with L4 that stopped me using it (or its interface) were its security problems, and the fact that it does not support process migration. Of course, that support could be added on top, in an extra layer; but obviously I felt there's no point in having that extra layer, I might just as well design a microkernel that supports it directly. There are a number of other minor problems with L4, too. There are other problems. I want to write the microkernel (mostly) in Ada, so I would have to rewrite L4 anyway. It might have still been attractive to use the L4 interface, but since there is only a binary interface and a C interface (no published Ada interface), this doesn't turn out to be such an advantage. Similar comments apply to other kernels, including Mach. > I also don't like the way that L4 ties communications to threads. The Mach > approach is much easier to work with, with its single receiver and > multiple send and send-once rights. This issue is related to the problem of process migration. Mach supports it by not tying communications to threads. But this creates all sorts of communications routing complexity inside the kernel. I think Bachar does much better: communications are thread-addressed, but a mechanism permits proxy threads (which can be in separate processes) to be transparently interposed when non-local communication is required (and removed when it is not). This way, you get simplicity and efficiency, but process migration is still properly supported. Note that there are some other subtleties: all Bachar resources can be addressed (identified) in a way that can be exactly reproduced in the target machine when a process is migrated; most microkernels do not seem to support this functionality. Bachar provides functionality that allows any process to be frozen, dissected, reconstructed (on the target machine), and then reanimated. These functions can be done by a higher layer, but it makes more sense for them to be supported directly by the kernel. > I've been mulling this over myself. Unfortunately, as soon as you say that > all computers must work together, you introduce all sorts of problems and > overheads. Endianness and page size are two issues, between two computers. > I have been wondering if this shouldn't be tiered: > > 1. Clustered systems with all the same endianness and page size > 2. "Networked Clusters" of #1 groupings > > In this way, it would be efficiently possible to cluster similar > equipment, and yet still provide "one-ness" in the different computer > cases, with the necessary overhead and complexity. This would also permit > a tiered development approach. Interesting idea. But I am assuming a network made up entirely of workstations sufficiently similar in architecture that a process can be migrated from any one to any other. In practice, to start with, that means a set of PCs. Obviously we will support heterogeneous networking, but I think we might as well use IP to do this, and all the existing (reliable) technologies built on top of it. I'd like to support both IPv4 and IPv6. A widely-distributed (heterogeneous architecture) filesystem and database system would be a very nice idea, however. I'm hoping that once we get a core AdaOS working, people will develop all sorts of nice ideas for it. > 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. I'm sorry, I didn't mean to imply that Bachar will do any networking. It won't. It really will be a microkernel (maybe not as tiny as L4). Networking will be implemented in device drivers and layers just above the kernel, especially in the ORB engine (called Avarus). > 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. I think > there are better ways of doing this however, but the general idea is good. > You can see that GNOME and Mozilla both use it, so it obviously satisfies > a need. I think any OS today that is going to support point and click > administration, is going to need some sort of a registry, even if it is > just layering it on a RieserFS. Exactly. The main problem with the Registry is that it is not a proper database system. -- Nick Roberts