On Thu, 6 Jul 2006, Andrew de Quincey wrote: > On Thursday 06 July 2006 01:57, Trent Piepho wrote: > > Or, just change the one function in dvb-bt8xx.c that calls > > cx24110_pll_write() to use fe->ops.write() directly and get rid of the > > whole cx24110_pll_write() function. I looked into this a bit more, and the only card driver that uses cx24110 is dvb-bt8xx. cx24110_pll_write() is only called from one function, cx24108_tuner_set_params() which is in dvb-bt8xx.c. It seems like it would make the most sense to move that function from dvb-bt8xx.c to cx24110.c. It looks like it's programming the cx24110 chip and any card using a cx24110 would need it, so conceptually it belongs with the cx24110 code and not with the bt8xx code. It's also more efficient, since the bt8xx driver won't include that code for cards that use different frontends. I haven't looked into it, but maybe the three other ops.write() users aren't really necessary in the same manner. > > In the Kconfig patch, I'd get rid of the extra checks for the kernel > > version. The requirement of kernel 2.6.17 in versions.txt for > > DVB_CORE_ATTACH will take of everything. What's the point of versions.txt > > if you're just going to stick a version check in the code anyway? > > I thought about that, but remembered someone could do "make kernel-links" > against a pre-2.6.17 kernel - and that will bypass versions.txt - so I left > the version check in. That's a good point, I hadn't thought of that. Still, there are plenty of drivers which will crash on older kernels and they don't have version checks. > > Only allowing FE customization when DVB_CORE_ATTACH is on seems backward. > > Customizing which frontends are built makes the most sense when you still > > have static dependencies or are not even using modules. There is no reason > > you can't customize both with and without dvb_attach, so why disable it? > > For static building, would that not require spreading #ifdefs everywhere > throughout the code? I really don't want to do that. For the drivers which support the largest number of frontends, the #ifdefs are already there, so it's more a matter of not removing them rather than adding new ones. Actually, most of them were there before customizing front-ends was possible, for some other reason that probably no longer exists. All the #ifdefs around the front-end header files aren't needed for front-end customization. I don't know why they're there. Your idea to put empty static inline versions of the attach functions in the front-end header files when that front-end is turned off would get rid of the rest of the #ifdefs. It's slightly less efficient since the drivers would include front-end specific code that won't be used and would have been #ifdefed out. Some functionality could be added though, the empty attach functions could printk "Front-end foo support was disabled at compile time" or something like that. Will dvb_attach() work on a static inline non-EXPORT_SYMBOLed function? _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
