On Thu, 7 Oct 1999, Jon M. Taylor wrote:
> 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! |->
When _this_ mail would be forwarded to Linus personaly and directly, it
could be sure, that this stuff will get into the kernel 2.5.x ...
Christoph Egger
E-Mail: [EMAIL PROTECTED]
