Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: Kernel-Patch to make VDR undisturbable



On Friday 05 April 2002 18:38, Matthias Loetzke wrote:
> Andreas Schultz (aschultz@cs.uni-magdeburg.de) schrieb:
> > > Do you see a possibility in userspace to make sure that VDR runs
> > > undisturbed? I do not. IMHO a kernel modification is unavoidable.
> >
> > yep, SCHED_FIFO/SCHED_RR ;-)
>
> I have to correct my last mail. I looked further into the kernel-souces,
> and I agree with you, that it is possible.
>
> VDR was never designed to be realtime scheduled, so you will need a
> completly different design.
> Doing the nessecary changes therefor will be close as much work as a
> complete rewrite of the VDR code.
> It must be _guaranted_ that neither VDR nor the DVB-driver will ever lock
> other processes out under any circumstances. Thats close to impossible with

I'm not sure what you mean by this. rt sheduling still allows the program to 
wait for I/O operations and to give up it's time slice. During wait for I/O 
operations, the kernel will automaticly (as always) give the CPU to some 
other process. If you have to wait inside the program you just have to avoid 
busy wait loops. Doing this is not really difficult.
Things like blocking reads/writes, poll/select, mutex_lock() on locked 
mutexes, cond_wait will automaticly allow lower priority processes to run.

I have tested my buffer syncing patch with SCHED_FIFO and it works so far. 
Even heavy disk activity during replay doesn't disturb the output any more.

There are still some possible problems in the recording and transfer mode 
stuff, which i have no tested yet. I'll have a look at recording, but 
transfer mode has to be done by someone else, as i have only one card. Also 
the EIT stuff needs to be tested.

> a complex programm! (but quiet easy using my kernel patch (which lets VDR
> behave somewhat similar to a realtime process without dangers))
>
> Yes, a rewrite of VDR for rt-scheduling would be the cleanest solution, but
> to stay realistic I do not think anybody is willing to do that work.

IMHO, this is not as difficult as you suggest. Much of it will only be a 
cleanup the current locking and syncing stuff - which is needed anyway.

Andreas




Home | Main Index | Thread Index