Date:	Fri, 12 Nov 2010 22:54:26 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mauro Carvalho Chehab <mchehab@...radead.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Patrick Boettcher <pboettcher@...nellabs.com>,
	Linux Media Mailing List <linux-media@...r.kernel.org>,
	linux-kbuild <linux-kbuild@...r.kernel.org>,
	Michal Marek <mmarek@...e.cz>
Subject: Re: Failed build on randconfig for DVB_DIB modules

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists