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. 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. Cheers, Mauro. -- 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
