[unios] No kernel

[Tril]

From: Tril <dem@tunes.org>

Pieter Dumon wrote:
> > > We can use a "no-kernel" design. All hardware, so cpu and memory too,
> > > is abstracted by an object each, running in a seperate memory space etc.
> > > This would make it all very flexible, and probably stable, but not fast.

I realize the term "no kernel" is broad and can be used for any design
that is decentralized, but you should still give credit where it is due,
and be clear as to what you mean when you say "no kernel."  Emmanuel Marty
coined the term "no-kernel" for his project, which isn't anything like the
description you wrote.  Here I take it to mean you want to talk about
possible designs of decentralized systems.  Examples are Emmanuel Marty's,
or a microkernel, or TUNES, or something else.  It should be the goal of
this thread to decide WHICH MODEL UniOS will use.  Let's discuss the
alternatives. 

Emmanuel Marty has a minimal "executive"  (smaller than a kernel) that
loads objects into kernel space (superuser mode).  Each object is in a
special binary format with multiple entry points.  If you want to know
more about this design please e-mail me and I'll tell you how to get more
info.

What you said sounds more like a microkernel, because you imply the
objects are running in user space.  However, each resource being
abstracted by a separate object isn't exactly a microkernel either.  It's
more like what we're doing in TUNES:

In the TUNES project, we're not using EITHER Emmanuel Marty's "no-kernel" 
NOR a microkernel.  Every aspect of the system is abstracted by an object,
yes.  But objects don't run in "user mode" or "kernel mode", because
objects aren't tied to a specific low-level representation.  The
implementation of any object or group of objects changes dynamically,
while being verified to conform to its specification.  This design is
extremely flexible, and can be stable if the programmer and user both
desire it for a particular object. 

As for speed, it is my opinion that almost every single system,
programming language, and most apps, were designed for speed, at the cost
of every other single desirable attribute to the user or programmer.  In
other words, making tradeoffs to gain speed in the short-term is the main
reason why we have a "software crisis" at all.  If you want your OS to be
universal, it cannot make concessions to speed.  In TUNES, we consider
"speed" to be how quickly the user can get their job done.  That means
that total control over the system, and being easy to use, is of a higher
priority than "runs fast on this CPU."  With such a flexible system, the
system designers cannot possibly know what "efficiency" means for every
single user.  First the user must decide what the system will be used for,
then optimizations for speed can take place.  Otherwise the system is not
"general-purpose", or universal if you like.

David Manifold <dem@tunes.org>
This message is placed in the public domain.


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