linux-kernel - Re: Kbuild problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070220145943.GU13958@stusta.de>
Date:	Tue, 20 Feb 2007 15:59:43 +0100
From:	Adrian Bunk <bunk@...sta.de>
To:	Tilman Schmidt <tilman@...p.cc>
Cc:	Kai Germaschewski <kai.germaschewski@....edu>,
	Hansjoerg Lipp <hjlipp@....de>, kkeil@...e.de,
	isdn4linux@...tserv.isdn4linux.de, linux-kernel@...r.kernel.org
Subject: Re: Kbuild problem

On Tue, Feb 20, 2007 at 02:56:27PM +0100, Tilman Schmidt wrote:
> Adrian Bunk schrieb:
> > On Sun, Feb 18, 2007 at 12:22:10AM -0500, Kai Germaschewski wrote:
> >> On Sat, 17 Feb 2007, Tilman Schmidt wrote:
> >> 
> >> > asyncdata.o is only needed for M105 and M101, not for the base
> >> > driver. How do I express in Kbuild that asyncdata.o is to be added
> >> > to gigaset-y only if CONFIG_GIGASET_M105 and CONFIG_GIGASET_M101
> >> > are not both 'n'?
> >> 
> >> The way this is typically done is via Kconfig. Add a config option 
> >> ASYNCDATA (actually something more descriptive/specific would be better), 
> >> add a "select ASYNCDATA" to the config options for m101 and m105, and then 
> >> you can use CONFIG_ASYNCDATA to decide whether to add asyncdata.o in the 
> >> Makefile.
> > 
> > One disadvantage of this approach is that in a kernel with 
> > CONFIG_GIGASET_BASE=y, you can't later compile and load the usb_gigaset 
> > or ser_gigaset modules without rebooting since they require a change to 
> > the kernel image.
> 
> You've got a point there. So linking asyncdata.o into the modules that
> need it, as it is currently done, would perhaps be better after all?
> The original problem (asyncdata.o linked in twice, causing duplicate
> symbol definitions) could be fixed with this (admittedly somewhat
> awkward) change to the Makefile (build tested):
> 
> --- linux-2.6.20-mm1-work/drivers/isdn/gigaset/Makefile 2007-02-20 13:39:44.000000000 +0100
> +++ u/drivers/isdn/gigaset/Makefile     2007-02-20 13:38:58.000000000 +0100
> @@ -1,7 +1,10 @@
>  gigaset-y := common.o interface.o proc.o ev-layer.o i4l.o
>  usb_gigaset-y := usb-gigaset.o asyncdata.o
>  bas_gigaset-y := bas-gigaset.o isocdata.o
> -ser_gigaset-y := ser-gigaset.o asyncdata.o
> +ser_gigaset-y := ser-gigaset.o
> +ifneq ($(CONFIG_GIGASET_M101)$(CONFIG_GIGASET_M105),yy)
> +ser_gigaset-y += asyncdata.o
> +endif

What happens with CONFIG_GIGASET_M101=y, CONFIG_GIGASET_M105=m ?

>  obj-$(CONFIG_GIGASET_M105) += usb_gigaset.o gigaset.o
>  obj-$(CONFIG_GIGASET_BASE) += bas_gigaset.o gigaset.o
> 
> The alternative would be to always link asyncdata.o into the gigaset
> module whether it's needed or not. "size asyncdata.o" says:
>    text    data     bss     dec     hex filename
>    4200       0       0    4200    1068 asyncdata.o
> which appears tolerable.
> 
> Opinions?

I'm usually someone who likes to avoid including unneeded code in the 
kernel, but in this case I'd say KISS - and build it always into the 
gigaset module.

> Tilman Schmidt

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

-
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/