On Fri, 8 Oct 1999, Andrew Apted wrote:
> James Simmons writes:
>
> > > There are easier ways to block a process than to modify the scheduler
> > > itself. Check out the vt_waitactive code in drivers/char/vt.c and see
> > > if that is ameniable to your problem.
> >
> > This blocks the current process. What I need to do is block all the
> > process that could be using a particular video card.
>
> 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:
* Able to trap freely at the interrupt and fault level and hold off the
scheduler for an arbitrary period of time;
* 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.
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... see! Microkernels _are_ the way to go! |->
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
