Re: [PATCH] add device node locking possibility todvbcore

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

 



Trent Piepho wrote:
> On Fri, 17 Aug 2007, Markus Rechberger wrote:
>   
>>>> as I wrote earlier the thread can be idle/closed even before the node
>>>> gets closed (you can test that with kaffeine, and you can test the
>>>> other case with the scan utility)
>>>>         
>>> How can this happen? Afaics the fe thread may continue to exist after
>>> the device node was closed, but not vice-versa.
>>>       
>
> Yes, how can that happen?  What will make the dvb frontend thread exit before
> the device is closed?
>   

I don't know. I should probably spend sometime reminding myself of the 
purpose of the thread.

> Maybe it would be a good idea to do what Andreas suggested and have the
> frontend release function block until the frontend thread has exited.  AFAIK,
> the thread hanging around after the device is closed does nothing but cause
> problems.  It's a very common FAQ, "Q:  Why does it mythtv not work if I
> change from a digital channel to an analog one?  A:  You need to set
> dvb_shutdown_timeout to 0." What's the purpose of dvb_shutdown_timeout > 0?
>
>   

We should be clear that the ts_bus_ctrl isn't design to lock or version 
count in any way. The purpose of the callback is to allow the bridge to 
determine whether the it has sufficient hardware resources to allow the 
ops open to complete (assuming that the callers wants data). The best 
example of this todate has been the HVR1300 sub-drivers in which a V4L 
and DVB ops structures both need to access frontends on the single PCI bus.

Having a DVB application interfere with the V4L application's use of the 
bus isn't acceptable.

Personally,  I think ts_bus_ctrl needs to be replaced with a single 
resource allocation/deallocation mechanism that extends beyond simple 
bus negotiation into tuners, demods, encoders and other devices.

>>> ts_bus_ctrl does a kind of reference counting.
>>>
>>> For readers:
>>> - fe->ops.ts_bus_ctrl(fe,1) is called during open
>>> - fe->ops.ts_bus_ctrl(fe,0) is called during close
>>>
>>> For the one and only writer:
>>> - fe->ops.ts_bus_ctrl(fe,1) is called during open
>>> - fe->ops.ts_bus_ctrl(fe,0) is called when the thread exits,
>>>   usually after close
>>>       
>
> So, how do you tell if the ts bus is already locked?
>
>   

Until now it's never been a requirement.

>> I didn't want to write it but this is also what I would do, and I
>> would also include the other dvb device nodes.. it doesn't make sense
>> to keep them open as non functional dummies, or even allow people to
>> open these nodes if the dvb mode is locked.
>>     
>
> What about a device with two frontends?  Maybe the DVB-T/Analog frontend is
> locked by the V4L device, but you can still use a DVB-S frontend with dvb.  In
> that case the demux could still be opened and used.
>
>   
The HVR1300 (and HVR3000 / 4000) prohibit this by using ts_bus_ctrl, 
these are good examples.

- Steve


_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux