> IIRC, IRIX and AIX do just that. It is a specialized type of hard
> realtime guaranteed scheduling for the display and console subsystems. And
> regular kernel semaphores are not going to be able to give you hard realtime
> guarantees. The whole display and console system needs to be:
>
> * Able to trap freely at the interrupt and fault level and hold off the
> scheduler for an arbitrary period of time;
RTlinux can do that. This is needed to make sure data is transfered full
to the accel engine for each accel command. You could confuss the accel
engine otherwise. The way RTLinux works is it reprograms the clock to go
off at specific times. RTLinux works better on SMP machine than UMP
becuase the special clock is need to handle SMP motherboards. Also the
rtl_schedular is the main function of the kernel. The regular schedular is
called when the rt_schedular is idle. You can set the rtl_schedular to be
periodic.
> * Able to schedule down arbitrary processes in the presence of hardware FIFO
> watermark violations, and to directly program the same FIFOs;
This would have to be added. I see from RTLinux it depends heavly on
FIFOs. What are FIFO watermark violations?
> * Able to extend these guarantees to userspace in clean, well-defined
> abstractions.
Hum. Explain what you have in mind.
Well I have joined the RT linux team and I'm studing their code. Do you
really think going RT linux is the way to go? The big thing always thrown
in my face is performace. If we can design a safe accel system that can
outperform DRI we got it made >:->
Note:
When you switch the kernel to RT mode the regular schedular does not
work as effiecently. Since RT process take far greater precedence the
other process suffer a preformance hit. Of course while playing Quake 3 I
don't think the average use will be worring that syslogd is not running
as often as it was before.
