[unios] Re: Generic design. More comments

[Anders Petersson]

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

>From: Pieter Dumon <Pieter.Dumon@rug.ac.be>
>
>OK, much clearer now. Sounds good.  It is indeed very flexible and
>powerful. The only thing that might degrade is performance...

Performance is the biggest hassle. I guess some effort has to be put into
this.

>Now, how can we implement the low-level part of the OS to support this?
>There are some options:
>First some definitions:
>  low-level : kernel, hardware interface
>  mid-level : user management,security, file system etc
>  high-level: OS system programs, UI etc

OK, let's dig in.

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

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

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

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?

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

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