Re: For the AdaOS folks

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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. The problem is that OS should have generic interfaces for all kinds of
devices. They should be in. You can try to solve it by declaring
"everything is a file": UNIX (tm), or by doing nothing Windows (tm), but in
both cases the result is pretty same. I think only a native OO design
*exposed* in the kernel interface can help.

>>>>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.
> 
> 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.

>>>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...

> However, IMHO, the microkernel should be small as possible, and
> leave networking up to the modules outside of it. After all, some may
> perfer an IPv6 only version of networking for example (in light
> of China's recent network announcment). In the end, I don't want
> to be "stuck" with what a brand of microkernel gives me. Just
> give me the basics and let me decide what is included.

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.

>>>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, 
> 
> So we agree that it is an improvement over little text files that
> you must parse/edit etc..

Sure

>> but the
>> concept of registry is not good. Try to reformat an Windows box and restore
>> all settings of say MS VC back.
> 
> 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.

>> 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.
> 
> 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! (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de