Sorry for the late reply, but KS and LPC got in the way. Also added kbuild to the Cc. On Tue, 2010-10-26 at 09:37 -0200, Mauro Carvalho Chehab wrote: > Hi Steven, > > Em 26-10-2010 02:15, Steven Rostedt escreveu: > > I'm currently finishing up an automated test program (that I will be > > publishing shortly). This program does various randconfig builds, boots > > and tests (as well as bisecting and patch set testing). But enough about > > it. > > > > I hit this little build bug that is more annoying than anything else. If > > I have the following configuration: > > > > > > CONFIG_DVB_USB_DIBUSB_MB=y > > CONFIG_DVB_USB_DIBUSB_MC=m > > CONFIG_DVB_USB_NOVA_T_USB2=m > > > > It fails to build with this error: > > > > ERROR: "dibusb_dib3000mc_frontend_attach" [drivers/media/dvb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined! > > ERROR: "dibusb_dib3000mc_tuner_attach" [drivers/media/dvb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined! > > ERROR: "dibusb_dib3000mc_frontend_attach" [drivers/media/dvb/dvb-usb/dvb-usb-dibusb-mc.ko] undefined! > > ERROR: "dibusb_dib3000mc_tuner_attach" [drivers/media/dvb/dvb-usb/dvb-usb-dibusb-mc.ko] undefined! > > > > Those undefined functions are defined in > > drivers/media/dvb/dvb-usb/dibusb-common.c, but are surrounded by: > > > > #if defined(CONFIG_DVB_DIB3000MC) || \ > > (defined(CONFIG_DVB_DIB3000MC_MODULE) && defined(MODULE)) > > > > Which Mauro updated in Dec 2007 with this commit: > > 4a56087f3b7660c9824e9ec69b96ccf8d9b25d1c > > due to just having CONFIG_DVB_DIB3000MC not enough. > > > > Well, this is not enough either. Why? > > > > On build the object dibusb-common.o is built first because of the > > DVB_USB_DIBUSB_MB being builtin kernel core. Thus, it gets built with > > the preprocessor condition false. > > > > Then when the compile gets to the modules, the object dibusb-common.o > > has already been built, and gets linked in as is. > > > > We end up with the functions not defined and we get the above error. > > > > My question: Why does that preprocessor condition exist? Can't we just > > build those functions in regardless? > > Not sure if I understood your question. Short answer is: No. What about just changing it to: #if defined(CONFIG_DVB_DIB3000MC) || defined(CONFIG_DVB_DIB3000MC_MODULE) Looking at the kbuild system scripts/Makefile.lib we have: # When an object is listed to be built compiled-in and modular, # only build the compiled-in version obj-m := $(filter-out $(obj-y),$(obj-m)) So if this is defined as both a module and builtin, the module version will never be built. Then we need that code in that #if block regardless. No need for testing the define(MODULE). > > > > A detailed explanation follows: > > <detailed> > > On DVB drivers, there are a few separate > components: > - Tuner - receives the signal from antenna, converting them into an > intermediate frequency, tune to a station; > - Demod - decodes the intermediate frame into a MPEG-TS; > - Bridge - talks with the PCI/USB/.. bus and send/receive commands to Demod/Frontend. > > The tuner + frontend + satellite controller are called frontend. > > On a typical design, tuners are a separate chip, interconnected via an I2C bus, and > the demod may be separate or integrated with the bridge (or with the tuner). > > Since the design is modular, the same frontend may be used by different bridges, and a > given bridge may work with more than one frontend, depending on the specific device you may have. > > So, we basically have one Kconfig option for each component, to allow building kernels with > the minimum footprint. > > For example, picking a random DVB bridge: > > config DVB_DM1105 > tristate "SDMC DM1105 based PCI cards" > depends on DVB_CORE && PCI && I2C > depends on INPUT > select DVB_PLL if !DVB_FE_CUSTOMISE > select DVB_STV0299 if !DVB_FE_CUSTOMISE > select DVB_STV0288 if !DVB_FE_CUSTOMISE > select DVB_STB6000 if !DVB_FE_CUSTOMISE > select DVB_CX24116 if !DVB_FE_CUSTOMISE > select DVB_SI21XX if !DVB_FE_CUSTOMISE > select DVB_DS3000 if !DVB_FE_CUSTOMISE > > The components at the select are the frontend. > > In this specific case, there's just one demod supported (stv0299), > but it allows using 6 different types of tuners. > > If you want to build a kernel with a minimal footprint, and if you have just one device type, > you'll need only one tuner driver. > > </detailed> > > In the specific case you're mentioning, we have the following bridge drivers: > > config DVB_USB_NOVA_T_USB2 > tristate "Hauppauge WinTV-NOVA-T usb2 DVB-T USB2.0 support" > depends on DVB_USB > select DVB_DIB3000MC > select DVB_PLL if !DVB_FE_CUSTOMISE > select MEDIA_TUNER_MT2060 if !MEDIA_TUNER_CUSTOMISE > > config DVB_USB_DIBUSB_MB > tristate "DiBcom USB DVB-T devices (based on the DiB3000M-B) (see help for device list)" > depends on DVB_USB > select DVB_PLL if !DVB_FE_CUSTOMISE > select DVB_DIB3000MB > select MEDIA_TUNER_MT2060 if !MEDIA_TUNER_CUSTOMISE > > config DVB_USB_DIBUSB_MC > tristate "DiBcom USB DVB-T devices (based on the DiB3000M-C/P) (see help for device list)" > depends on DVB_USB > select DVB_DIB3000MC > select MEDIA_TUNER_MT2060 if !MEDIA_TUNER_CUSTOMISE > > > And the following frontends: > > config DVB_DIB3000MC > tristate "DiBcom 3000P/M-C" > depends on DVB_CORE && I2C > default m if DVB_FE_CUSTOMISE > help > A DVB-T tuner module. Designed for mobile usage. Say Y when you want > to support this frontend. > > config DVB_DIB3000MB > tristate "DiBcom 3000M-B" > depends on DVB_CORE && I2C > default m if DVB_FE_CUSTOMISE > help > A DVB-T tuner module. Designed for mobile usage. Say Y when you want > to support this frontend. > > The makefile for it is: > > obj-$(CONFIG_DVB_DIB3000MB) += dib3000mb.o > obj-$(CONFIG_DVB_DIB3000MC) += dib3000mc.o dibx000_common.o > obj-$(CONFIG_DVB_DIB7000M) += dib7000m.o dibx000_common.o > obj-$(CONFIG_DVB_DIB7000P) += dib7000p.o dibx000_common.o > obj-$(CONFIG_DVB_DIB8000) += dib8000.o dibx000_common.o > > For sure, the Makefile is not doing the right thing, for a random config on those drivers, > as some of the frontends may be compiled builtin, while others may be compiled as module. > > I can see two possible fixes: > > 1) create a Kconfig option for dibx000_common, and let the other frontends > select/depend on it; > 2) change the build system to not allow having some frontends builtin and others as modules. > > Probably, (1) is easier than (2). Yet, (2) may also fix other hidden cases like that. Or we just don't test for define(MODULE). If either CONFIG_DVB_DIB3000MC or CONFIG_DVB_DIB3000MC_MODULE are defined, the code must be there, because, if this code is built as both a module and builtin, only the builtin will be created. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
