> > Well I think there are ways to put arbitrary processes to sleep
> > waiting for a semaphore or whatever. Point is: modifying the
> > scheduler WONT go down well with the top linux dudes, I suspect
> > they'll reject that very very hard (and rightly so IMHO).
>
> 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:
Yeap. I can't agree with you enough. This is what I'm working on now.
DRI uses kernel semaphores for their locking. I don't think it can make
the cut like a good schedular could.
> * Able to trap freely at the interrupt and fault level and hold off the
> scheduler for an arbitrary period of time;
Yes very important. Especially to prevent a context switch while filling
up a buffer. You can confuss the accel engine if you you start filling in
other types of date. Most likely the accel engine will just sit their
waiting.
> * Able to schedule down arbitrary processes in the presence of hardware FIFO
> watermark violations, and to directly program the same FIFOs;
>
> * Able to extend these guarantees to userspace in clean, well-defined
> abstractions.
The next step is to design the clean system. This will have to clearly
thought out.
> I guarantee you that the windows drivers and windows itself make use
> of these features, and that is why a even a brokedown POS OS like Win98 can
> play constant rate streamed data much better than Linux can. There is no
> reason that RTLinux could not give us some or all of these guarantees,
> however...
Yeap. I plan to change that.
