(no subject)

> I've actually been pondering writing a much more informative document,
> and the call for submissions for the Usenix OS Design & Implementation
> symposium is making me think it's more than time. I know that the paper
> would be much more interesting if we had begun to do distributed stuff
> yet, so I'm a little undecided if it's time to do it yet.

Andy,

I think some things need attention before starting to present this work
at conferences.

I've spend the last two weeks reading through the vsta-list archive, reading
the code and did some live playing with vsta. But it has only been two weeks
and I didn't do any really serious devlopment on it so forgive me if some
of my comments have their origine in not been involved from the start.

[ And don't worry to much about the work implications of my comments, I may
  contribute quite a few things myself. ]

1. real-time

One of the reasons why I was initially atracted to vsta was that it was
published as a "real-time" (micro-kernel) OS. But when going through the
code and looking and the primitives and system calls I couldn't
really find a good justification for the "real-time" title.

Although you seperate real-time from background threads and timesharing
threads the scheduling policy you implement is strictly FIFO on the threads.
This is not sufficient to implement any real-time environment.

To accomodate the required real-time functionality we need to augment the
tfork system call to carry real-time thread attributes. The attributes
will carry information like wether the thread is periodic or not, the period,
the deadline(s), estimated exution time, start time, preemptibility constraints,
etc. A number of scheduling mechanisms are needed to be able to give
system implementors a good choice; I would want at least rate monotonic,
earliest dealine and leat laxity.

The other urgent items needed, are to supply the user space threads with
synchronization mechanisms. Currently we only have them in the kernel.
If you want to implement these with the possibility to offer priority
inversion protocols like priority ceilings, etc these primitives will have to
come from the kernel not a user level threads synch implementation, as
they have to closely cooperate with the scheduler.

Personaly if think we also need primitives to indicate preempatble regions,
etc. And also mechanisms to freeze all pages owned by a process/thread to
avoid page faults for that process.

If the VSTa community is very eager to comply to POSIX we should try to get
as much of 1003.4(a) (real-time extensions) into the interface (and of course
functionality in the design). With respect to the scheduling there is a
POSIX requirment to at least support FIFO and RR scheduling. I would want to
add at least rate monotomic, earliest deadline first and least laxity first.

I think we should give priority to real-time thread scheduling (1003.4a) over
the implementation of traditional real-time process scheduling (1003.4). This
off course means that we need a pthread interface to the kernel threads. If
cut out most of the signal stuff the pthread defeinition isn't much different
from any other thread interface, expect that it has explicit real-time
assignment hooks.

2. distribution.

Support for distribution is essential. And treating it as an "add-on" feature
may turn out to be a fundamental mistake. As a good micro-kernel should do
VSTa leaves it all to the user space to implement things, but until now we
have had not so very good experiences with user level implementations of
protocols stacks. Although Chris Maeda's work was great he still arrived
at times comparable to monolithic Mach and Ultrix. And we also know by now
that the way the packet filter/demultiplexer is build and is able to
interact with the device is crucial to get the better performance. As is the
quest to avoid crossing protection domains while moving the message through
the protocols. [Maybe you can comment on this Chris? as it is more your cup
of tea].

The packetfilter is an engineering issue, but basic support for the domain
crossing of data could become could an excellent feature of VSTa which would
avoid a lot of performance problems. Especially network file servers could
benefit from this.

We could also learn from Mach what not to do if you want to extended you port
& port capability space across a cluster of machines.

As an intemediate solution we could adapt the x-kernel as the network
server while working on better (real-time, non-real-time, etc) mechanisms.
The port of the xkernel is trivial as soon the mutex's etc are available
to user space. Be aware that the xkernel performance is bad and some of the
protocols are not fully implemented, but it would be a relatively easy start.

If we could solve these two problems and show extensive measurements of all
parts of the kernel, you would have good material for a paper.

--
Werner