On Mon, 8 May 2006, Andrew de Quincey wrote: > On Saturday 06 May 2006 19:44, Andrew de Quincey wrote: > > On Saturday 06 May 2006 18:55, Patrick Boettcher wrote: > > > Hi list, > > > > > > I'm about to write the mt2060-driver using dvb_tuner and dvb_tuner_ops > > > and I stumbled over something: > > > > > > dvb_tuner_ops inside dvb_frontend_ops is not a pointer but a real field. > > > That's why the static dvb_tuner_ops of a tuner have to be copied directly > > > into dvb_frontend_ops.tuner_ops . > > > > > > This mechanism is different to dvb_frontend_ops which is (and has been > > > for a long time) a pointer in dvb_frontend. That's why every demod-driver > > > is having a field of dvb_frontend_ops in its private-state-struct and > > > using the reference for filling the pointer-field in dvb_frontend. > > > > > > Is there a specific reason for having the same "mechanism" implemented in > > > different ways I maybe missed during the discussion? If not, would it be > > > useful to change the dvb_frontend_ops* into dvb_frontend_ops and be > > > coherent with the new dvb_tuner_ops: > > > > > > - It would save at least two lines of code per demod-driver, > > > - would make it a little bit easier for newbies to understand how it > > > works and > > > - would avoid stupid mistakes because you would have to copy the > > > dvb_frontend_ops always, currently you can assign the static pointer > > > directly, which is dangerous. > > > > yeah I see what you mean - the last reason is a _really_ good reason for > > doing this (the others are more cosmetic, but still valid). > > Patrick - are you working on this, or should I investigate it? I hate to put work on someone's list especially on your list, but I will probably not be able to do anything before the weekend... Sorry. OTOH it is not so urgent, is it? So it could wait. Yes I will do it. regards, Patrick. _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
