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!news4.google.com!news.glorb.com!meganewsservers.com!feeder2.on.meganewsservers.com!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks References: <1PTAd.1218$0y4.421@read1.cgocable.net> <1vemlj8wqr9ea$.qyecszhsmtqa$.dlg@40tude.net> <1b48kdfqsk3mw.7gajq12fsa82.dlg@40tude.net> In-Reply-To: <1b48kdfqsk3mw.7gajq12fsa82.dlg@40tude.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 31 Dec 2004 06:30:51 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1104492586 24.150.168.167 (Fri, 31 Dec 2004 06:29:46 EST) NNTP-Posting-Date: Fri, 31 Dec 2004 06:29:46 EST Organization: Cogeco Cable Xref: g2news1.google.com comp.lang.ada:7342 Date: 2004-12-31T06:30:51-05:00 List-Id: Dmitry A. Kazakov wrote: > On Thu, 30 Dec 2004 11:30:35 -0500, Warren W. Gay VE3WWG wrote: >>Dmitry A. Kazakov wrote: >> >>>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. >> >>I'm not sure exactly what you're supporting here (clearly not M$), but >>IMHO, the device driver(s) can be written on top of the microkernel, >>and need to be inside it. This also helps to keep the mk small. > > So it is about implementations then? But that is not what makes the kernel > fat. To support drivers in the mk, there was additional API added. This fattens the core somewhat, perhaps not to the extent that other things did. The problem is that OS should have generic interfaces for all kinds of > devices. They should be in. The problem then is that the drivers add to the code in "real-mode", which is one thing that the mk tries to avoid (for additional safety and modularity). >>>That is an interesting question. I think that the kernel should be able to >>>tunnel its requests through higher order protocols. >> >>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. The kernel only needs to be able to provide "hooks". It is the user land OS modules that neeed the networking, not the mk. This discussion is basically a disagreement on "core functionality" for the mk. I just don't see networking as being "core", IMO. >>>>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. >> >>I am not disputing that. But that is different than saying every >>embedded device needs it. So if you want to save some memory, then >>the first thing that can be dumped (if the option exists) is >>networking if you don't require it. If it is included in a >>given mk, it should be optional. > > I'm not sure if that could be possible. I have designed not an OS, but a > large middleware project. I tried to do the thing you describe, i.e. to > isolate all networking and remove it from the system core. It turned to be > impossible. In the final version it appears as a "normal driver", but it > still has some secret wires leading to the core. So I failed. BTW, there > were other things which seemed to be no less coupled. For example, I > managed to isolate the system data logger. So in principle, I agree with > you, but... I view "impossible" as a strong word. It may have been true with certain kinds of constraints imposed upon you that it was impossible, but I have trouble generally accepting "immpossible", if enough time and effort is permitted. >>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. This is a different problem (complexity). No amount of registry/ database/repository design is going to change that for you. You have complexity because of the applications -- not because of the registry. At best, you might organize away some of the complexity, but storage of registry values and the complexity of the same are two different problem domains. My point is simply that programs (including installers), need a programmatic way of testing what is installed etc. on a system. This is impractical with little text files, all in different formats. The registry approach is a very practical solution to this problem. > 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. I don't see any unsolvable problem here. Links and symlinks can create any kind of network you need. >>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! (:-)) All it becomes is just different terminology, but you'll still have similar levels of abstraction (short-term memory vs long-term etc. for example). In the meantime, file systems provide a very useful solution as a hierarchical database ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg