kbuild problem

kbuild problem

[Randy Dunlap]

Hi Sam,

I have daily/nightly builds + test runs that use something like:
(but more complicated than this)

cp saved.config.file arch/$ARCH/config.default
EXPORT KBUILD_DEFCONFIG=config.default
make defconfig


This stopped working in 2.6.24-rc1-git3.  git2 worked as (I) expected.

Is there anything in the Makefile changes around that time
that could have caused this?

Note: the make defconfig output has changed from

Default configuration is based on config.default

to

*** Default configuration is based on 'x86_64_defconfig'


If not, I'll dig deeper into my script files.

Thanks,
---
~Randy

Re: kbuild problem

[Sam Ravnborg]

On Wed, Oct 31, 2007 at 06:39:00PM -0700, Randy Dunlap wrote:
> Hi Sam,
> 
> I have daily/nightly builds + test runs that use something like:
> (but more complicated than this)
> 
> cp saved.config.file arch/$ARCH/config.default
> EXPORT KBUILD_DEFCONFIG=config.default
> make defconfig

KBUILD_DEFCONFIG is supposed to point out a file located in
arch/$(ARCH)/configs.
I assume you copy the file to that directory.

Browsing the changes to scripts/kconfig/Makefile
nothing says 'this is the bug' but I suggest you to look there
first of all. 
I do not have -git2 and -git3 handy to do a diff between.


	Sam

Re: kbuild problem

[Randy Dunlap]

On Thu, 1 Nov 2007 06:21:45 +0100 Sam Ravnborg wrote:

> On Wed, Oct 31, 2007 at 06:39:00PM -0700, Randy Dunlap wrote:
> > Hi Sam,
> > 
> > I have daily/nightly builds + test runs that use something like:
> > (but more complicated than this)
> > 
> > cp saved.config.file arch/$ARCH/config.default
> > EXPORT KBUILD_DEFCONFIG=config.default
> > make defconfig
> 
> KBUILD_DEFCONFIG is supposed to point out a file located in
> arch/$(ARCH)/configs.
> I assume you copy the file to that directory.

Oops, yes, the command that I entered above was missing the
/configs/ part, but it is there.

> Browsing the changes to scripts/kconfig/Makefile
> nothing says 'this is the bug' but I suggest you to look there
> first of all. 
> I do not have -git2 and -git3 handy to do a diff between.

I think I found it -- in my scripts.  :)
They still think that $ARCH is i386 or x86_64, not "x86".
I'm testing a fix for that now.

Thanks,
---
~Randy

Re: kbuild problem

[Sam Ravnborg]

> 
> I think I found it -- in my scripts.  :)
> They still think that $ARCH is i386 or x86_64, not "x86".
> I'm testing a fix for that now.

Good - thanks for reporting back.

	Sam

Re: Kbuild problem

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

Am 20.02.2007 15:59 schrieb Adrian Bunk:
> 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.

There seems to be a clear majority for this solution. So KISS it
will be. Thanks for all the advice. I'll do a new patch.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: Kbuild problem

[Adrian Bunk]

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

Re: Kbuild problem

[Joerg Dorchain]

[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]

On Tue, Feb 20, 2007 at 02:56:27PM +0100, Tilman Schmidt wrote:
> > 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?

From the architectural point of view, what odds against making it a
module of its own? Dependancies are resolved by modprobe, so users should
be fine.
There are other library-like parts in the kernel where an object is
built statically when at least one needing driver is static, a module
when all nedding drivers are modules, or not at all but appears are a
config option when no in-kernel driver needs it.

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

Ugly. But I've seen worse.

Bye,

Joerg

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Kbuild problem

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

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

 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?

-- 
Tilman Schmidt                    E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: Kbuild problem

[Adrian Bunk]

On Sun, Feb 18, 2007 at 12:22:10AM -0500, Kai Germaschewski wrote:
> On Sat, 17 Feb 2007, Tilman Schmidt wrote:
> 
> > Alright, then so be it. But that raises another question:
> > 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.

> --Kai

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

Re: Kbuild problem

[Kai Germaschewski]

On Sat, 17 Feb 2007, Tilman Schmidt wrote:

> Alright, then so be it. But that raises another question:
> 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.

--Kai

Re: Kbuild problem

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

Am 17.02.2007 11:52 schrieb Adrian Bunk:
> On Sat, Feb 17, 2007 at 01:04:33AM +0100, Tilman Schmidt wrote:
>> [...] I'd prefer a
>> Makefile which builds modular usb_gigaset.ko and/or ser_gigaset.ko
>> like the present one (including asyncdata.o), but when linking
>> usb-gigaset.o and ser-gigaset.o into the kernel includes asyncdata.o
>> only once. Trouble is, I don't know how to express that in Kbuild.
>>
>> Any ideas?
> 
> CONFIG_GIGASET_M105=y, CONFIG_GIGASET_M101=m and similar problems might 
> make this quite tricky.

I am no judge of that. All I know about the possibilities of Kbuild
is what the files in Documentation/kbuild tell me. From browsing
through other kernel Makefiles it would appear that there are more
possibilities though, such as if/then/else constructs.

> Shared functionality simply doesn't belong into any of the affected 
> modules, but to a different place where all users can access it.

Alright, then so be it. But that raises another question:
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'?

Thanks,
Tilman

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]