Re: kbuild problem
> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild problem
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild problem
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild problem
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild problem
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kbuild problem
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kbuild problem
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kbuild problem
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kbuild problem
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: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
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.0 +0100 > +++ u/drivers/isdn/gigaset/Makefile 2007-02-20 13:38:58.0 +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: >textdata bss dec hex filename >4200 0 042001068 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kbuild problem
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: >textdata bss dec hex filename >4200 0 042001068 asyncdata.o > which appears tolerable. Ugly. But I've seen worse. Bye, Joerg signature.asc Description: Digital signature
Re: Kbuild problem
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.0 +0100 +++ u/drivers/isdn/gigaset/Makefile 2007-02-20 13:38:58.0 +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: textdata bss dec hex filename 4200 0 042001068 asyncdata.o which appears tolerable. Opinions? -- Tilman SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: Kbuild problem
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.0 +0100 +++ u/drivers/isdn/gigaset/Makefile 2007-02-20 13:38:58.0 +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: textdata bss dec hex filename 4200 0 042001068 asyncdata.o which appears tolerable. Opinions? -- Tilman SchmidtE-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: Kbuild problem
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: textdata bss dec hex filename 4200 0 042001068 asyncdata.o which appears tolerable. Ugly. But I've seen worse. Bye, Joerg signature.asc Description: Digital signature
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.0 +0100 +++ u/drivers/isdn/gigaset/Makefile 2007-02-20 13:38:58.0 +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: textdata bss dec hex filename 4200 0 042001068 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kbuild problem
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: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: Kbuild problem
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kbuild problem
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kbuild problem
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kbuild problem
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: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: Kbuild problem (was: [2.6 patch] drivers/isdn/gigaset/: build asyncdata.o into the gigaset module)
On Sat, Feb 17, 2007 at 01:04:33AM +0100, Tilman Schmidt wrote: > Am 16.02.2007 09:33 schrieb Adrian Bunk: > >>> ... > >>> LD drivers/isdn/gigaset/built-in.o > >>> drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_send_skb': > >>> (.text+0xe50): multiple definition of `gigaset_m10x_send_skb' > >>> drivers/isdn/gigaset/usb_gigaset.o:(.text+0x0): first defined here > >>> drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_input': > >>> (.text+0x1121): multiple definition of `gigaset_m10x_input' > >>> drivers/isdn/gigaset/usb_gigaset.o:(.text+0x2d1): first defined here > >>> make[4]: *** [drivers/isdn/gigaset/built-in.o] Error 1 > > > CONFIG_ISDN_DRV_GIGASET=y > > CONFIG_GIGASET_BASE=y > > CONFIG_GIGASET_M105=y > > CONFIG_GIGASET_M101=y > > Ah, thanks, I can see what's happening now. When both the M101 and M105 > drivers are built into the kernel, asyncdata.o gets linked in twice, via > > usb_gigaset-y := usb-gigaset.o asyncdata.o > obj-$(CONFIG_GIGASET_M105) += usb_gigaset.o gigaset.o > > and > > ser_gigaset-y := ser-gigaset.o asyncdata.o > obj-$(CONFIG_GIGASET_M101) += ser_gigaset.o gigaset.o > > The assertion in Documentation/kbuild/makefiles.txt: > > The order of files in $(obj-y) is significant. Duplicates in > the lists are allowed: the first instance will be linked into > built-in.o and succeeding instances will be ignored. > > doesn't work out in this case because asyncdata.o isn't added directly > to $(obj-y), but as part of usb_gigaset.o and ser_gigaset.o. > > I'm not quite happy with your solution, though. 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. Shared functionality simply doesn't belong into any of the affected modules, but to a different place where all users can access it. > Thanks, > Tilman 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kbuild problem (was: [2.6 patch] drivers/isdn/gigaset/: build asyncdata.o into the gigaset module)
On Sat, Feb 17, 2007 at 01:04:33AM +0100, Tilman Schmidt wrote: Am 16.02.2007 09:33 schrieb Adrian Bunk: ... LD drivers/isdn/gigaset/built-in.o drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_send_skb': (.text+0xe50): multiple definition of `gigaset_m10x_send_skb' drivers/isdn/gigaset/usb_gigaset.o:(.text+0x0): first defined here drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_input': (.text+0x1121): multiple definition of `gigaset_m10x_input' drivers/isdn/gigaset/usb_gigaset.o:(.text+0x2d1): first defined here make[4]: *** [drivers/isdn/gigaset/built-in.o] Error 1 CONFIG_ISDN_DRV_GIGASET=y CONFIG_GIGASET_BASE=y CONFIG_GIGASET_M105=y CONFIG_GIGASET_M101=y Ah, thanks, I can see what's happening now. When both the M101 and M105 drivers are built into the kernel, asyncdata.o gets linked in twice, via usb_gigaset-y := usb-gigaset.o asyncdata.o obj-$(CONFIG_GIGASET_M105) += usb_gigaset.o gigaset.o and ser_gigaset-y := ser-gigaset.o asyncdata.o obj-$(CONFIG_GIGASET_M101) += ser_gigaset.o gigaset.o The assertion in Documentation/kbuild/makefiles.txt: The order of files in $(obj-y) is significant. Duplicates in the lists are allowed: the first instance will be linked into built-in.o and succeeding instances will be ignored. doesn't work out in this case because asyncdata.o isn't added directly to $(obj-y), but as part of usb_gigaset.o and ser_gigaset.o. I'm not quite happy with your solution, though. 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. Shared functionality simply doesn't belong into any of the affected modules, but to a different place where all users can access it. Thanks, Tilman 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kbuild problem
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: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Re: Kbuild problem
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kbuild problem (was: [2.6 patch] drivers/isdn/gigaset/: build asyncdata.o into the gigaset module)
Am 16.02.2007 09:33 schrieb Adrian Bunk: >>> ... >>> LD drivers/isdn/gigaset/built-in.o >>> drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_send_skb': >>> (.text+0xe50): multiple definition of `gigaset_m10x_send_skb' >>> drivers/isdn/gigaset/usb_gigaset.o:(.text+0x0): first defined here >>> drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_input': >>> (.text+0x1121): multiple definition of `gigaset_m10x_input' >>> drivers/isdn/gigaset/usb_gigaset.o:(.text+0x2d1): first defined here >>> make[4]: *** [drivers/isdn/gigaset/built-in.o] Error 1 > CONFIG_ISDN_DRV_GIGASET=y > CONFIG_GIGASET_BASE=y > CONFIG_GIGASET_M105=y > CONFIG_GIGASET_M101=y Ah, thanks, I can see what's happening now. When both the M101 and M105 drivers are built into the kernel, asyncdata.o gets linked in twice, via usb_gigaset-y := usb-gigaset.o asyncdata.o obj-$(CONFIG_GIGASET_M105) += usb_gigaset.o gigaset.o and ser_gigaset-y := ser-gigaset.o asyncdata.o obj-$(CONFIG_GIGASET_M101) += ser_gigaset.o gigaset.o The assertion in Documentation/kbuild/makefiles.txt: The order of files in $(obj-y) is significant. Duplicates in the lists are allowed: the first instance will be linked into built-in.o and succeeding instances will be ignored. doesn't work out in this case because asyncdata.o isn't added directly to $(obj-y), but as part of usb_gigaset.o and ser_gigaset.o. I'm not quite happy with your solution, though. 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? Thanks, Tilman -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
Kbuild problem (was: [2.6 patch] drivers/isdn/gigaset/: build asyncdata.o into the gigaset module)
Am 16.02.2007 09:33 schrieb Adrian Bunk: ... LD drivers/isdn/gigaset/built-in.o drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_send_skb': (.text+0xe50): multiple definition of `gigaset_m10x_send_skb' drivers/isdn/gigaset/usb_gigaset.o:(.text+0x0): first defined here drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_input': (.text+0x1121): multiple definition of `gigaset_m10x_input' drivers/isdn/gigaset/usb_gigaset.o:(.text+0x2d1): first defined here make[4]: *** [drivers/isdn/gigaset/built-in.o] Error 1 CONFIG_ISDN_DRV_GIGASET=y CONFIG_GIGASET_BASE=y CONFIG_GIGASET_M105=y CONFIG_GIGASET_M101=y Ah, thanks, I can see what's happening now. When both the M101 and M105 drivers are built into the kernel, asyncdata.o gets linked in twice, via usb_gigaset-y := usb-gigaset.o asyncdata.o obj-$(CONFIG_GIGASET_M105) += usb_gigaset.o gigaset.o and ser_gigaset-y := ser-gigaset.o asyncdata.o obj-$(CONFIG_GIGASET_M101) += ser_gigaset.o gigaset.o The assertion in Documentation/kbuild/makefiles.txt: The order of files in $(obj-y) is significant. Duplicates in the lists are allowed: the first instance will be linked into built-in.o and succeeding instances will be ignored. doesn't work out in this case because asyncdata.o isn't added directly to $(obj-y), but as part of usb_gigaset.o and ser_gigaset.o. I'm not quite happy with your solution, though. 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? Thanks, Tilman -- Tilman Schmidt E-Mail: [EMAIL PROTECTED] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite) signature.asc Description: OpenPGP digital signature
