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 > Regards, > > Michael Krufky > > -- Markus Rechberger _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
