[linux-dvb] [PATCH] function for checking if the dvb framework is idle
mrechberger at gmail.com
Wed Aug 15 16:38:52 CEST 2007
On 8/14/07, Markus Rechberger <mrechberger at gmail.com> wrote:
> On 8/14/07, Michael Krufky <mkrufky at linuxtv.org> wrote:
> > Markus Rechberger wrote:
> > > On 8/14/07, Christoph Pfister <christophpfister at gmail.com> wrote:
> > >> Hi Markus,
> > >>
> > >> [ although you shouldn't overrate my opinion here I'm giving my $0.02 ]
> > >>
> > >> The problem with this approach are race conditions.
> > >> You can't reliably use the result of this function if you don't ensure
> > >> that no thread is started during / after the query. As far as I
> > >> understood your idea you try to solve this issue with the
> > >> allow-dvb-files-to-be-locked patch. But that patch doesn't handle file
> > >> descriptors which have been opened before you did the "lock".
> > >>
> > >> Of course you can do additional work to fix that too - but imho the
> > >> easier (and safer from a design-pov) approach is to do the locking at
> > >> the bridge level as Steve did. I don't think that there are issues
> > >> with handling it there - as neither dvb-core nor the frontends access
> > >> the device directly (dvb-core via callbacks and the frontend via i2c
> > >> adapter). Or do I miss something here?
> > >>
> > >
> > > There's some other code for checking if the filehandles are open but I
> > > don't need that patch to go into the framework, it will be stored in
> > > the local driver.
> > > For now my aim is to bring in the most needed patches in and nothing
> > >
> > > Markus
> > Markus,
> > You seem to be avoiding the issue.
> > Christoph is trying to explain to you the same idea that I have tried to
> > explain
> > to you in the past -- locking of the device for use between analog and
> > digital
> > should take place at the bridge driver level.
> > This is what Steve Toth has done for the :8802 port in the cx88 driver, by
> > only
> > allowing cx88-blackbird -or- cx88-dvb to use the hardware at any given
> > moment.
> > Since it is the bridge hardware that determines whether or not the device
> > a
> > combo device (both analog and digital can be used concurrently) or a
> > device (only analog or digital can be used, one at a time), and it is the
> > bridge
> > hardware itself, that has the limitation. the locking is only appropriate
> > the
> > level of the bridge driver itself.
> Steve's patch basically does the same as my initial patch does.
> The question should moreover be when do you define that a device is in
> a certain mode.
> I have successfully implemented that way into the existing driver
> which is in question and it works as expected.
> And yes the bridge always knows in what mode the code is in. I
> moreover think there's a misunderstanding here.
> Still the bridge driver can decide what it wants to do, and in case of
> the em28xx driver I want to fully lock the device since it's not
> possible to use analogue TV, svideo, composite and DVB/ATSC at the
> same time.
Allthough this patch is still in the queue of required patches. I
would still like to see that one upstream since it would be required
by a few drivers for checking if they're really idle.
More information about the linux-dvb