[unios] Re: Generic design. More comments

[Anders Petersson]

From: Anders Petersson <anders.petersson@mbox320.swipnet.se>

At 19:46 1998-12-16 , you wrote:
>From: Pieter Dumon <Pieter.Dumon@rug.ac.be>
>
>> 
>> From: Anders Petersson <anders.petersson@mbox320.swipnet.se>
>> 
>> > - A completely independent low-level part wich can run this system, 
>> >   and Win32,POSIX,OS/2,DOS etc, as seperate subsystems:
>> >
>> >   pro : - very fast
>> >         - stable : if one subsystem has problems, the others don't
>> >                    depend.
>> >         - flexible
>> >         - independent low-level (not dedicted to one function)
>> >   con : - not just one mid-level part of the OS 
>> 
>> You mean a bottom system that can run all these systems natively? That
>> sounds very generic, but... all mentioned systems have to be translated to
>> run on this virtual machine - a virtually impossible task.
>
>Well, every OS implements a virtual machine. The above just means that all
>subsystems run completely seperate on top of the kernel  , on top of the
>basic services.
>It is however, not a good system, because every subsystem would have to
>implement its own file system, tcp-ip etc. In certain cases, this can have
>advantages, but in most not.

OK, we skip this one.

>> 
>> >- A complete independent low-level part wich runs your systems, and
>> >  your system can off course run POSIX,Win32,OS/2,DOS etc on top of it,
>> >  together with its own API (Like NT)
>> >  
>> >  pro : - one mid-level part, your system, which runs the other mid-level
>> >          parts
>> >        - still very flexible
>> >  con : - not as fast
>> >        - other subsystems depend on the basic subsystem
>> 
>> This would lower performance for every system... just taking advantages of
>> the former method out.
>
>Well, with "not as fast", I meant not as fast as the first design, but it
>is still pretty fast.
>Actually, this is the best design, I think, because your system can
>provide the file system, networking protocols etc, to the other
>subsystems,so export it objects to the others. It represents certain
>objects as files to the POSIX and Win32 subsystems,.... 

I'd still want the low-level objects (the ones in mOS) to handle the
hardware directly.

>> >- A low-level that allready implements the basic parts of your system,
>> >  so the low-level are objetcs too.
>> >  
>> >  pro : - fast
>> >  con : - larger and less stable low-level
>> >        - all mid-levels depend on the implementation of the basic
>> >          "mid"-level system in the low level.
>> >        - harder to develop low-level
>> >        - low-level dedicated to your system.
>> 
>> This was about the way I thought about it. It would make my system faster
>> (since designed for it from the beginning), and not affect the performance
>> of other systems very much, compared to the first model (just another
>> interface to the hardware).
>> The low-level layer would indeed be bigger, including much of the
>> mid-level... just like you said. This does however bring one advantage...
>> mid-level functions can, if wanted, circumvent the low-level stage, going
>> directly to the hardware, since it's a part of the hardware specific code
>> anyway.
>> It's still possible to create mid-level functions that are
>> hardware-independant. Faster to develop, slower to run.
>
>But it makes the system fragile and more difficult to develop:
>Look at WindowsNT. All services run in the low level, and even in kernel
>mode. Whenever MS tries to add something, this makes NT unstable. That's
>the reason NT still uses DirectX 3 : if they would add newer DirectX
>versions to NT, this would make NT unstable. Indeed, it would make your
>system faster. That's exactly what MS did : up to version 3.51, the GUI
>ran in user mode, but in NT4, they let it run in kernel mode, in the
>executive. This makes the UI somewhat faster, but is really a big error in 
>architecture design. It's why NT is so difficult to get stable.  

I don't want another NT. I would never make everything into low-level
objects. The only things that should go there are hardware-dependent code
and the kernel.
Could you maybe explain a little more exactly how the low-level parts would
differ between this and the former method?

>Whith low level, I mean really the LOW level, so only the basic services:
>  - threads , cpu scheduling
>  - memory spaces, memory scheduling
>  - hardware access control
>  - hardware interrupt control & handling
>  - cpu exception control  & handling
>  - inter-process communication.

I think something inbetween method 2 and 3 would be good:
Have the low-level be directly represented as and communicated with as
objects. Only put a minimum of functions there (hurting performance, but
still), and have the rest hardware-independant.
Speed could be improved by implementing singe mid-level features in the
low-level, but nothing should depend on that it is one way or another. If
not done by the low-level, the middle layer(s) do(es) that.

>Processes, memory management, drivers, file system, networking: it can
>all be implemented by the middle level, the level that gives an OS its
>functionality and provides the API for the high level and user .  

Processes - Multitasking has to be low-level, since it's closely related to
the kind of processor, if that's what you mean. However, processes are not
concerned with the type of hardware.
Memory management - Isn't this dependant (at least for resonable
performance) on the hardware availible?
Drivers - Device drivers are  of course low-level... could you mention some
examples of middle-level drivers?
FS'es  and networking - Yes, mid-level.

>> I looked back at your definitions and saw you defined the kernel
>> low-level... this would mean that in the first two models, at least *two*
>> kernels are needed - one for the completely independant part, and one for
>> this ('my' sounds so self-centered) design... it that really good?
>
>Don't be afraid to sound self-centered :-) I know what is meant.
>Your (how can I otherwise indicate it ?) design doesn't run as a "kernel",
>but as a normal set of user processes, perhaps with somewhat more
>privilege. This is the basic idea that led to the development of
>microkernels, still the best architecture today. 

mOS needs a kernel to implement the most basic stuff, like memory managment
and system calls. The kernel need to be there, only that it is small and
has delegated most jobs to ordinary processes.

>> >One more thing : you should think about a good name for your system.
>> 
>> I in fact already have a name for it, mOS (good or not). I haven't used the
>> name, since I didn't want the system look like something that's already
>> designed and implemented. And, we're working under the flag of UniOS.
>> 
>> If everybody agrees that this is the preferred system, we could just call
>> it UniOS.
> 
>I think UniOS should be the name for the whole system : kernel,
>subsystems, basic OS applications,etc. Your design can be part of UniOS,
>but Win32 can be too...

Sounds very good. Let's have it that way.

>I think this is the best desing: (hell, this costed me a lot of my
>text-mode graphical capabilituies :-) )
>
> ------------------------------------------
> | OS & user objects (applications)       |  HIGH LEVEL
> ------------------------------------------ 
>                 ||
>                                           ---------------
> ----------- -------- -------- -------
> | POSIX/X | | Win32| | OS/2 | | DOS |
> ----------- -------- -------- -------
>   ||           ||       ||      ||           MID LEVEL                      
> -------------------------------------- 
> |         mOS (unprivileged)         | 
> --------------------------------------
>                   ||
> -----------------------------------------------
> | Drivers,network, file systems (unprivileged)| 
> ----------------------------------------------- 
>      ||                                   ---------------
> -------------------------------------
> |        KERNEL (privileged)        |        LOW LEVEL
> -------------------------------------
>                 ||
> -------------------------------------
> |            HARDWARE               |               
> -------------------------------------

I don't like the idea... I want to make mOS the kernel.

>I hope it's not confusing...

No problem, it's quite clear, even if a bit low on color shades. :)

binEng

------------------------------------------------------------------------
To unsubscribe from this mailing list, or to change your subscription
to digest, go to the ONElist web site, at http://www.onelist.com and
select the User Center link from the menu bar on the left.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios