Re: Ada Microkernel?

[OPERA <vincent.diemunsch@edf.fr>]

Hello,

I am not sure to have completely understood the problem, because I'm no
specialist, but what would you think of the following :
- take as a basis for an new general purpose OS the RT Ravenscar. This Real Time
OS in Ada would be the micro-kernel. It provides a predictable management of
simple tasks (call them Ravenscar tasks) and static memory allocation.
- Then developp around this micro kernel, using GNORT, all the services needed
by a general purpose kernel, ie the management of  dynamic allocation of ADA
tasks (threads and processes) and ressources. This services would be provided by
"servers" (simple protected objects and Ravenscar tasks). This would involve
adding to the Ravenscar micro-kernel only the very few primitives needed to
handle dynamic tasks, for exemple to execute or suspend execution of a given ADA
task or modifiy it's environnement. The goal here is to keep the micro-kernel as
simple and predicatble as before for Ravenscar tasks, but to allow ADA tasks to
execute when it is idle. We can do the same for memory : the micro-kernel would
simply provide the ability to attach a memory segment to a task. The managment
of dynamic memory would be kept to the "memory service".

Therefore :
- a Real Time application would be attached to the system as a sort of driver,
and built with GNORT using Ravenscar restrictions.
- conventionnal application (developped with GNAT) would run just like on any
other OS.


Vincent




Marin David Condic a �crit :

> The key to it is predictability. Or at least uniformity so you know that
> your timing tests are going to be good. One could argue all day about this
> OS versus that OS and their relative suitability for realtime work, but I
> think that to be a candidate at all, the OS has to provide deterministic
> behavior and stability. How compatible is this with the goals of a
> "workstation" OS? I don't know. I think that from a requirements viewpoint,
> one might insist that a single process should be able to run in some mode
> where it can guarantee that its cycle time is 100% consistent. (You could
> ask if this is with or without threads within the process - I'd think we
> would want that.) As long as the OS will let the process run in a guaranteed
> consistent cycle time, the rest is just efficiency and appropriate hardware
> to make sure the cycle time is sufficiently fast.
>
> AFAIK, the two things that this would impact the most would be the scheduler
> and the device driver model (interrupt handling figuring into the device
> driver model as far as I'm concerned.) If you had at the core of your OS
> these two things built such that they were suitable for realtime, you'd have
> something that could be marketed in a large variety of places. If you could
> build a workstation OS on top of that - even if it had to have some
> different operation mode - you'd have an environment that was quite valuable
> for realtime/embedded development, for reasons that should be obvious.
>
> Can an OS provide at least one "realtime" process and still allow other
> processes to run in an acceptable manner? I don't know if this is doable,
> but it would certainly be cool if it did exist. I'd even accept some sort of
> configuration switch at boot time or OS build time just so you could have
> essentially the same OS on your PC as would be used in the realtime/embedded
> app. That enables a huge amount of development to occur on the desktop
> rather than the lab - at an enormous cost/time savings.
>
> MDC
> --
> Marin David Condic
> Senior Software Engineer
> Pace Micro Technology Americas    www.pacemicro.com
> Enabling the digital revolution
> e-Mail:    marin.condic@pacemicro.com
> Web:      http://www.mcondic.com/
>
> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:wG3%6.1950$Kf3.21097@www.newsranger.com...
> > In article <9hi6fv$lop$1@nh.pace.co.uk>, Marin David Condic says...
> >
> > For schedulability analysis, I presume one would handle this either by
> adding
> > the appropriate multiple of the max scheduling delay (which the OS vendor
> would
> > hopefully provide), or by showing that the task in question completes in
> less
> > than one scheduling interval. Being able to provide that max scheduling
> delay
> > (and have it be a resonable number) is where I think most consumer OS's
> would
> > have trouble.
> >