scheduling, real-time and so on

There was a diskussion at the subject in the last days.
Let me add my 2 cents.

In my diploma I moved the complete scheduling out of the kernel,
giving this task to a user-object. The kernel ony provides a very
simple scheduler for system-boot and scheduler-exchange. The
user-object for scheduling provides a {process, task, thread, whatever
called} or a procedure to switch to / call up from the kernel for
scheduling. This way gives me the opportuntiy to incorporate all kinds
of scheduling into a system realising a very simple interface.
(BTW The interface *can* be made very efficient, if the kernel maps
the adressspace (o parts of it) of this object into it's own - paying
the price of security.)

Unfortunatly I did this on a different System and I have (at this time)
not the experience in VSTa nor the time to repeat it for VSTa.
But, why not to go this way in VSTa in the future?

So far the first cent, now the second:
Let me strongly agree with Andy to call for
1: keep the kernel micro
2: keep the code well structured and clean!
For this goals we may pay at other things.

Here (short) my experience :
The system used in my diploma (BirliX, sure you don't know)
was similar to VSTa in some aspects,
it has message-based process-comunication (network transparent, at
user-level you only see RPC's),
it has multi-thread-support (I still don't know, what it is good for,
even in VSTa) and monitors for mutex,
it has VM, segments, persistent memory,
it is still "real" micro-kernel as all I/O and stuff like that is
implemented by user-objects.
The system emulates Unix an runs X (therefor some kernel-extensions
where needed).
It far portable cause most of the code is system-independent and
modula-2.

I think with some development VSTa would come to this point.

But the work in my diploma didn't come over the stage of debugging for
some reasons:
1st: the "micro"-kernel-system, providing all the mentioned things
compiled at the sun 3/80 gets about 2 Meg.
2nd: even when there was a "strong structured" language used and only
a hand full people worked on it, applying some "good" coding-rules,
the code couldn't kept clean. (Therefor I appended a simple
grep-output from the source-directory to my diploma:
grep hack *.m[di]
about 3 pages...)
3rd: the system finaly suffered from a lot of side-effects
4th: nobody would ever know all parts of the system. But if there are
thousend ways to do the same thing, it will be done in hundred ways.
And they *will* assume about each other to go the same way (even if they
shouldn't do so). And they won't work together.

So I hope even VSTa can become simplyfied.
Don't add functionality to the kernel!
Add simple clear interfaces, if needed and move funtionality out.
It may cost some cpu-ticks, but the cpu's are really fast,
software-development is far to slow, because the systems are to
complex.

-----------------------------------------------------------------------------
Joerg Wittenberger email: jw@ibch50.inf.tu-dresden.de
Rietzstr. 32b jw6@mail.inf.tu-dresden.de
01139 Dresden
Germany

--- PGP PUBLIC KEY avialable on request or by finger ---
Received on Tue Mar 1 03:01:41 1994