[kbuild-devel] Re: 2.5 kbuild: use of '-z muldefs' for LD?
On Mon, 9 Jun 2003, Christoph Hellwig wrote: On Mon, Jun 09, 2003 at 01:56:59PM +0200, Jaroslav Kysela wrote: one object file for more targets. Example: -- snd-ice1712-objs := ice1712.o delta.o hoontech.o ews.o ak4xxx.o snd-ice1724-objs := ice1724.o amp.o revo.o aureon.o ak4xxx.o # Toplevel Module Dependency obj-$(CONFIG_SND_ICE1712) += snd-ice1712.o obj-$(CONFIG_SND_ICE1724) += snd-ice1724.o -- The ak4xxx.o module is shared and has defined a few public functions. Unfortunately, the default build-in.o rule fails when targets are requested to be included into the solid kernel because the public functions are duplicated in snd-ice1712.o and snd-ice17124.o. I can instruct the ld compiler to ignore the multiple definitions using '-z muldefs': EXTRA_LDFLAGS = -z muldefs But it seems like a hack for me. Does anybody have another idea to solve my problem? Move ak4xxx.o out of the multi-obj rules. Just declare a new helper- config option CONFIG_SND_AK4XXX that gets defined by all drivers using it and add obj-$(CONFIG_SND_AK4XXX) += ak4xxx.o I basically second this, though you don't even need a new config variable. snd-ice1712-objs := ice1712.o delta.o hoontech.o ews.o snd-ice1724-objs := ice1724.o amp.o revo.o aureon.o # Toplevel Module Dependency obj-$(CONFIG_SND_ICE1712) += snd-ice1712.o ak4xxx.o obj-$(CONFIG_SND_ICE1724) += snd-ice1724.o ak4xxx.o If you think the functions are too trivial to justify a module of their own, you may want to consider to put them as static inline into a header file, as someone else suggested. --Kai --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [RFC/CFT] Separate obj/src dir
On Tue, 19 Nov 2002, Larry McVoy wrote: On Tue, Nov 19, 2002 at 03:22:45PM -0500, Richard B. Johnson wrote: On Tue, 19 Nov 2002, Sam Ravnborg wrote: Based on some initial work by Kai Germaschewski I have made a working prototype of separate obj/src tree. Usage example: #src located in ~/bk/linux-2.5.sepobj mkdir ~/compile/v2.5 cd ~/compile/v2.5 sh ../../kb/v2.5/kbuild [SNIPPED...] I have a question; What problem is this supposed to solve? This looks like a M$ism to me. Real source trees don't look like this. If you don't have write access to the source- code tree, you are screwed on a real project anyway. That's why we have CVS, tar and other tools to provide a local copy. It can be really nice to maintain a bunch of different architectures at the same time from the same tree. It also makes it really easy to clean a tree. On the other hand, I do wonder whether ccache could be used to get the same effect. Sam? ccache helps a lot if you change your .config back to one previously compiled, but it still doesn't offer you the option to keep multiple .configs around at the same time. Also, of course it doesn't help with keeping the source tree clean of non-source files ;) Wrt the original patch, I like it, one preliminary comment is that I think symlinks are nicer than copying. They are faster, shouldn't cause any trouble on NFS, make uses stat and not lstat, so it gets the timestamps right, too. And if you edit a Makefile/Kconfig in the source tree, you rather want that to take effect immediately, I guess ;) --Kai --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH] Have split-include take another argument
On Mon, 11 Nov 2002, Tom Rini wrote: Hello. The following patch makes split-include take another argument, which is the prefix of what is being split up. This is needed since I'm working on a system which will allow for various params in the kernel to be tweaked at compile-time, without offering numerous CONFIG options (see http://marc.theaimsgroup.com/?l=linux-kernelm=103669658505842w=2). I'm sending this out for two reasons. First, does anyone see any problems with the patch itself? Second, Kai, would you be willing to apply this patch now, or would should I wait until the system is ready? Hmmh, I think I'd rather like to wait for the rest of the patch to see what its actual purpose is. If at all possible, I'd like to avoid introducing further hacks like this into kbuild, but that's more easily discussed when I can see what you're trying to achieve. --Kai --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [upatch] tweak for !KBUILD_VERBOSE output
On Sun, 3 Nov 2002, Peter Samuelson wrote: With !KBUILD_VERBOSE output, you can't tell whether a CC or LD line is for a module or for the kernel proper. Sure, most people probably don't care, but *I* do. Hence this patch. Output: CC vmlinux-object.o CC [M] standalone-module.o CC (M) partial-module.o LD built-in.o LD [M] composite-object.o This looks generally looks okay to me, I don't like the subtle difference between stand-alone and partial module, though, probably nobody can remember that, anyway ;) And there is really no difference in the command line, so why print something different. The LD line also doesn't really depend on whether we're linking a module or not, so not sure about the [M] there. If anything, I'd suggest to have it there for a composite object which is linked to become a module, and not there for a composite object which is linked into the kernel / built-in.o. I think your patch does the latter, so my point is only about the CC (M)/[M]. Also, implementation-wise, it may be cleaner to handle things the same way '-DMODULE' gets added? Does that make sense? --Kai --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [upatch] tweak for !KBUILD_VERBOSE output
On Mon, 4 Nov 2002, Sam Ravnborg wrote: On Mon, Nov 04, 2002 at 02:21:11PM -0600, Kai Germaschewski wrote: On Mon, 4 Nov 2002, Peter Samuelson wrote: The idea was that [M] is printed whenever a new module is born. (M) means a module is in progress. What people will see is that sometimes (M) is used sometimes [M]. That will confuse most people, keep it simple. But on the other hand I like [M] on the LD command. This allows me to see that foo.o is a module, something that I could not see before. It breaks the philosofy that this is a subset of the verbose output, but why not improve it when there is a good reason. I completely agree, though it weakens my argument about consistency ;) Now we only need to convince Peter. --Kai --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Thu, 3 Oct 2002, Sam Ravnborg wrote: -obj-$(CONFIG_ACPI_INTERPRETER) := $(patsubst %.c,%.o,$(wildcard *.c)) +obj-y := dsfield.o dsmthdat.o dsopcode.o dswexec.o dswscope.o \ +dsmethod.o dsobject.o dsutils.o dswload.o dswstate.o Should that have been: obj-$(CONFIG_ACPI_INTERPRETER) := dsfield.o dsmthdat.o dsopcode.o... Looks wrong to me that you remove the CONFIG_ dependency. Same is true for the rest of this cset. No, that's fine. We only enter this subdirectory if CONFIG_ACPI_INTERPRETER is set, so we do not need to repeat the variable here. A lot of places rely on this behavior to persist, so why not use it? +ifdef list-multi +$(warning kbuild: list-multi ($(list-multi)) is obsolete in 2.5. Please fix!) +endif Since kbuild no longer support list-multi this should be $(error ) Well, since it will still work fine (throwing an additional warning later on), I think a warning is okay here. I should have made the O_TARGET one an error now, though, since that stopped working. Anyway, I'll make both of them an error in a little bit, so... SUBDIRS+= $(patsubst %/,%,$(filter %/, $(init-y) $(init-m))) I prefer first assignment to be := not += This is true for several places including several makefiles as well. Well, really mostly a matter of taste. Using += everywhere has the advantage that you can add another line before that line without changing out. Kinda the same thing as adding a comma after the last element of a struct / enum. -export CPPFLAGS EXPORT_FLAGS NOSTDINC_FLAGS OBJCOPYFLAGS +export CPPFLAGS EXPORT_FLAGS NOSTDINC_FLAGS OBJCOPYFLAGS LDFLAGS Did not see this change justified. The export LDFLAGS just moved to a place where it's more logical. -export NETWORKS DRIVERS LIBS HEAD LDFLAGS MAKEBOOT +$(warning $(SUBDIRS)) Warning shall be deleted Right. I overlooked it first, but it's deleted in a later cset. ifndef O_TARGET ifndef L_TARGET -O_TARGET := built-in.o +O_TARGET := $(obj)/built-in.o +endif endif This change result in ld being called for directories like: $(TOPDIR)/scripts $(TOPDIR)/scripts/lxdialog $(TOPDIR)/Documentation/DocBook If obj-y is empty then do not define O_TARGET? Well, it's rather that I used EXTRA_TARGETS in those subdirs now. You're right that the standard rules do not apply in those dirs, so I'll think of a way to fix it there. Not defining O_TARGET when obj-y is empty is not an option, we rely on that case working elsewhere. Another more general comment. There seem to no consistency in the variables used in the first section of the makefile. There is a mixture of lower and upper case variables: O_TARGET, host-progs etc. This is confusing. Well, the whole thing is moving away from capitalized letters (in particular in the per-subdir Makefiles), as it is moving from old-style to new-style. The only common variables which are capitalized are CFLAGS, CC and the like, and I think they'll stay since that's standard make. kbuild-specific variables should really be basically all lower-case by now, I can only think of L_TARGET as an exception. Furthermore the construct: obj-y := some.o dot.o .o module.o Seems illogical to me. What does obj-y mean to me?? mandatory-objs := some.o dot.o .o module.o No, I think once you've understood obj-$(CONFIG_FOO), the meaning of obj-y is perfectly clear. Giving multiple names to the samt thing is not good, next thing would be people wondering what the difference between obj-y and mandatory-objs is. first_rule: $(if $(KBUILD_BUILTIN),$(O_TARGET) $(L_TARGET) $(EXTRA_TARGETS)) \ Where comes the requirement that EXTRA_TARGETS needs to be buildin? Initially, it was for built-in targets in addition to the standard O_TARGET, like arch/i386/kernel/head.o. I've been abusing it for scripts/, and I shouldn't be doing that. -cmd_link_multi = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $($(basename $@)-objs),$^) +cmd_link_multi = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(addprefix $(obj)/,$($(subst $(obj)/,,$(@:.o=-objs,$^) Keep a variable without obj appended would make this readable I think. I agree that it is not particularly readable, but I'm limited to what make offers. What do you suggest? --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
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Thu, 3 Oct 2002, Sam Ravnborg wrote: On Thu, Oct 03, 2002 at 10:01:20PM +0200, Sam Ravnborg wrote: Now it's testing time.. [...] You must be missing some of the changes (My first push to bkbits was incomplete, since I did inadvertently edit Makefile without checking it out, I do that mistake all the time...). It's fixed in the current repo. --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
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On 3 Oct 2002, Xavier Bestel wrote: Could you do instead: include subdir/Makefile ? It's not quite that easy, unfortunately ;( This would avoid recursive make, which isn't really a good idea (even if it's used widely). Here is a good agument about that: http://www.cse.iitb.ac.in/~soumen/teach/cs699a1999/make.html I think I heard that before, but I would argue that recursive builds if done right are just fine from the correctness point of view. --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] [PATCH] auto-include Rules.make
On Wed, 2 Oct 2002, Peter Samuelson wrote: Almost all kernel makefiles have to include $(TOPDIR)/Rules.make explicitly. 3/4 of the time, this is done at the end of the file. This patch lets you omit the include line in that case. (You still to include Rules.make explicitly if you have special make rules.) I've been thinking about doing something like this a couple of times. The reasons I didn't actually do it yet was that include $(TOPDIR)/Rules.make was kind of a separator between automatically handled stuff and additional hand-made rules for special cases. This distinction becomes a little more obvious with separate src/objdir or another patch I'm about to send, i.e. not really descending during the recursive make. If you pass what you want to be done in variables to Rules.make, you have a chance to manipulate this vars, e.g. adding proper src / obj paths. However, if you explicitly write a rule into a Makefile, Rules.make has no way to fix up paths or anything. That's why for the latter, you have to use $(src) / $(obj) explicitly, and to avoid confusion where these prefixes are necessary and where it's not, the split is kinda helpful, I think. Anyway, I think it's sth definitely worth considering, but if we do it, we should do so completely. AFAICS, there's two reasons why Rules.make is included in the middle. Of course it needs to be included after the obj-[ymn] and friends are set to do something sensible. It defines $(obj), $(src), so it needs to be included before those are used, and it currently relies on Rules.make's first_rule really being the first rule in a Makefile. Both the $(obj)/$(src) and the first_rule restriction could be lifted, making it possible to have Rules.make come last, AFAICS. So one could actually do make -f Rules.make obj=subdir src=subdir and Rules.make contains: include .config include $(src)/Makefile [rest of Rules.make follows here] Sounds worth trying? Anyway, I have still two other changes lined up, the do everything from the topdir one and Sam's make clean work. Once that is in (RSN, I hope), why not see if the above works out. As a positive side effect, we can now get rid of the $(MAKEFILES) kludge. (Hi Michael!) As a negative side effect, we prevent GNU make from being clever and recursing on 'make -n'. Well, I didn't find MAKEFILES a particularly bad hack, it's basically using MAKEFILES the way it's supposed to be used. I don't think the make -n thing hurts (I'm breaking that with my other changes, too). If anybody gives good reasons why we should keep it, it's just a matter of a little more typing to get it back to working, anyway. --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
[kbuild-devel] RfC: Don't cd into subdirs during kbuild
Hi, I'd appreciate to get comments on the appended patch. It's mostly cleanups and the like, but the interesting part is the last cset, which is actually fairly small: 14 files changed, 64 insertions(+), 47 deletions(-) The build process remains recursive, but it changes the recursion from make -C subdir to make -f subdir/Makefile i.e. the current working directory remains the top dir for all times. So gcc/ld/.. are now called from the topdir, allowing to closer resemble a non-recursive build. Some Makefiles may need a little additional tweaking (in particular arch/*), but generally, the changes required are pretty small. I'd appreciate comments and/or testing, if I hear no complaints, it'll go to Linus soon ;) --Kai Pull from http://linux-isdn.bkbits.net/linux-2.5.make (Merging changesets omitted for clarity) - [EMAIL PROTECTED], 2002-10-02 14:23:38-05:00, [EMAIL PROTECTED] kbuild: Small cleanups o Use a function descend for descending into subdirectories o Remove unused (?) boot target o Remove unnecessary intermediate sub_dirs target from Rules.make o Use /bin/true instead of echo -n to suppress spurious nothing to be done for ... output from make Makefile | 53 + Rules.make | 27 +++ 2 files changed, 40 insertions(+), 40 deletions(-) - [EMAIL PROTECTED], 2002-10-02 14:42:00-05:00, [EMAIL PROTECTED] kbuild: Remove xfs vpath hack xfs.o is built as one modules out of objects distributed into multiple subdirs. That is okay with the current kbuild, you just have to include the path for objects which reside in a subdir, then. xfs used vpath instead of explicitly adding the paths, which is inconsistent and conflicts e.g. with proper module version generation. Rules.make |3 +-- fs/xfs/Makefile | 27 +-- 2 files changed, 14 insertions(+), 16 deletions(-) - [EMAIL PROTECTED], 2002-10-02 14:46:16-05:00, [EMAIL PROTECTED] kbuild: Standardize ACPI Makefiles ACPI was a bit lazy and just said compile all .c files in this directory, which is different from all other Makefiles and will not work very well e.g. bk, where a .c file may not be checked out yet, or separate obj/src dirs. So just explicitly list the files we want to compile. dispatcher/Makefile |3 ++- events/Makefile |3 ++- executer/Makefile |5 - hardware/Makefile |2 +- namespace/Makefile |4 +++- parser/Makefile |3 ++- resources/Makefile |3 ++- tables/Makefile |3 ++- utilities/Makefile |3 ++- 9 files changed, 20 insertions(+), 9 deletions(-) - [EMAIL PROTECTED], 2002-10-02 14:54:37-05:00, [EMAIL PROTECTED] kbuild: Small quirks for separate obj / src trees Add a couple of missing $(obj) and the like. Also, remove the __chmod hack which made some files in the source tree executable - hopefully, everybody's copy is by now ;) drivers/isdn/hisax/Makefile |2 +- drivers/pci/Makefile|2 +- drivers/zorro/Makefile |2 +- scripts/Makefile| 11 +++ scripts/lxdialog/Makefile |6 +- 5 files changed, 11 insertions(+), 12 deletions(-) - [EMAIL PROTECTED], 2002-10-02 14:59:28-05:00, [EMAIL PROTECTED] kbuild: Add some bug traps Makefiles which still use obsolete 2.4 constructs now give a warning. Rules.make | 29 +++-- 1 files changed, 19 insertions(+), 10 deletions(-) - [EMAIL PROTECTED], 2002-10-02 16:29:37-05:00, [EMAIL PROTECTED] kbuild: Handle $(core-y) the same way as $(init-y), $(drivers-y) etc $(CORE_FILES) did not quite follow the way the other vmlinux parts where handled, due to potential init order dependencies. However, it seems everybody is putting arch specific stuff in front, so we keep doing this and nothing should break ;) Makefile |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-)
[kbuild-devel] Re: UML kbuild patch
[Removed l-k Cc] On Mon, 23 Sep 2002, Jeff Dike wrote: [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. Well, I don't think messing with cmd_link_vmlinux yourself is a good idea, that basically means code duplication, which is bad ;) If you really want the one-stage link, let's do it the way you suggested. However, I still think doing vmlinux first and linux afterwards is conceptually more similar to the normal vmlinux - bzImage or whatever. For example, there's a pending patch (kksymoops/kallsyms) which replaces the vmlinux link with a two-stage process, it'd be nice if such changes can happen without interfering with arch/*/Makefile at all. So here's my current proposal, however I'm not entirely sure if that order of using the link script is okay or not, uml just segfaults here either way. Against your updates-2.5. --Kai = Makefile 1.308 vs edited = --- 1.308/Makefile Mon Sep 23 20:46:21 2002 +++ edited/Makefile Tue Sep 24 11:32:18 2002 @@ -288,12 +288,10 @@ # 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_vmlinux) $(LDFLAGS_$(@F)) $(HEAD) $(INIT) \ +cmd_link_vmlinux = $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $(HEAD) $(INIT) \ --start-group \ $(CORE_FILES) \ $(LIBS) \ @@ -315,11 +313,7 @@ $(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort System.map endef -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)) +LDFLAGS_vmlinux += -T arch/$(ARCH)/vmlinux.lds.s vmlinux: $(vmlinux-objs) arch/$(ARCH)/vmlinux.lds.s FORCE $(call if_changed_rule,link_vmlinux) = arch/um/Makefile 1.3 vs edited = --- 1.3/arch/um/MakefileMon Sep 23 20:51:25 2002 +++ edited/arch/um/Makefile Tue Sep 24 11:50:42 2002 @@ -32,8 +32,7 @@ core-y += $(ARCH_DIR)/kernel/ \ $(ARCH_DIR)/drivers/ \ - $(ARCH_DIR)/sys-$(SUBARCH)/ \ - $(ARCH_DIR)/os-$(OS)/ + $(ARCH_DIR)/sys-$(SUBARCH)/ libs-$(CONFIG_PT_PROXY)+= $(ARCH_DIR)/ptproxy/ @@ -48,8 +47,6 @@ -DSUBARCH=\$(SUBARCH)\ -D_LARGEFILE64_SOURCE -I$(ARCH_INCLUDE) \ -Derrno=kernel_errno -LDFLAGS += -r - LINK_WRAPS = -Wl,--wrap,malloc -Wl,--wrap,free -Wl,--wrap,calloc SIZE = (($(CONFIG_NEST_LEVEL) + $(CONFIG_KERNEL_HALF_GIGS)) * 0x2000) @@ -57,8 +54,7 @@ AFLAGS_vmlinux.lds.o = -U$(SUBARCH) -DSTART=$$(($(TOP_ADDR) - $(SIZE))) \ -DELF_ARCH=$(ELF_ARCH) -DELF_FORMAT=\$(ELF_FORMAT)\ -LD_vmlinux = $(CC) -LDFLAGS_vmlinux = $(LINK_PROFILE) $(LINK_WRAPS) -static $(ARCH_DIR)/main.o +LDFLAGS_vmlinux = -r $(LINK_PROFILE) -static $(ARCH_DIR)/main.o SYMLINK_HEADERS = include/asm-um/archparam.h include/asm-um/system.h \ include/asm-um/sigcontext.h include/asm-um/processor.h \ @@ -72,7 +68,7 @@ linux: scripts $(ARCH_SYMLINKS) $(GEN_HEADERS) $(SYS_HEADERS) \ $(ARCH_DIR)/main.o \ vmlinux - mv vmlinux linux + gcc -o $@ $(LINK_WRAPS) -lutil vmlinux USER_CFLAGS := $(patsubst -I%,,$(CFLAGS)) USER_CFLAGS := $(patsubst -Derrno=kernel_errno,,$(USER_CFLAGS)) = arch/um/Makefile-os-Linux 1.1 vs edited = --- 1.1/arch/um/Makefile-os-Linux Fri Sep 6 12:29:28 2002 +++ edited/arch/um/Makefile-os-LinuxTue Sep 24 11:44:02 2002 @@ -3,5 +3,4 @@ # Licensed under the GPL # -SUBDIRS += $(ARCH_DIR)/os-$(OS)/drivers -LIBS += $(ARCH_DIR)/os-$(OS)/drivers/drivers.o +core-y += $(ARCH_DIR)/os-$(OS)/ = arch/um/kernel/Makefile 1.2 vs edited = --- 1.2/arch/um/kernel/Makefile Sun Sep 22 18:40:07 2002 +++ edited/arch/um/kernel/Makefile Tue Sep 24 11:36:03 2002 @@ -10,7 +10,6 @@ umid.o user_util.o obj-$(CONFIG_BLK_DEV_INITRD) += initrd_kern.o initrd_user.o -endif #
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 21 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, 22 Sep 2002, Jeff Garzik wrote: One cosmetic thing I mentioned to Roman, Config.new needs to be changed to something better, like conf.in or build.conf or somesuch. I agree. (But I'm not particularly good at coming up with names ;) build.conf is maybe not too bad considering that there may be a day where it is extended to support driver.conf as well. One other thing I wanted to mention but forgot was that lkc now does a quiet make oldconfig when .config changed or does not exist, which is changed behavior. 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 21 make.log which now may take forever waiting for input. --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] RFC: kernel config: new dependency syntax
On Wed, 14 Aug 2002, Peter Samuelson wrote: I've reused the syntax for a dependency line (the tail end of a dep_bool / dep_mbool / dep_tristate), like so: if_dep idependency line/i ... endif Honestly, I do not like this. It's probably the best that can be done in shell, but I think it's ugly and not intuitive. * !CONFIG_FOO negates sense: !y==n, !n==y, !==y, !m==m. The last !m==m is due to Roman's observation that it is useful to exclude two things from both being Y while allowing them to both be M. * 'or' placed between dependencies functions as a logical OR, and takes very low precedence. This complements the implicit AND performed between every pair of dependencies. x or x - x, for any x n or m == m or n - m n or y == y or n - y m or y == y or m - y * A=B evaluates to either Y or N, depending on whether A is logically equivalent to B. It has higher precedence than the ! operator. Thus: CONFIG_FOO=m evaluates to 'y' if CONFIG_FOO is m, 'n' otherwise CONFIG_BAR=n evaluates to 'y' if CONFIG_BAR is n or empty, 'n' otherwise !CONFIG_BAZ=y evaluates to 'n' if CONFIG_BAZ is y, 'y' otherwise Hmmh, personally I don't like all these logical operations on tristates, since they are not intuitive (at least for me). They all make sense, and I know we have them in thep dep_* lines already, but I'm not sure we want to spread them further. When we get real tristates for $CONFIG_, every case can be tested for in one comparison (= 'y', = 'm', = 'n', != 'n' etc), and I think the result looks clearer than having to remember the subtleties of a tristate or. This syntax is fully backward-compatible. Examples of use: if_dep CONFIG_X86 or CONFIG_X86_64 or CONFIG_IA64 bool 'ACPI support' CONFIG_ACPI endif if_dep CONFIG_SOUND !CONFIG_SOUND_ALSA source sound/oss/Config.in endif I don't like this, and I think it is actually the kind of change which is hard to get past Linus, since it just looks ugly. I realize this limitation is largely caused by using shell as the interpreter, but in this case I'd prefer to drop using shell, I think we all agree that a using common parser later would be a good thing anyway, and that really does not need to be written in shell. Just my opinion, of course ;) --Kai --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
On Thu, 15 Aug 2002, Peter Samuelson wrote: The more I think about it, the more I think the default if_dep should do the m-restricting thing. That way: dep_bool FOO1 BAR BAZ dep_mbool FOO2 BAR BAZ dep_tristate FOO3 BAR BAZ is exactly equivalent to if_dep BAR BAZ bool FOO1 mbool FOO2 tristate FOO3 fi_dep Of course, that requires the invention of 'mbool'. But I do believe it covers most if not all common cases. I guess in this case, though, it's still an open question whether 'define_bool' should be immune from the M effect (like 'mbool') or not. Seeing it from that point of view, it may actually turn into something which can agree with much more easily. Maybe it actually suffices to declare if_dep, fi_dep as virtually adds the listed arguments to each statement in the enclosed region. Maybe there would be a better name for that, then if_dep, OTOH using if_dep makes it quite clear what else_dep does. Then, there would be some more steps, which could be easily done: Make every statement accepts dependencies (and depreciate the dep_ prefixes, since they become unnecessary). There really isn't any reason for the difference between bool and dep_bool right now, it only leads to confusion and mistakes. I didn't look into like choice statements, but I'd hope it's possible to add dependencies to them, too, for consistency. Extend the normal dep_* dependencies (now just called *) to accept the same kind of dep lines as if_dep, i.e. !, =[ymn], !=[ymn], 'or', 'and'. Also, when doing that conversion, I think it may be worthwhile to get rid of the distinction between mbool and bool by something like, changing dep_mbool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS $CONFIG_ISDN_CAPI_CAPI20 to bool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS' CONFIG_ISDN_CAPI!=n and dep_bool ' AVM A1 (Fritz)' CONFIG_HISAX_AVM_A1 $CONFIG_ISA to bool ' AVM A1 (Fritz)' CONFIG_HISAX_AVM_A1 CONFIG_ISA=y I think a sensible default would be m - y in this case (like mbool), which would allow to handle 95% of the cases with just bool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS' CONFIG_ISDN_CAPI bool ' AVM A1 (Fritz)' CONFIG_HISAX_AVM_A1 CONFIG_ISA (both cases are equivalent to the above, CONFIG_ISA is a bool) If the real old dep_bool is needed, it can be written as CONFIG_FOO=y, in most cases CONFIG_FOO!=n = CONFIG_FOO will be what's needed. I'd be interested to see if these statements are actually sufficient to express all we've got today. A nice side effect of the above definition of if_dep would be that bool '...' CONFIG_FOO if [ $CONFIG_FOO = y ]; then bool '...' CONFIG_BAR [...] else define_bool CONFIG_BAR n fi can turn into just bool '...' CONFIG_FOO if_dep CONFIG_FOO bool '...' CONFIG_BAR [...] fi_dep (The CONFIG_FOO=n case would still run through the statements included by if_dep / fi_dep, automatically setting all vars to 'n', since one of their deps is 'n') OTOH, one of the problems I can see already is that bool '...' CONFIG_FOO if [ $CONFIG_FOO = y ]; then bool '...' CONFIG_BAR [...] else define_bool CONFIG_BAR y fi doesn't translate well. (Hacks I can see would be: bool '...' CONFIG_FOO if_dep CONFIG_FOO bool 'not ...' CONFIG_NOT_BAR [...] fi_dep define_bool CONFIG_BAR !CONFIG_NOT_BAR or bool '...' CONFIG_FOO if_dep CONFIG_FOO bool '...' CONFIG_FOO_BAR [...] fi_dep define_bool CONFIG_BAR CONFIG_FOO_BAR or !CONFIG_FOO both not particularly nice, but if there's only like one or two cases like this in the current config.in's, it may be acceptable) Oh well, I think the only way to find out if all that is really a good idea is to try, convert some config.in's and look at the result. --Kai --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
On Thu, 15 Aug 2002, Roman Zippel wrote: I don't think anyone who actually understands the config system would argue these points, but we are limited by practical constraints to making incremental improvements only. That's fine with me, but nonetheless I'd really like to know where it will go to. Just fixing the easy problems is simple, but so far I haven't seen any plan on how to fix the hard problems. Anyone starting to fix all the problems should have at least some ideas how to do it and I'd really like to hear them. I don't want to discourage anyone, but he should understand the complete problem first before going for the easy targets. I think concentrating on the small gotchas for now is a good thing. Surely not all conceptual problems are fixable easily, they probably need to be done in conjunction with switching to a common parser etc. (Note: this switch to a new parser should happen with no change to the config.in format or semantics, in order to fit the Linux/Linus way of doing things). However, I think it is too late in 2.5 for these kind of big changes. That doesn't mean that fixing bugs, of which there are plenty, and small improvements like == n where possible shouldn't be done. If nothing else, it will at least give a better starting point for more elaborate work later. --Kai --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media
On Wed, 14 Aug 2002, Greg Banks wrote: @@ -330,6 +329,5 @@ 1 CONFIG_ZORRO -34 forward-dependancy +23 forward-dependancy 11 CONFIG_ISDN_CAPI 11 CONFIG_PROC_FS -11 CONFIG_SOUND_ACI_MIXER 1 CONFIG_BLK_DEV_SD Could you check that the appended patch solves the CONFIG_ISDN_CAPI problem (and doesn't introduce new ones)? --Kai = drivers/isdn/Config.in 1.18 vs edited = --- 1.18/drivers/isdn/Config.in Wed Apr 24 09:42:33 2002 +++ edited/drivers/isdn/Config.in Wed Aug 14 10:49:07 2002 @@ -22,8 +22,9 @@ tristate 'CAPI2.0 support' CONFIG_ISDN_CAPI if [ $CONFIG_ISDN_CAPI != n ]; then source drivers/isdn/capi/Config.in - source drivers/isdn/hardware/Config.in fi + + source drivers/isdn/hardware/Config.in fi fi endmenu = drivers/isdn/hardware/Config.in 1.1 vs edited = --- 1.1/drivers/isdn/hardware/Config.in Sun Apr 21 23:07:44 2002 +++ edited/drivers/isdn/hardware/Config.in Wed Aug 14 11:01:04 2002 @@ -2,4 +2,26 @@ # ISDN hardware drivers # -source drivers/isdn/hardware/avm/Config.in +if [ $CONFIG_ISDN_CAPI != n ]; then + comment 'CAPI hardware drivers' + source drivers/isdn/hardware/avm/Config.in +fi + +if [ $CONFIG_ISDN != n ]; then + comment 'ISDN4Linux hardware drivers' + + source drivers/isdn/hisax/Config.in + + mainmenu_option next_comment + comment 'Active cards' + + source drivers/isdn/icn/Config.in + source drivers/isdn/pcbit/Config.in + source drivers/isdn/sc/Config.in + source drivers/isdn/act2000/Config.in + source drivers/isdn/eicon/Config.in + source drivers/isdn/tpam/Config.in + source drivers/isdn/hysdn/Config.in + endmenu +fi + = drivers/isdn/hardware/avm/Config.in 1.3 vs edited = --- 1.3/drivers/isdn/hardware/avm/Config.in Tue Jun 18 14:00:47 2002 +++ edited/drivers/isdn/hardware/avm/Config.in Wed Aug 14 10:53:57 2002 @@ -3,7 +3,7 @@ # mainmenu_option next_comment -comment 'Drivers for active AVM cards' +comment 'Active AVM cards' bool 'Support AVM cards' CONFIG_CAPI_AVM = drivers/isdn/hisax/Config.in 1.9 vs edited = --- 1.9/drivers/isdn/hisax/Config.inTue Jul 30 07:15:09 2002 +++ edited/drivers/isdn/hisax/Config.in Wed Aug 14 11:01:20 2002 @@ -1,5 +1,5 @@ mainmenu_option next_comment -comment 'Passive ISDN cards' +comment 'Passive cards' dep_tristate 'HiSax SiemensChipSet driver support' CONFIG_ISDN_DRV_HISAX $CONFIG_ISDN if [ $CONFIG_ISDN_DRV_HISAX != n ]; then comment ' D-channel protocol features' = drivers/isdn/i4l/Config.in 1.3 vs edited = --- 1.3/drivers/isdn/i4l/Config.in Sun Apr 21 23:07:44 2002 +++ edited/drivers/isdn/i4l/Config.in Wed Aug 14 10:47:42 2002 @@ -24,22 +24,5 @@ dep_tristate 'Support isdn diversion services' CONFIG_ISDN_DIVERSION $CONFIG_ISDN endmenu -comment 'low-level hardware drivers' - -source drivers/isdn/hisax/Config.in - -### Active ISDN cards - -mainmenu_option next_comment -comment 'Active ISDN cards' - -source drivers/isdn/icn/Config.in -source drivers/isdn/pcbit/Config.in -source drivers/isdn/sc/Config.in -source drivers/isdn/act2000/Config.in -source drivers/isdn/eicon/Config.in -source drivers/isdn/tpam/Config.in -source drivers/isdn/hysdn/Config.in - endmenu --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
On Tue, 13 Aug 2002, Peter Samuelson wrote: CONFIG_PROC_FS is needed by ISDN hysdn. That's actually in my opinion more of a general kernel facility than a filesystem. Eh? Well, the use in hysdn can (and should) die, possibly by adding an #ifndef CONFIG_PROC_FS #error This driver won't work without procfs #endif until fixed properly. Then again it could be said that requiring CONFIG_PROC_FS is actually a design bug in hysdn - does the driver *really* need CONFIG_PROC_FS? Everything else in the kernel seems to cope without it. Granted, non-/proc kernels are not widely tested Kai? I don't know, I suspect it needs it for something like firmware loading or so. But since that's obviously an abuse of /proc, it's okay to have it break IMO. CONFIG_ISDN_CAPI - interestingly, CONFIG_HYSDN_CAPI, which is under the menu Old ISDN4Linux (obsolete) seems to require CAPI 2.0. I suppose the CAPI stuff should come first in drivers/isdn/Config.in. Kai? Yes. I'll look into that and fix it properly - I think just exchanging probably gives the same kind of problem for CONFIG_ISDN ;( --Kai --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] config language dep_* enhancements
On Tue, 13 Aug 2002, Greg Banks wrote: Kai Germaschewski wrote: But so the change would be a good thing, right? It would make the behavior consistent between all configuration tools, Sorry, I don't understand what you're getting at. Currently the behaviour is consistent between config, menuconfig and xconfig: null-valued deps are ignored. For some reason, I thought that menuconfig or xconfig were handling the case differently. Apparently not, sorry about that. CONFIG_BLK_DEV_IDESCSI would be not selectable in either. So people would have to notice that this statement is broken and fix it. Ah. If you're willing to knowingly feed Linus with patches that break current config behaviour, then OK we have a way to proceed. Well, it'd be nice to first fix the dep_* statements so that they don't break when that change is done (i.e. in this case, moving IDESCSI behind CONFIG_SCSI. So you agree a bit of spring cleaning wouldn't hurt, right? ;) Absolutely, and I have a catalogue of dust puppies to help that process ;-) Okay. Let me first state that I do not really have the time to get involved currently. ISDN4Linux and other pending kbuild stuff already takes somewhat more than the remaining free time I have. But if you guys want to get going with some step by step cleaning (w/o breaking too much), I can try to help reviewing and submitting to Linus. Well, you're right here. Which makes me think of my original idea as to define all CONFIG_* values to n unless they've explicitly been assign another value before. CML2's semantics were that all symbols have a default which is a zero; for booleans and tristates that means n. Changing from those semantics to the ones necessary to run the gcml2 rulebase on CML1 rules was one of the most painful parts of supporting CML1. So I think having an explicit n default is a good idea, but I fail to see how you would actually implement such a thing in a shell based parser. Basically, extend the source command to do a grep CONFIG_* in the file to be read and set all found symbols to n, if unset - only then do the actual source. The main usage currently is make oldconfig, though .config may be a bit confusing: Questions which have been answered before (even with n) will not be asked again, whereas for undefined symbols, the corresponding question is put. So I think the logic should really be tristate, n,m,y, plus additionally a list of CONFIG_* values which have been defined (as opposed to just being n by default). This is precisely the CML2 semantics. Of course, this is a 2.5 change, Agreed. though the only potential for breakage are the dep_* statements which are arguably already broken. I don't think there's any value to gratuitously breaking 2.4's config. That's the point of a stable series right? I agree. Anyway, some more points: o a) dep_bool ' Blah' CONFIG_FOO $CONFIG_BAR vs. b) dep_bool ' Blah' CONFIG_FOO CONFIG_BAR (the latter proposed by Peter Samuelson) I see the following: b) needs a large scale patch through all Config.in's. OTOH, it can be done step by step, only changing an instance after it has been looked at. a) means only a patch to Configure/menuconfig etc, but since it changes semantics, it'd be nice to check all possibly breaking usages (not too hard thanks to gcml2) I find a) more intuitive, for people who know sh, it's pretty clear when we use $ and when not. Also, for 'if' statements, we'll have to use the $ variant anyway for all I can see, so I prefer that from a consistency point of view. b) is better if you want to add features like automatic (EXPERIMENTAL) a) has the advantage of automatically getting rid of the ugly duplicated 'if' tests: (And I think it should allow for getting rid of the quotation marks, too) if [ $CONFIG_FOO = -o $CONFIG_FOO = n ] -- if [ $CONFIG_FOO == n ] if [ $CONFIG_FOO = y -o $CONFIG_FOO = m ] -- if [ $CONFIG_FOO != n ] o whatever we do, having a nice way to handle two exclusive drivers would be nice --Kai --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media
On Tue, 13 Aug 2002, Peter Samuelson wrote: Here's another one - this should fix the forward dependency between CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config into the Multimedia menu - where I think it belongs anyway. Hmmh, makes sense to me, but there will probably be people complaining sound config has disappeared for me ;) The big loser here is ARM - it no longer suppresses the sound card question for the appropriate boards. But it's just one question, so I didn't sweat it too much. Well, I think that's okay, but you should check back with _rmk_. What I like about that patch is that it actually removes duplicated code. I think that's exactly where this effort should start. For example, the SCSI patch didn't do this, though AFAICS it would be nicely possible to unconditionally source drivers/scsi/Config.in and then have the if in there. These are trivial changes, and they make it easier to see what's happening in the patches which actually change behavior. Taking that a step further, this should also be a nice opportunity to introduce drivers/Config.in and remove even more duplication from arch/$ARCH/config.in. It comes of the cost of testing for the architecture, since e.g. s390 does not want to include most of drivers/*, but that means we'd actually collect this knowledge at a centralized place. Introducing drivers/Config.in could be done nicely piecemeal as well, without any change in behavior which is always good. It would also provide a possibility to not lose the ARM knowledge. I think it's basically just a question of taste if you prefer to initial global subsystem question in drivers/Config.in or drivers/subsys/Config.in. drivers/isdn/Config.in starts with mainmenu_option next_comment comment 'ISDN subsystem' if [ $CONFIG_NET != n ]; then bool 'ISDN support' CONFIG_ISDN_BOOL if [ $CONFIG_ISDN_BOOL = y ]; then mainmenu_option next_comment since I did not like having that duplicated in each arch/*/config.in. It also makes sense in the have as much information as possible about a subsystem located in one place (drivers/subsys). By the way, if you do these kind of changes, also check Config.help, you may be able to remove duplicated entries there as well ;) The drawbacks of that solution as opposed to having the above in drivers/Config.in and ending with source drivers/isdn/Config.in are: o We need to source all the Config.in files even when the subsys gets disabled, since we cannot know that beforehand o The trivial patches moving statements like the above into the subsys/Config.in means that all of that file should be indented, which makes the patches look really large, even though they change very little. I have no strong opinion either way, but I'd certainly like a drivers/Config.in. Oh, what I don't like about your patches: You don't include them inline, so I cannot easily (R)eply to them and have them quoted ;) --Kai --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] config language dep_* enhancements
On Mon, 12 Aug 2002, Greg Banks wrote: I'm pleased to see that you have preserved those semantics. There are many places in the corpus where a dep_* lists as a dependency a variable which is not defined until later, or is only defined in some architectures, or is never defined. Earlier today I tweaked up gcml2 to detect them and found 260 in 2.5.29. You give me too much credit. The main motivation for dropping the '$' was to make possible the == n semantics. That the patch failed to do so was accident, not design. Ah, well that's more disturbing. Changing the existing semantics, regardless of how broken we all agree they are, is asking for a world of trouble. To pick an example, in 2.5.29 drivers/ide/Config.in:17 is dep_tristate 'SCSI emulation support' CONFIG_BLK_DEV_IDESCSI $CONFIG_ATAPI $CONFIG_BLK_DEV_IDE $CONFIG_SCSI But at this point in the menu tree for 14 of 17 architectures, CONFIG_SCSI has not yet been defined. The result is that CONFIG_BLK_DEV_IDESCSI only works in make config and make allyesconfig precisely because of the semantic that you wish to change. But so the change would be a good thing, right? It would make the behavior consistent between all configuration tools, CONFIG_BLK_DEV_IDESCSI would be not selectable in either. So people would have to notice that this statement is broken and fix it. I know the current behavior is documented, but I had thought this was because changing the behavior was not feasible due to our Bash-based JIT parsers. Yes, changing the behaviour is infeasible with shell-based parsers. However, there is now a body of rules which implictly depend on the semantics. If they do, they should be fixed. And, as I pointed out before, it is possible to fix even shell-based parsers. Can you provide a rationale for why the current behavior is desirable? I wouldn't call it desirable. I would use words like clunky, congealed, unorthogonal, riddled with errors, and very hard to fix like the rest of the config language. So you agree a bit of spring cleaning wouldn't hurt, right? ;) It seems to me that it only encourages buggy Config.in code (since == n in other contexts like the #defines), And != n in other contexts, like if [];then statements. Did I mention unorthogonal ? Well, you're right here. Which makes me think of my original idea as to define all CONFIG_* values to n unless they've explicitly been assign another value before. The problem is that logic in config language is implicitly four-state, with the null or empty value being a separate value distinct from y, m and n. The fact that both and n mean don't build this object to kbuild doesn't mean that and n are the same thing. This isn't really obvious. One example where there is a semantic difference between and n would be an autoconfigurator, where n would mean I have probed for this hardware and it is not present but means something like I have not probed. The main usage currently is make oldconfig, though .config may be a bit confusing: Questions which have been answered before (even with n) will not be asked again, whereas for undefined symbols, the corresponding question is put. So I think the logic should really be tristate, n,m,y, plus additionally a list of CONFIG_* values which have been defined (as opposed to just being n by default). This would get rid of the non-intuitive behavior of dep_* and allow simplifying all the if [ == n || == ] duplication. It's a bit cumbersome to implement in shell, but surely possible. Of course, this is a 2.5 change, though the only potential for breakage are the dep_* statements which are arguably already broken. It shouldn't be too hard to come up with a script which points out the dep_* statements which reference symbols defined only later (or use gcml2, which I understand can do that already?) to see how much breakage there may be. --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
[kbuild-devel] Re: [PATCH] kbuild: Remove 2048 symbol limit in tkparse
On Fri, 31 May 2002, Sam Ravnborg wrote: tkparse limit the number of symbols to 2048. This patch makes the array dynamic avoiding this problem in the future. The problem showed up in one of the powerpc tree's. Thanks, I'll look at this (and the other patches) and submit it to Linus (assuming I don't find anything wrong with it), if he didn't already merge it. --Kai ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: Announce: Kernel Build for 2.5, Release 2.4is available
On Sat, 4 May 2002, Keith Owens wrote: An update to 2.5/Documentation/Changes has been submitted. Linus has already done 2.5 changes that require make 3.79 features, the Changes update is overdue. Trying to get back to technical issues, which change do you refer to? (Note that I don't object to this requirement at all) --Kai ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
On Fri, 28 Dec 2001, Linus Torvalds wrote: On Fri, 28 Dec 2001, Legacy Fishtank wrote: I think one thing to note is that dependencies is that if you are smart about it, dependencies -really- do not even change when your .config changes. Absolutely. I detest gcc -MD, exactly because it doesn't get this part right. mkdep.c gets this _right_. Well, -MD gets this right. The dependencies it generates will cause a recompile when necessary. Unfortunately, though, it's too good, because the dependency on include/linux/autoconf.h will cause lots of unnecessary recompiles. But yes, it seems possible to replace the -MD dependency file, which depends on a specific config, with a generic dependency file, which knows about our #ifdef CONFIG_XXX and translates them to the corresponding ifeq(CONFIG_,) Makefile syntax. It'd make an interesting project, but it effectively means re-implementing a C preprocessor. I don't think you can blame gcc -MD for not knowing about the kernel's CONFIG_ system, though ;-) From --- #ifdef CONFIG_XXX #include linux/xxx.h #endif #ifdef CONFIG_YYY const int nr = 10; #else const int nr = 100; #endif --- you'd have to generate --- ifeq(CONFIG_XXX,y) DEPS += include/linux/xxx.h endif DEPS += include/config/yyy --- i.e. the include/config trick has to stay any way. I don't think the above is necessary, though, the following does work pretty good (I did it this way, inspired by mec, and I think kbuild-2.5 does it similarly): Generate dependencies for a .o file when compiling it. [ Doing make dep in advance is unnessary. Actually, it's pretty stupid to generate dependencies for *all* possible object files which you are never going to compile (think arch/*). If you don't have the object yet, you don't need to know the dependencies, dependencies only make sense for recompiles. It's also cheaper to generate dependencies during the compile, as you need to read the file anyway. Also, dependencies on generated files cannot be found correctly until these files have been generated. ] The generated dependencies will always include linux/autoconf.h, which is correct, but will cause too many recompiles. So, replace linux/autoconf.h with linux/config/xxx, where xxx are all the config options which appear in all of the files used to build the object file (which is what -MD gave you). The result is still dependencies which are 100% correct. It's that simple. The object file gcc generates depends on the command line and all the files it reads during the compile. Why make it more complex? --Kai ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Handling boolean subsets of objects
On Mon, 29 Oct 2001, Keith Owens wrote:
Several Makefile.in files have code like this
ifsel(CONFIG_ISDN_PPP)
select(CONFIG_ISDN slhc.o)
endif
How about handling this in the configuration language? I don't know CML2
yet, but I believe it should be easy enough to handle these things there.
Basically, define CONFIG_SLHC to y/m depending on CONFIG_ISDN_{,PPP},
CONFIG_PPP, CONFIG_SLIP.
This would also increase chances to get e.g. the PPP modular, ISDN
built-in case correct. Well, maybe it already is, we filter out obj-y
from obj-m, right?
--Kai
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Need help with module dependency problem (long,probably tedious)
On Thu, 14 Jun 2001, Brad Hards wrote: So far so good. The problem comes from introducing the new EHCI, and associated refactoring of the common host controller code. The new approach is that host controllers will live in a subdirectory (drivers/usb/hcd), and we will eventually link in the common host controller support infrastructure as part of usbcore.o, if we are using any of the new style hcd support. [... Makefiles removed] This works fine as long as (CONFIG_USB=y and CONFIG_EHCI_HCD=y) or (CONFIG_USB=m and CONFIG_EHCI_HCD=m), just ignoring CONFIG_OHCI_HCD for now, although you can s/EHCI/OHCI in that logic. It doesn't work if CONFIG_USB is built in, and you want modular host controller drivers (which is typically the case). Specifically, when I modprobe ehci-hcd, I get five unresolved references. When I do a strings hcd.o, I see the following: __VERSIONED_SYMBOL(usb_hcd_pci_probe) __VERSIONED_SYMBOL(usb_hcd_pci_remove) __VERSIONED_SYMBOL(usb_hcd_pci_suspend) __VERSIONED_SYMBOL(usb_hcd_pci_resume) __VERSIONED_SYMBOL(usb_hcd_giveback_urb) There's two possible explanations for this: module versioning dependencies are broken, the only reliable way to fix this is to make mrproper and rebuild. The other one is the objects which are exporting symbols are not listed appropriately in export-objs. I think you've got the second problem. You get the list for export-objs by grep EXPORT_SYMBOL *.c and replacing .c - .o. However, your Makefiles are broken and handling things differently from the rest of the kernel, which is not good (and may cause all sorts of problems). I'm appending a patch agains current sf CVS (usb and hcd), which gets things more in line with how it's done usually. The following is untested though, because I didn't get the CVS version to compile for other reasons (supposedly the fact that I didn't update include/linux/usb*). [Patch to usb CVS] Index: Config.in === RCS file: /cvsroot/linux-usb/usb/Config.in,v retrieving revision 1.23 diff -u -r1.23 Config.in --- Config.in 2001/06/07 06:30:03 1.23 +++ Config.in 2001/06/14 20:57:27 @@ -24,6 +24,9 @@ dep_tristate ' UHCI Alternate Driver (JE) support' CONFIG_USB_UHCI_ALT $CONFIG_USB fi dep_tristate ' OHCI (Compaq, iMacs, OPTi, SiS, ALi, ...) support' CONFIG_USB_OHCI $CONFIG_USB + dep_tristate ' EHCI HCD (USB 2.0) support (EXPERIMENTAL)' CONFIG_EHCI_HCD +$CONFIG_USB $CONFIG_EXPERIMENTAL + dep_tristate ' OHCI HCD support (EXPERIMENTAL)' CONFIG_OHCI_HCD $CONFIG_USB +$CONFIG_EXPERIMENTAL + dep_tristate ' UHCI HCD support (EXPERIMENTAL)' CONFIG_UHCI_HCD $CONFIG_USB +$CONFIG_EXPERIMENTAL comment 'USB Device Class drivers' dep_tristate ' USB Audio support' CONFIG_USB_AUDIO $CONFIG_USB $CONFIG_SOUND I removed the CONFIG_USB_HCD thing, we now always enter drivers/usb/hcd. (It's not a problem even if we didn't select any host controller, it only has a tiny performance penalty in this case. I suppose it doesn't really much sense to compile USB without host controller support, anyway) Index: Makefile === RCS file: /cvsroot/linux-usb/usb/Makefile,v retrieving revision 1.16 diff -u -r1.16 Makefile --- Makefile2001/01/04 08:41:24 1.16 +++ Makefile2001/06/14 20:57:27 @@ -2,33 +2,25 @@ # Makefile for the kernel USB device drivers. # -# Subdirs. - # The target object and module list name. O_TARGET := usbdrv.o +# Subdirs. + +mod-subdirs:= hcd +subdir-y := hcd + # Objects that export symbols. export-objs:= usb.o # Multipart objects. - -list-multi := usbcore.o -usbcore-objs := usb.o usb-debug.o hub.o - -# Optional parts of multipart objects. - -ifeq ($(CONFIG_USB_DEVICEFS),y) - usbcore-objs+= devio.o inode.o drivers.o devices.o -endif - -# Object file lists. -obj-y := -obj-m := -obj-n := -obj- := +list-multi := usbcore.o +usbcore-objs := usb.o usb-debug.o hub.o +usbcore-objs-$(CONFIG_USB_DEVICEFS)+= devio.o inode.o drivers.o devices.o +usbcore-objs += $(usbcore-objs-y) # Each configuration option enables a list of files. @@ -65,13 +57,7 @@ subdir-$(CONFIG_USB_SERIAL)+= serial subdir-$(CONFIG_USB_STORAGE) += storage -ifeq ($(CONFIG_USB_SERIAL),y) - obj-y += serial/usb-serial.o -endif - -ifeq ($(CONFIG_USB_STORAGE),y) - obj-y += storage/storage.o -endif +obj-y += $(addsuffix /vmlinux-obj.o, $(subdir-y)) include $(TOPDIR)/Rules.make Explanation: subdir-y := hcd means we enter hcd unconditionally. As hcd is also listed in mod-subdirs, we also enter it when making modules, too. This is not optimal performance-wise, but usually done this way since it's simple. The usbcore stuff is only rewritten a bit. I suppose that one's a question of taste.
Re: [kbuild-devel] Auto detection of changed commands/flags
On Tue, 29 May 2001, Keith Owens wrote: While your rules are good, they only handle the common case of compiling a kernel source to a kernel object. That is not really a problem, there are several solutions for the common case. I am looking at the unusual cases that require explicit user commands. Most are $(HOSTCC) commands but some run special scripts, there is no kbuild support for automatic rebuild in these cases. Yes, I know, and you're right. But my point was that a program like your preprocessor can convert such rules into safe variants automatically. It's much like what your plan seems to be, i.e. having the user input his rule and than enhance it. It's only that I think when you convert into a rule like the above, you can actually still use most of the Makefile's features, i.e. automatic variables like $@ $? $^ etc still just work. Well, again, not quite, as I said, because you have to filter-out FORCE, but it's still way easier then having your preparser substituting all this at Makefile generation time. It also makes it possible to have pattern rules like this, where substituting at generation time just doesn't work. But yes, you're right, what I quoted above is nothing like a complete solution, to work for the cases you mentioned you still need a specialized tool. It's just that I think writing this tools is easier the way I pointed out. This means that I even get modversions etc. right. I doubt it ;). modversions is fundamentally broken as designed and has been since day 1. It is absolutely wrong to calculate a hash once at the start then never recalculate it. Config and code changes all affect the hash but we rely on the user manually running make mrproper, make dep to calculate the new hash. Even if you move the hash generation into the compile path so it is recalculated automatically, you still have the problem of deciding where the changed symbols are used. The hash for foo() has changed, where is foo() used? Well, let me claim that it's not broken by design, at least not where you say it is. If you start from a fresh tree (and maybe compile without -j), you'll get a working result. If you change some config variable, edit a file, whatever and re-make, then you may get an invalid result, messed up versions etc. However, that's not broken as designed, it means the dependencies are broken, and things are remade in the wrong order or not at all. But not a fundamental problem: The easiest, but of course slowest way, to remove this breakage is to change the Makefiles to do the equivalent of mrproper before every recompile. That will obviously work (with backing up .config etc), but of course I'm not suggesting this. It's just to say that it can be fixed. Now, I did claim that getting this right is possible, actually, that it even gets done right automatically if you do dependencies the Right Way. If you compile without modversions, everything is rather easy. Now you put on modversions. This will add -include linux/modversions.h to your command line. For everything which has been compiled befored, make will note that the command line changes, therefore it will rebuild everything. Also, due to the changed command line, every source file which is compiled with these flags depends on include/linux/modversions.h (explicitly in the Makefile). modversions.h depends on all the included .ver files, which btw. should be in the same directory as the corresponding export-obj, to remove the flat namespace there. The .ver files depend on the export-obj from which they are generated, and are generated via the usual genksyms rule etc. Of course, they have the usual dependencies, i.e. command line, and the converted files, plus all files included by the C preprocessor etc. So, if you turn on modversions in .config, all these dependencies get triggered, the .ver files are built, then modversions.h, then basically everything gets recompiled. Also, all the dependencies during the intermediate steps are recorded. Now, if you change a config option, this will trigger rebuilding of the affected .ver files. That means modversions.h needs to be remade, and eventually, everything which included the now changed hash will be remade. If your list of export-objs changes due to editing or config, the Makefile will notice, because modversions.h depends on export-objs:%.o=.%.dep, modversions.h will be rebuilt, everything else depends on it, so gets rebuilt. Well, that means it works, you don't get broken output. But it needs to be optimized. Particularly, we are rebuilding to many files. In most cases, a change doesn't affect the hash, so no need to rebuild anything at all. This optimization was already done in the current Makefiles (don't touch modversions.h unless necessary). Still, if a hash changes, actually only the files which depend on the affected versioned symbol need to be remade. Currently, every file which uses any versioned symbol depends on all of them. So we rebuild too
Re: [kbuild-devel] Removal of CPP and CPPFLAGS
On Fri, 18 May 2001, Keith Owens wrote: That is precisely my problem, it is not done cleanly at the moment. We currently have, in roughly this order global cppflags in top level makefile include list from top level makefile module/kernel flags from top level makefile global cflags in top level makefile extra cflags for entire directory from makefile extra cflags for individual file from makefile The last two are called EXTRA_CFLAGS and CFLAGS_$@, even though they almost always contain preprocessor flags. Some of the preprocessing steps are missing some flags, I just got a bug report that genksyms does not get extra cflags from the directory or file so the modversions calculation is not always correct. Okay, I see your point now. There's of course the option to have EXTRA_CPPFLAGS/CPPFLAGS_$@, but most likely Makefile writers will get this wrong, and it effectively doubles the number of FLAGS variables to track. If I maintain the semi-separation between preprocessor and other C flags then it gets very messy when most of the extra cflags are really being used for preproessing options. I would have to include almost all flags in the preprocessor steps anyway, just in case they affected cpp. So why have an artificial separation that only affects a couple of cases, has been a source of error and AFAICT provides no benefit? It is a lot easier to say that all steps get all flags and let the preprocessor and compiler work out which bits they want. Okay, I think you're right, the logical separation is not worth the additional complexity. But why not leave the CPP variable at least? --Kai ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, 18 May 2001, Eric S. Raymond wrote: That being the case, we do face a question of design philosophy, expressed as a policy question about how to design rulesets. Actually two questions: 1. When we have a platform symbol for a reference design like MVME147, do we stick to its spec sheet or consider it representative of all derivatives (which may have other facilities)? I know my answer to this one, which I will implement unless there's strong consensus otherwise. I go for explicitness. If we're going to support MVME147 derivatives and variants in the ruleset, they get their own platform symbols. I believe it's important two distinguish between two things here, auto-configuration and normal configuration. One should take care to not mix these things up. Of course I don't know about the specific hardware there, but I believe selecting NVME147 will give you arch specific code which will cope with general aspects of that board, but also for derived designs. That makes sense, and no need to introduce different config symbols at that level. I'd call CONFIG symbols like that basic, and they should be described by a ruleset which ensures that building the kernel will actually work, and that you have a chance that it even runs. (Things like a SCSI driver requires the SCSI midlayer, etc. which would normally lead to unresolved symbols or the inability to load the driver module into the running kernel later). On the other hand, for some people it would be nice to say I've got the reference board, build the right kernel. That's okay, but it should be another option, and rules like that should be in a separate files, so they don't clutter up the basic rulesets. So, leave the flexibility to people who need, and on top of that you can have a mechanism which allows easier configuration for people who don't want to care about the details. However, more important there would be some option like build me a kernel for the hardware I'm currently running on (and let the user fine tune afterwards). --Kai ___ kbuild-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/kbuild-devel
