Re: [ANNOUNCE] Adeos nanokernel for Linux kernel

[Daniel Phillips <phillips@bonn-fries.net>]

On Wednesday 05 June 2002 13:15, Peter Wächtler wrote:
> > Improving the average latency of systems is a worthy goal, and there's
> > no denying that 'sorta realtime' has its place, however it's no substitute
> > for the real thing.  A soft realtime system screws up only on occasion,
> > but - bugs excepted - a hard realtime system *never* does.
> 
> Yes, in theory. You define hard realtime system in a clean room.
> Even QNX4 couldn't provide hard realtime when creating new processes.
> You had to start them beforehand - so you needed good system design.

With Adeos, you'd make the non-realtime OS do all the hard work of
starting the process, such as allocating the memory and locking it down,
then (one of) the realtime OS(es) just inserts the process into its
queue.  Once in the queue, the new process can exhibit realtime behavior,
but until that time there are no deadline guarantees and the realtime
application should not rely on any.  In other words, forking a realtime
process to handle an event in real time is a poor idea.

Similarly, loading a realtime driver to control some device that just
came online is not in general going to be a realtime process, but we
don't really care.  A machine starts when it starts (think about your
car in the winter) but once running, we expect it to keep running
without a hiccup.

> The OS is just a small part of that.
> 
> Even vxworks had problems with priority inversion ... and so on.

Here, the Adeos pipeline design exhibits a really nice property: you
can stack realtime OSes one on top of one another, so you could for
example, have one RTOS entirely optimized for microsecond-scale events,
another for millisecond-scale events, and a third for events with
timings measured in seconds.  Each has a completely independent set of
locks.  Alternatively, a slower-scale process can be forbidden from
acquiring a lock of a faster-scale process, but the reverse can be
permitted.

-- 
Daniel