[linux-dvb] Re: dvb-kernel budget tests

[Emard <emard@softhome.net>]

On Mon, Feb 17, 2003 at 01:05:28PM +0100, Holger Waechtler wrote:
> Emard wrote:
> >On Mon, Feb 17, 2003 at 11:54:55AM +0100, Ralph Metzler wrote:
> >
> >>Hi,
> >>
> >>Emard writes:
> >>> I was thinking of a possible workaround in higher layers. 
> >>> So the current problem is:
> >>> 
> >>> 1. irq tasklet constantly uses sw_demux
> >>> 
> >>> 2. applications want to change sw_demux parameters in
> >>>    runtime
> >>> 
> >>> 3. if applicatons use semaphore lock for sw_demux and 
> >>>    tasklet attempts to execute (too long ?) locked 
> >>>    sw_demux machine will freeze
> >>> 
> >>> So I (foggy) see 2 ways out of this:
> >>> 
> >>> WAY 1
> >>> 
> >>> Have a copy of all sw_demux related structures.
> >>> Applications will change it at will, and have semaphores
> >>> to differentiate one from another, but not from the tasklet.
> >>> 
> >>> When application changes the sw_demux, it will keep it 
> >>> locked and inform tasklet that changes have been done
> >>> by incrementing one byte somewhere in the tasklet readable
> >>> data. Tasklet will it its new IRQ cycle copy sw_demux stuff
> >>> to its active profile and somehow send application the message
> >>> that it has accepted the setting so lock can be removed.
> >>> 
> >>> 
> >>> WAY 2
> >>> 
> >>> Have some queue of small changes commited to sw_demux but
> >>> not yet applied. When tasklet executes its next IRQ, it will
> >>> go through the queue, applying changes to sw_demux structures
> >>> and use there. Mutual locking of the queue may be tricky.
> >>
> >>
> >>But this  will not work with the big cards. They need to sleep
> >>when talking to the AV7110 and waiting for reply. 
> >>A tasklet cannot sleep. 
> >>This would even be the case if you change the communication
> >>with the AV7110 to use some kind of message queues because
> >>filter setting needs a response. 
> >>Other cards with a separate processor will need that too.
> >
> >
> >Sleeping in the kernel is as well not acceptable even if 
> >tasklet could sleep, it will jitter the machine.
> >
> >How about making an userspace daemon that will actually talk 
> >to av7110 and feed back data to kernel?
> >
> >Kernel driver would provide only saa7146 transport interface.
> 
> ?!?
> 
> the common way to do this is that the ioctl/read/write function 
> initializes a communication state machine and issues the start command 
> to the hardware. Then it falls asleep and the interrupt handler wakes up 
> the calling process when the communication state has changed. The ioctl 
> returns when communication either failed or finished successfully. An 
> timer might get initialized as watchdog for buggy hardware.
> 
> Well - these state machines can get tricky but are the proper way to 
> solve these problems. Threads like the arm_mon should go away at some point.

OK, I'd rather see the bloat go away.

I'd like to comment something that I don't know is it handled
properly.

Imagine this: TS stream being played by some application
and sw_demux is initialized to filter pids for that
application. Then comes another application that wants
to also filter something else.

Another application wants to fetch different pid, so it
wants to update sw_demux structures. As we now have list,
and not a single integer there are more problems arising.

List fetch/update is complex operation, memory allocation,
pointer arithmetic and data read/write.

Consider vpeirq is calling sw_demux regularly to filter data,
while at the same time we try to update the sw_demux pid list. 

In the middle of updating, vpeirq calls sw_demux and finds 
halfway-updated list. That could be good chance to get OOPS?

There has to be some logic in the upper layers to work around
this. Can state machine handle that

Emard


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.