[kbuild-devel] Re: UML kbuild patch
[EMAIL PROTECTED] said: > The actual executable UML generates is called "linux" anyway, so its > Makefile can have its own rule (as for other archs the boot images) > which builds "linux" from "vmlinux" using gcc and the link script. - > I.e. the same way as UML used to do it earlier, anyway. I'd actually prefer the one-stage link. That takes better advantage of the infrastructure that you've put in place. Instead of making LDFLAGS_vmlinux available to the arch Makefile, can you make cmd_link_vmlinux available? Then I can just rewrite it. That looks like it has no impact on the global Makefile except for moving it above the include of the arch Makefile. Jeff --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] UML kbuild patch
The UML build needs a few kbuild changes in order to work with the latest stuff. Since kbuild now enforces the use of the linker script on the vmlinux build, UML can't use its old two-stage link, where vmlinux is a normal relocatable object file which is linked into the linux binary with the linker script So, in order to fold those into one stage and produce an ELF binary, I need the vmlinux "linker" to actually be gcc. This implies I need a "-Wl,-T,arch/$(ARCH)/vmlinux.lds.s" instead of the usual "-T arch/$(ARCH)/vmlinux.lds.s". This is done without breaking the other arches by changing the final link command to $(LD_vmlinux) which is defaulted to $(LD) if the arch doesn't define it. The "-Wl,..." is done similarly by using $(LDFLAGS_vmlinux_default) if the linker command is anything but gcc and $(LDFLAGS_vmlinux_gcc) if it is gcc. The one caveat is that I removed $(LDFLAGS) from the link line - you might want to add it back. You can pull bk://jdike.stearns.org/kbuild-2.5. The patch is also appended. Jeff # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet1.600 -> 1.602 # Makefile1.305 -> 1.307 # # The following is the BitKeeper ChangeSet Log # # 02/09/23 [EMAIL PROTECTED]1.601 # Fixes to allow UML to build with the new vmlinux rules. # # 02/09/23 [EMAIL PROTECTED]1.602 # Made the UML Makefile changes work for the other arches. # # diff -Nru a/Makefile b/Makefile --- a/Makefile Mon Sep 23 19:50:33 2002 +++ b/Makefile Mon Sep 23 19:50:33 2002 @@ -288,10 +288,12 @@ # we cannot yet know if we will need to relink vmlinux. # So we descend into init/ inside the rule for vmlinux again. +LD_vmlinux := $(if $(LD_vmlinux),$(LD_vmlinux),$(LD)) + vmlinux-objs := $(HEAD) $(INIT) $(CORE_FILES) $(LIBS) $(DRIVERS) $(NETWORKS) quiet_cmd_link_vmlinux = LD $@ -cmd_link_vmlinux = $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $(HEAD) $(INIT) \ +cmd_link_vmlinux = $(LD_vmlinux) $(LDFLAGS_$(@F)) $(HEAD) $(INIT) \ --start-group \ $(CORE_FILES) \ $(LIBS) \ @@ -313,7 +315,11 @@ $(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map endef -LDFLAGS_vmlinux += -T arch/$(ARCH)/vmlinux.lds.s +LDFLAGS_vmlinux_default = -T arch/$(ARCH)/vmlinux.lds.s +LDFLAGS_vmlinux_gcc = -Wl,-T,arch/$(ARCH)/vmlinux.lds.s + +vmlinux_base = $(basename $(notdir $(LD_vmlinux))) +LDFLAGS_vmlinux += $(if +$(LDFLAGS_vmlinux_$(vmlinux_base)),$(LDFLAGS_vmlinux_$(vmlinux_base)),$(LDFLAGS_vmlinux_default)) vmlinux: $(vmlinux-objs) arch/$(ARCH)/vmlinux.lds.s FORCE $(call if_changed_rule,link_vmlinux) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: UML kbuild patch
On Mon, 23 Sep 2002, Jeff Dike wrote: > The UML build needs a few kbuild changes in order to work with the latest > stuff. > > Since kbuild now enforces the use of the linker script on the vmlinux build, > UML can't use its old two-stage link, where > vmlinux is a normal relocatable object file > which is linked into the linux binary with the linker script > > So, in order to fold those into one stage and produce an ELF binary, I need > the vmlinux "linker" to actually be gcc. This implies I need a > "-Wl,-T,arch/$(ARCH)/vmlinux.lds.s" instead of the usual > "-T arch/$(ARCH)/vmlinux.lds.s". > > This is done without breaking the other arches by changing the final link > command to $(LD_vmlinux) which is defaulted to $(LD) if the arch doesn't > define it. > > The "-Wl,..." is done similarly by using $(LDFLAGS_vmlinux_default) if > the linker command is anything but gcc and $(LDFLAGS_vmlinux_gcc) if it is > gcc. I just thought of another solution, which actually seems cleaner and has less impact on the top-level (generic) Makefile. Let's just do the LDFLAGS_vmlinux := -T arch/$(ARCH)/vmlinux.lds.s before including arch/$(ARCH)/Makefile. Normal archs can then just do LDFLAGS_vmlinux += -extra_option while UML does LDFLAGS_vmlinux := -r The actual executable UML generates is called "linux" anyway, so its Makefile can have its own rule (as for other archs the boot images) which builds "linux" from "vmlinux" using gcc and the link script. - I.e. the same way as UML used to do it earlier, anyway. The only impact on generic code is basically s/LDFLAGS_vmlinux :=/LDFLAGS_vmlinux +=/ in arch/*/Makefile, and it makes the UML "linux" build conceptually similar to other archs' "bzImage" or whatever targets. What do you think? --Kai --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] scripts/Configure and 'int'
On Tue, Sep 24, 2002 at 10:04:41AM +1000, Greg Banks wrote: > [...catching up on last few week's email...] > > Tom Rini wrote: > > > > Hello. Cufrrently in both 2.4 ad 2.5, scripts/Configure implements > > optional min/max arguments for the 'int' keyword. > > There are two problems however, first being that the spec, as defined in > > Documentation/kbuild/config-language.txt states that the int verb does > > not take range parameters, so this is out of spec. > > Secondly, if one specifies a default value higher than 1000 (or > > lower than -1000) oldconfig/config become horribly unhappy, unless > > the invalid range parameters are included. > > > > So, would anyone object to patches to fix this behavior and any Config > > entries which use it? Thanks. > > I don't think any entries use it, they would turn up as parse errors in gcml2. Ah, that's good to hear. > I think the best way to fix the behaviour is to remove it from Configure > entirely, so that Configure matches the spec. So do I. I'll have patches up shortly. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] scripts/Configure and 'int'
[...catching up on last few week's email...] Tom Rini wrote: > > Hello. Cufrrently in both 2.4 ad 2.5, scripts/Configure implements > optional min/max arguments for the 'int' keyword. > There are two problems however, first being that the spec, as defined in > Documentation/kbuild/config-language.txt states that the int verb does > not take range parameters, so this is out of spec. > Secondly, if one specifies a default value higher than 1000 (or > lower than -1000) oldconfig/config become horribly unhappy, unless > the invalid range parameters are included. > > So, would anyone object to patches to fix this behavior and any Config > entries which use it? Thanks. I don't think any entries use it, they would turn up as parse errors in gcml2. I think the best way to fix the behaviour is to remove it from Configure entirely, so that Configure matches the spec. Another approach would be to add a "int"-like and "hex"-like statements which allowed multiple ranges of values to be specified, as in CML2. This would cater for things like if [ "$CONFIG_SOUND_MSNDCLAS" = "y" ]; then int ' MSND Classic IRQ 5, 7, 9, 10, 11, 12' CONFIG_MSNDCLAS_IRQ 5 hex ' MSND Classic memory B, C8000, D, D8000, E, E8000' CONFIG_MSNDCLAS_MEM D hex ' MSND Classic I/O 210, 220, 230, 240, 250, 260, 290, 3E0' CONFIG_MSNDCLAS_IO 290 fi But that's probably not worth doing with Roman's lkc here. Greg. -- the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] linux kernel conf 0.6
On Mon, 23 Sep 2002, Roman Zippel wrote: > > I intentionally only printed a message and errored out in this case, and I > > think that's more useful, particularly for people doing > > > > make all 2>&1 > make.log > > > > which now may take forever waiting for input. > > You should have tried this first :) : Yup, obviously ;) Sorry about that. > > $ make | cat > make[1]: Entering directory `/home/roman/src/linux-lkc/scripts' > make[1]: Leaving directory `/home/roman/src/linux-lkc/scripts' > make[1]: Entering directory `/home/roman/src/lc' > make[1]: `conf' is up to date. > make[1]: Leaving directory `/home/roman/src/lc' > ./scripts/lkc/conf -s arch/i386/config.new > # > # using defaults found in .config > # > * > * Restart config... > * > Enable loadable module support (MODULES) [Y/n/?] y > Set version information on all module symbols (MODVERSIONS) [N/y/?] (NEW) aborted! > > Console input/output is redirected. Run 'make oldconfig' to update configuration. > > make: *** [include/linux/autoconf.h] Error 1 I'm still not happy at least for the ".config does not exist" case. Since when I forget to "cp ../config-2.5 .config", I don't really want "make oldconfig", I want to do the forgotten cp. I think there's hardly anyone who wants oldconfig in that case, rather menuconfig/xconfig or a cp like I mentioned. Since kbuild/lkc does not know, it shouldn't make that (bad) guess. If .config exist but is not current, I think in 99% of the cases we really want make oldconfig, so that's fine. --Kai --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] linux kernel conf 0.6
On Sun, Sep 22, 2002 at 05:36:25PM -0500, Kai Germaschewski wrote: > > > scripts/lkc/Makefile* > > > - As kbuild does not distingush between individual objects, > > > used for a given target, but (try to) build them all, I have > > > found a solution where I create one Makefile for each executable. > > > I could not see a clean way to integrate this in kbuild, and finally > > > decided that in this special case a number of Makefiles did not > > > hurt too much. > > > > Here I thought about using "ifeq ($(MAKECMDGOALS),...)" to keep them in a > > single file. Did you try something like this? > > That's now handled without obvious hacks. Applying $(sort ) to create a unique list of obj files does not solve this issue, only hide it. kbuild will compile all .o files originating from .c files when building conf and mconf. Likewise when building qconf, all .o files originating from both .c _and_ .cc files will be built. In other words the current solution leverage on the fact that the only problematic object files is qconf.o based on qconf.cc. It is OK that the first "make oldconfig" - automatic or not - needs to compile one extra .o file (mconf.o), since this is relatively fast. PS. linux-isdn.bkbits.net/linux-2.5.kconfig has not showed up yet - mentioned the patch you posted a diff for. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
