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? _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
