On 8/14/07, Markus Rechberger <mrechberger@xxxxxxxxx> wrote: > On 8/14/07, Michael Krufky <mkrufky@xxxxxxxxxxx> wrote: > > Markus Rechberger wrote: > > > On 8/14/07, Christoph Pfister <christophpfister@xxxxxxxxx> 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 > else. > > > > > > 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 > is > > a > > combo device (both analog and digital can be used concurrently) or a > hybrid > > 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 > at > > 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. > > Markus 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. Markus _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
