Re: [kbuild-devel] Kernel panic: VFS : Unable to mount root fs on 03:03
[Hussain, Farhad] request_module[nls_iso8859-1]: Root fs not mounted Unable to load NLS charset iso8859-1 Kernel panic: VFS: Unable to mount root fs on 03:02 Debice 03:02 is /dev/hda2. It probably means either a) your root device is somewhere other than /dev/hda2 b) you don't have the necessary IDE drivers compiled into your kernel If it's (a), you need to tell your kernel where your root device is - use 'rdev /dev/fd0 /your/root/device' or something. If it's (b), make sure you've selected IDE disk support and your lowlevel IDE type (PIIX, Promise PDC202xx, or whatever). Peter --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: 2.5 kbuild: use of '-z muldefs' for LD?
[Christoph Hellwig] Well, if you want separate copies of it you have to make sure the symbols won't clash, e.g. calling all functions in it MYPREFIX_foo and then do #define MYPREFIX KBUILD_MODNAME ...or just move everything into a header file as static functions. Inline, even, if the code is really trivial enough that you don't want to make a separate module of it. Peter --- 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: [PATCH] Have split-include take another argument
[Tom Rini]
First, does anyone see any problems with the patch itself?
Well,
- str_config += sizeof(CONFIG_) - 1;
+ str_config += strlen(str_split_token);
it does seem a bit inefficient to call strlen() for every single line
of every single source file. Perhaps today's compilers know that
strlen() is invariant and has no side effects, but I vote you go ahead
and optimise it explicitly.
Peter
--- scripts/split-include.c.trini 2002-11-11 17:34:57.0 -0600
+++ scripts/split-include.c 2002-11-11 17:30:45.0 -0600
@@ -52,7 +52,7 @@
FILE * fp_target;
FILE * fp_find;
-int buffer_size;
+int buffer_size, split_token_len;
char * line;
char * old_line;
@@ -72,6 +72,7 @@
str_file_autoconf = argv[1];
str_dir_config= argv[2];
str_split_token = argv[3];
+split_token_len = strlen(str_split_token);
/* Find a buffer size. */
if (stat(str_file_autoconf, stat_buf) != 0)
@@ -116,7 +117,7 @@
continue;
/* Make the output file name. */
- str_config += strlen(str_split_token);
+ str_config += split_token_len;
for (itarget = 0; !isspace(str_config[itarget]); itarget++)
{
int c = (unsigned char) str_config[itarget];
---
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] Possibility to sanely link against off-directory .so
[Petr Baudis] Can't say anything about the C++ stuff, but the second user of shared libraries is going to be lxdialog - hopefully this evening already, in my patches (it already works, I'm only cleaning out few details now; lxdialog + mconf is also user of both these extensions). What is so all-fired great about shared libraries anyway? It's not like our burning need is to save memory when two people run 'make menuconfig' in parallel. What's wrong with 'ar cq libxxx.a $(OBJS)' anyway? It's fast, it's easy, it's portable, and you never have to worry about things like LD_LIBRARY_PATH or `-rpath'. Sure, with Linux you can create a shared library with 'gcc -shared' ... but what about bootstrapping a Linux kernel from a legacy OS? (Yes, people do compile Linux on Solaris, for example.) HOSTCC may or may not be gcc, and if it is, it may or may not support creating shared libraries, and if it does, you might need funky flags or variables to denote the link-time or run-time search path. Why bother? `ar' is basically universal, both in availability and usage. (Well, *almost* universal usage: if you want to run 'ranlib', be prepared for it not to exist.) Basically, what I'm saying is, I see no need for the existing .so in the kernel build, much less another one. Static libraries are ever so much easier to manage. Peter --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH] [kbuild] Possibility to sanely link against off-directory .so
[Peter Samuelson] Basically, what I'm saying is, I see no need for the existing .so in the kernel build, much less another one. Static libraries are ever so much easier to manage. [Roman Zippel] If you want to limit people to the config tools in the kernel, there is indeed no need for a shared library. Note that during the next development cycle all graphical front ends are possibly removed. Huh? I don't get it. How is a shared library any better than a static library in this regard? I'm pondering the traditional advantages of shared libraries, and I cannot think of a single one that matters here. Peter --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH] [kbuild] Possibility to sanely link against off-directory .so
[Peter Samuelson] Huh? I don't get it. How is a shared library any better than a static library in this regard? I'm pondering the traditional advantages of shared libraries, and I cannot think of a single one that matters here. [Roman Zippel] Shared libraries can be loaded dynamically, this means distribution can package the graphical front ends and the user doesn't need to install huge development packages. I still don't get it. Why can't the distribution vendor just link /usr/bin/qconf against $(LINUX)/scripts/kconfig/libkconfig.a? Peter --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH] [kbuild] Possibility to sanely link against off-directory .so
[Roman Zippel] New features will be added and only the parser that comes with the kernel will understand them. It's less likley that the library API will change. Even if this is true - I'll grant you that it may be - let the vendor package /usr/bin/qconf as a shell script that links /usr/lib/qconf.o with -lqt and $(LINUX)/scripts/kconfig/libkconfig.a . It's a little unorthodox, but it removes the hackery of figuring out how HOSTCC is supposed to build a shared library and whether any magic is needed at runtime. Removes the need for the horrible stuff libtool was invented for, in other words. Remember, the whole point of HOSTCC is to support a build environment different from the compile target - arbitrarily different, even. Peter --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH] [kbuild] Possibility to sanely link against off-directory .so
[Roman Zippel] If your build environment doesn't support shared libraries, you can easily generate a static library instead and link against it yourself, like you described, but it's no reason to deny the convenience to working environments. Yeah, but until I do, I can't even run 'make oldconfig'. (This isn't about me - I will probably always build on Linux, with gcc - it's about weird environments like cross-compiling from Solaris, which I'm told was often done in the earlier stages of SPARC Linux.) I suggest that *at least* the built-in targets should link libkconfig statically - either via libkconfig.a or just the list of .o files. Peter --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH] [kbuild] Possibility to sanely link against off-directory .so
[Petr Baudis] I'm a bit lost here - the kernel uses tons of gcc extensions - how is another compiler supposed to understand them? And if it is specifically extended to understand them, isn't it likely that it'll understand the -shared switch in gcc-like way as well? There is a difference between $(CC) and $(HOSTCC). We have both of them for a reason. $(CC) specifies the compiler used to build the kernel - it may or may not be your regular system compiler. It can even be for another architecture - for example, it may produce PowerPC object files from the comfort (?) of your x86 PC. $(HOSTCC) is specifically to build executables that are to run *on* the build system itself - kconfig, for example. If you're running on x86 and building a PowerPC kernel, you need an x86 version of kconfig, not a PowerPC version. So $(CC) *must* be a gcc (or a convincing facsimile) - but $(HOSTCC) can be *any* C compiler on your system. I don't think anyone tries to use any gcc extensions with $(HOSTCC). And how likely is situation when someone want to configure a kernel with non-gcc compiler and actually build it with gcc? Not very likely, but you take a lot for granted. On many combinations of Unix + gcc versions, `gcc -shared' doesn't work until you spend half a day hand-tweaking the specs file whilst poring over the obscure flags section of the `ld' manpage. Try it for gcc 2.95 on AIX sometime, for a bit of good clean fun. My point was and is that while shared libraries are a (relative!) breeze on Linux, they have always been a horrible portability headache; furthermore, the kernel build system doesn't need them and ought to do without. Peter --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] A hole in kernel space!
Note: this question really belongs on [EMAIL PROTECTED].
[Pannaga Bhushan]
I am looking for a setup where I need to have a certain amount
of data always available to the kernel. The size of data I am looking
at is abt 40MB(preferably, but I will settle for 20MB too) . So the
normal kmalloc will not help me. So what I did was, I created a hole
in kernel space by putting the following line in vmlinux.lds
ALIGN(4096);
__hole_start = .;
. = . + 0xmy_size;
__hole_end = .;
I assume you also tried the old-fashioned C method:
#include asm/page.h
static char __hole_start[0xmy_size] __attribute__((__aligned__(PAGE_SIZE)));
Did that not work either?
1. Is there any other way I can get to keep 40MB(or even 20MB) of
contiguous kernel memory space ?
There used to be a patch out there called `bigphysarea' - look around,
perhaps someone is still maintaining it. It should do what you want.
2.Abt the 17MB hole, I am able to use after the _end = .;
is this 17MB really there in kernel image?('cos it isn't in
any segment and also it appears after _end).
I doubt it is accessible, but that is really uninformed speculation on
my part.
(basically, i want by data in kernel space always available to kernel
without having to bother abt swapping the pages back)
User space could allocate this space and then call mlockall(). That
does not guarantee *physically* contiguous space, though, and is only
accessible within to the address space of that one process.
Peter
---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [upatch] tweak for !KBUILD_VERBOSE output
[Kai Germaschewski] 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 idea was that [M] is printed whenever a new module is born. (M) means a module is in progress. If you *really* don't like this distinction, I'll remove it. I thought it was nice to have, though. The LD line also doesn't really depend on whether we're linking a module or not, so not sure about the [M] there. See above. 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. That's what the patch does. When I said composite object I really meant composite module. Also, implementation-wise, it may be cleaner to handle things the same way '-DMODULE' gets added? You're probably right. Try this one. (BTW, is there a better way to set a variable equal to?) Peter --- 2.5.45/scripts/Makefile.build~ 2002-11-03 07:44:20.0 -0600 +++ 2.5.45/scripts/Makefile.build 2002-11-04 13:58:33.0 -0600 @@ -53,11 +53,21 @@ # Default is built-in, unless we know otherwise modkern_cflags := $(CFLAGS_KERNEL) +quiet_modtag := $(if ,, ) $(real-objs-m): modkern_cflags := $(CFLAGS_MODULE) $(real-objs-m:.o=.i) : modkern_cflags := $(CFLAGS_MODULE) $(real-objs-m:.o=.lst): modkern_cflags := $(CFLAGS_MODULE) +$(real-objs-m): quiet_modtag := (M) +$(real-objs-m:.o=.i) : quiet_modtag := (M) +$(real-objs-m:.o=.s) : quiet_modtag := (M) +$(real-objs-m:.o=.lst): quiet_modtag := (M) +$(obj-m) : quiet_modtag := [M] +$(obj-m:.o=.i): quiet_modtag := [M] +$(obj-m:.o=.s): quiet_modtag := [M] +$(obj-m:.o=.lst) : quiet_modtag := [M] + $(export-objs): export_flags := $(EXPORT_FLAGS) $(export-objs:.o=.i) : export_flags := $(EXPORT_FLAGS) $(export-objs:.o=.s) : export_flags := $(EXPORT_FLAGS) @@ -68,19 +78,19 @@ -DKBUILD_BASENAME=$(subst $(comma),_,$(subst -,_,$(*F))) \ $(export_flags) -quiet_cmd_cc_s_c = CC $@ +quiet_cmd_cc_s_c = CC $(quiet_modtag) $@ cmd_cc_s_c = $(CC) $(c_flags) -S -o $@ $ %.s: %.c FORCE $(call if_changed_dep,cc_s_c) -quiet_cmd_cc_i_c = CPP $@ +quiet_cmd_cc_i_c = CPP $(quiet_modtag) $@ cmd_cc_i_c = $(CPP) $(c_flags) -o $@ $ %.i: %.c FORCE $(call if_changed_dep,cc_i_c) -quiet_cmd_cc_o_c = CC $@ +quiet_cmd_cc_o_c = CC $(quiet_modtag) $@ cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $ %.o: %.c FORCE @@ -103,13 +113,13 @@ a_flags = -Wp,-MD,$(depfile) $(AFLAGS) $(NOSTDINC_FLAGS) \ $(modkern_aflags) $(EXTRA_AFLAGS) $(AFLAGS_$(*F).o) -quiet_cmd_as_s_S = CPP $@ +quiet_cmd_as_s_S = CPP $(quiet_modtag) $@ cmd_as_s_S = $(CPP) $(a_flags) -o $@ $ %.s: %.S FORCE $(call if_changed_dep,as_s_S) -quiet_cmd_as_o_S = AS $@ +quiet_cmd_as_o_S = AS $(quiet_modtag) $@ cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $ %.o: %.S FORCE @@ -156,7 +166,7 @@ # Rule to link composite objects # -quiet_cmd_link_multi = LD $@ +quiet_cmd_link_multi = LD $(quiet_modtag) $@ cmd_link_multi = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(addprefix $(obj)/,$($(subst $(obj)/,,$(@:.o=-objs))) $($(subst $(obj)/,,$(@:.o=-y,$^) # We would rather have a list of rules like --- 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
[Kai Germaschewski] Well, it's not that my life depends on it ;) Heh. But I see the non-verbose mode as an abbreviated view of what happens, and normally you cannot see the difference between module or part of module, so it appears inconsistent to have that distinction in the short view? Same amount of screen space, just as readable, more information. What's not to like? Well, you're the one who'll have to merge this to Linus, so I've switched it. You can do := $(empty) $(empty), which maybe looks a little less magical ;) Done. --- 2.5.45/scripts/Makefile.build~ 2002-11-03 07:44:20.0 -0600 +++ 2.5.45/scripts/Makefile.build 2002-11-04 18:35:59.0 -0600 @@ -53,11 +53,19 @@ # Default is built-in, unless we know otherwise modkern_cflags := $(CFLAGS_KERNEL) +quiet_modtag := $(empty) $(empty) $(real-objs-m): modkern_cflags := $(CFLAGS_MODULE) $(real-objs-m:.o=.i) : modkern_cflags := $(CFLAGS_MODULE) $(real-objs-m:.o=.lst): modkern_cflags := $(CFLAGS_MODULE) +$(real-objs-m): quiet_modtag := [M] +$(real-objs-m:.o=.i) : quiet_modtag := [M] +$(real-objs-m:.o=.s) : quiet_modtag := [M] +$(real-objs-m:.o=.lst): quiet_modtag := [M] +$(obj-m) : quiet_modtag := [M] +$(obj-m:.o=.lst) : quiet_modtag := [M] + $(export-objs): export_flags := $(EXPORT_FLAGS) $(export-objs:.o=.i) : export_flags := $(EXPORT_FLAGS) $(export-objs:.o=.s) : export_flags := $(EXPORT_FLAGS) @@ -68,19 +76,19 @@ -DKBUILD_BASENAME=$(subst $(comma),_,$(subst -,_,$(*F))) \ $(export_flags) -quiet_cmd_cc_s_c = CC $@ +quiet_cmd_cc_s_c = CC $(quiet_modtag) $@ cmd_cc_s_c = $(CC) $(c_flags) -S -o $@ $ %.s: %.c FORCE $(call if_changed_dep,cc_s_c) -quiet_cmd_cc_i_c = CPP $@ +quiet_cmd_cc_i_c = CPP $(quiet_modtag) $@ cmd_cc_i_c = $(CPP) $(c_flags) -o $@ $ %.i: %.c FORCE $(call if_changed_dep,cc_i_c) -quiet_cmd_cc_o_c = CC $@ +quiet_cmd_cc_o_c = CC $(quiet_modtag) $@ cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $ %.o: %.c FORCE @@ -103,13 +111,13 @@ a_flags = -Wp,-MD,$(depfile) $(AFLAGS) $(NOSTDINC_FLAGS) \ $(modkern_aflags) $(EXTRA_AFLAGS) $(AFLAGS_$(*F).o) -quiet_cmd_as_s_S = CPP $@ +quiet_cmd_as_s_S = CPP $(quiet_modtag) $@ cmd_as_s_S = $(CPP) $(a_flags) -o $@ $ %.s: %.S FORCE $(call if_changed_dep,as_s_S) -quiet_cmd_as_o_S = AS $@ +quiet_cmd_as_o_S = AS $(quiet_modtag) $@ cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $ %.o: %.S FORCE @@ -156,7 +164,7 @@ # Rule to link composite objects # -quiet_cmd_link_multi = LD $@ +quiet_cmd_link_multi = LD $(quiet_modtag) $@ cmd_link_multi = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(addprefix $(obj)/,$($(subst $(obj)/,,$(@:.o=-objs))) $($(subst $(obj)/,,$(@:.o=-y,$^) # We would rather have a list of rules like --- 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
[Kai Germaschewski] I completely agree, though it weakens my argument about consistency ;) Heh. Now we only need to convince Peter. I just sent you a patch with all [M], so I guess you can consider me sufficiently convinced. I'm not, really, but it's hardly an important issue, so I figured I'd stop wasting all of our time. Besides, I am outnumbered 2-1. (: I think the world would have been better off if 5 years ago we had decided to come up with a new suffix (say .ko) for kernel modules. Sure they are object files, but they are *more* than that. (And some day we may want to use ... who knows? shared libraries?) The biggest advantage would have been avoiding crap like sr_mod.o in favor of the much saner sr.ko As a side effect, this would have made the present issue go away, because there would be no need for the additional information: .ko == final module, .o == not final module. At this point I suspect it is about 5 years too late to propose my .ko change. Too much user confusion. Too bad. Peter --- 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] [upatch] tweak for !KBUILD_VERBOSE output
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 Does not support CPP or CC -S ... do those even work? Peter --- 2.5.45/scripts/Makefile.build~ 2002-11-03 07:44:20.0 -0600 +++ 2.5.45/scripts/Makefile.build 2002-11-03 10:53:09.0 -0600 @@ -68,6 +68,8 @@ -DKBUILD_BASENAME=$(subst $(comma),_,$(subst -,_,$(*F))) \ $(export_flags) +quiet_modtag = $(if $(findstring $@,$(obj-m)),[M],$(if $(findstring +$@,$(real-objs-m)),(M), )) + quiet_cmd_cc_s_c = CC $@ cmd_cc_s_c = $(CC) $(c_flags) -S -o $@ $ @@ -80,7 +82,7 @@ %.i: %.c FORCE $(call if_changed_dep,cc_i_c) -quiet_cmd_cc_o_c = CC $@ +quiet_cmd_cc_o_c = CC $(quiet_modtag) $@ cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $ %.o: %.c FORCE @@ -109,7 +111,7 @@ %.s: %.S FORCE $(call if_changed_dep,as_s_S) -quiet_cmd_as_o_S = AS $@ +quiet_cmd_as_o_S = AS $(quiet_modtag) $@ cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $ %.o: %.S FORCE @@ -156,7 +158,7 @@ # Rule to link composite objects # -quiet_cmd_link_multi = LD $@ +quiet_cmd_link_multi = LD $(quiet_modtag) $@ cmd_link_multi = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(addprefix $(obj)/,$($(subst $(obj)/,,$(@:.o=-objs))) $($(subst $(obj)/,,$(@:.o=-y,$^) # We would rather have a list of rules like --- 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: [upatch] tweak for !KBUILD_VERBOSE output
[I wrote] +quiet_modtag = $(if $(findstring $@,$(obj-m)),[M],$(if $(findstring $@,$(real-objs-m)),(M), )) Actually s/findstring/filter/g is a bit cleaner. Peter --- 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: [upatch] tweak for !KBUILD_VERBOSE output
[Sam Ravnborg] Nice. Thanks. Does not support CPP or CC -S ... do those even work? Could you please elaborate - what do you impose by CPP and CC -s? Maybe it just too late in my timezone... I'm talking about the built-in rules for .c-.i (preprocessing), .S-.s (preprocessing), and .c-.s (compiling but not assembling). My mechanism didn't support those rules, so they always just printed 'CPP obj.i', etc, whether or not -DMODULE is defined. Interestingly, those rules seem to work fine now. I could have sworn yesterday that they didn't work at all. Weird. So, since they are working for me now, here is a better patch. Peter --- 2.5.45/scripts/Makefile.build~ 2002-11-03 07:44:20.0 -0600 +++ 2.5.45/scripts/Makefile.build 2002-11-03 21:04:26.0 -0600 @@ -68,19 +68,22 @@ -DKBUILD_BASENAME=$(subst $(comma),_,$(subst -,_,$(*F))) \ $(export_flags) -quiet_cmd_cc_s_c = CC $@ +targ2obj = $(patsubst %.s,%.o,$(patsubst %.i,%.o,$@)) +quiet_modtag = $(if $(filter $(targ2obj),$(obj-m)),[M],$(if $(filter +$(targ2obj),$(real-objs-m)),(M), )) + +quiet_cmd_cc_s_c = CC $(quiet_modtag) $@ cmd_cc_s_c = $(CC) $(c_flags) -S -o $@ $ %.s: %.c FORCE $(call if_changed_dep,cc_s_c) -quiet_cmd_cc_i_c = CPP $@ +quiet_cmd_cc_i_c = CPP $(quiet_modtag) $@ cmd_cc_i_c = $(CPP) $(c_flags) -o $@ $ %.i: %.c FORCE $(call if_changed_dep,cc_i_c) -quiet_cmd_cc_o_c = CC $@ +quiet_cmd_cc_o_c = CC $(quiet_modtag) $@ cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $ %.o: %.c FORCE @@ -103,13 +106,13 @@ a_flags = -Wp,-MD,$(depfile) $(AFLAGS) $(NOSTDINC_FLAGS) \ $(modkern_aflags) $(EXTRA_AFLAGS) $(AFLAGS_$(*F).o) -quiet_cmd_as_s_S = CPP $@ +quiet_cmd_as_s_S = CPP $(quiet_modtag) $@ cmd_as_s_S = $(CPP) $(a_flags) -o $@ $ %.s: %.S FORCE $(call if_changed_dep,as_s_S) -quiet_cmd_as_o_S = AS $@ +quiet_cmd_as_o_S = AS $(quiet_modtag) $@ cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $ %.o: %.S FORCE @@ -156,7 +159,7 @@ # Rule to link composite objects # -quiet_cmd_link_multi = LD $@ +quiet_cmd_link_multi = LD $(quiet_modtag) $@ cmd_link_multi = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(addprefix $(obj)/,$($(subst $(obj)/,,$(@:.o=-objs))) $($(subst $(obj)/,,$(@:.o=-y,$^) # We would rather have a list of rules like --- 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: linux kernel conf 0.8
[Roman Zippel] The problem is that the config syntax will continue to evolve and currently I prefer to keep the library close to the matching config files. I think I can keep the basic structure constant, but new options will be added, so IMO it's more likely that a front end works with a newer library than that a library can understand a newer syntax. Besides which, I think it is ridiculous that one would have to download and install a kernel configurator just to build a kernel. Current minimum requirements for compiling the thing are gcc, binutils and GNU make. The kernel can't very well ship a copy of any of those, because (a) they're huge and (b) they're useful for many things other than building kernels. Roman's library is neither. (And no, modutils isn't a counterexample - you can build, install and run a kernel without it.) Peter --- 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] kbuild status
[Brendan J Simon] Is there a site that documents the changes the Kai has made or is making ? Well, there's http://www.??.kernel.org/pub/linux/kernel/v2.5/ChangLog-*, search for kai@. He seems to have started in 2.5.7. Off the top of my head, the main kbuild2.5 features 2.5.40 *doesn't* have would be: * separate source and object trees - but see below * source tree overlays, aka shadow tree support * backward timestamp tracking * nonrecursive make * speed - largely due to the nonrecursive make, I think The backward timestamp tracking was implemented because it is required for proper handling of source overlays. It is useful in its own right, but in the 15+-year history of 'make', most of the world seems to have gotten along fine without it, so it's hard to justify as *necesssary* outside that context. I'm mainly interested in building in seperate directories, building from readonly src directories and having a single makefile so that a complete dependency graph is generated. The separate build directory is something Kai is currently working on, and I'm guessing it will work in another week or two. Most of the infrastructure is in place already. The complete dependency graph, one feature of nonrecursive make, might be necessary for 100% correct and efficient MODVERSIONS handling, but it is not necessary for most other tasks, I believe. It certainly makes it *easier* to implement minimum necessary change build semantics, but I am not convinced it's *necessary* for this. It sounds like politics has killed another great project. Hopefully Kai can do a good job of getting some of great kbuild work into the kernel (in some form). He has been doing an excellent job so far, in my opinion - especially considering the mess the build system was in to begin with. The remaining kbuld2.5 features - source overlays, backward timestamp tracking, and nonrecursive make (and the accompanying speed increase) - are probably impossible with the current architecture. Peter --- 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] kbuild status
[Brendan J Simon] Thanks for that information. Looks like Kai's work will/may eventually do what I want but when will it be mainstream, that is the question. If by mainstream you mean in 2.4, probably never. There is just no motivation to backport it, and I doubt Marcelo would accept the changes if anyone did. Which, indeed, he shouldn't. The 2.4 makefiles only require GNU Make 3.77, whereas 2.5 now uses certain features introduced in 3.78 and 3.79. It is not acceptible to change the required program list within a stable kernel release cycle. And no, you can't really hack around the 3.79 features Kai is using. At least not easily. Kai and I both tried, somewhere in the 2.4.0testN series, I believe it was I guess my only option is to either keep porting kbuild-2.5 (which seems like a waste of time if it isn't going to become mainstream) or put some other kludges in my build system to work around the deficiencies of the current kernel build system. Unfortunately, I think the latter is probably going to win. You may have some luck backporting the Kai makefiles. Because he took an incremental approach, rather than a rewrite, most of the porting will consist of deleting cruft from makefiles. The hard parts will be backporting (a) the toplevel Makefile, and (b) the arch/* makefiles. Just realise that your porting work will never make mainstream 2.4, because of the Make version requirement. The backward timestamp tracking was implemented because it is required for proper handling of source overlays. It is useful in its own right, but in the 15+-year history of 'make', most of the world seems to have gotten along fine without it, so it's hard to justify as *necesssary* outside that context. What does this do and how is it useful in non shadow tree environments ? The way 'make' determines when a file needs to be rebuilt is by the simple heuristic is this file older than any of its dependencies? This works fine if you can trust your timestamps to increase monotonically. Seems obvious - but there are in fact at least four scenarios where you *don't* have monotonic timestamps: (1) If some files are on an NFS server and others on a local machine (think separate source / object trees), the two system clocks may be far enough from each other that a freshly built object file still shows up as older than the source - or a stale object shows up as newer. (2) You can get similar effects one a single box by using ntpd to skew your local clock. (3) Things like 'tar', plus certain (broken) source management tools, can move a file's timestamp backward. (4) Finally, if you use shadow trees, and you delete a file on a shadow layer - so that a different source file is visible than was visible last time you built the object - the visible timestamp is not indicative of whether the object is up-to-date. Keith's kbuild2.5 fixes all four problems by tracking all source file timestamps; it triggers an object rebuild *whenever* the source file's timestamp changes - whether or not the source is newer than the existing object, and whether its time moved forward or backward. Like I said, this is a feature the world has done without for the past 15 or 20 years, so it's kind of a hard sell - unless you use shadow trees, where it is quite necessary because of case (4). It's quite ironic but I bet Kai ends up with something similar to kbuild-2.5 at the end of the day. I'll bet against you. The two architectures have basically *nothing* in common except their external behavior. Keith runs a fancy preprocessor program that puts together a master makefile out of all the directory makefiles and maintains a state database. Kai just plods along with a recursive make structure with a very sophisticated piece of infrastructure called Rules.make, but doesn't really do any preprocessing or dynamic content. Certainly Kai has studied kbuild2.5, but there really isn't any way to use an incremental approach to produce the kbuild2.5 architecture from the in-kernel kbuild architecture. It's a problem of irreducible complexity, as they say in evolution debates. I know I've stripped back other peoples projects in the past (mainly because I didn't understand them or thought something was irrelevant) only to find me adding back features at a later date and ending up with something similar to what I started with. I hear ya. Remember the 2.1.1xx days? Linus looked at the relatively mature uusb project and basically said Wow, what a load of crap, the usb spec isn't *nearly* this complex. Then he spent a weekend hacking up an extremely simple but working usb keyboard / mouse driver. Fast-forward a few years and look at the kernel usb system now. I have no idea whether it resembles uusb at all, but simple it ain't Peter --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
Re: [kbuild-devel] kbuild status
[Brendan J Simon] What is the status of kbuild with respect to getting into the kernel proper ? Is it going to get into the linus kernel source tree ?? At this point it doesn't seem likely. Of the rich feature set Keith produced, Kai Germaschewski has managed to replicate the most compelling features (though by no means all!) by incrementally tweaking the Rules.make-based system, so Linus doesn't seem to see the urgency of replacing the whole thing. I hope kbuild-2.5 does have a future because so much hard work has gone into it. It would be a shame to see all the effort wasted. Me too, but Linus has never made any secret of the fact that he doesn't really care much about effort wasted, so long as he gets a kernel he is happy with. Call it what you will, we all know that's how this game is played Peter --- 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
[Sam Ravnborg] +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 ) Except that it is harmless. list-multi is a hint which the kbuild system no longer needs. Code with list-multi is (I believe) still compatible with today's kbuild, so there's no need to *force* a cleanup. Peter --- 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
[I wrote] I guess I wasn't quite clear: my current implementation is both visibility + value, not visibility only (like current if [ ]) or value only (like an earlier discussion of dep_if). [Greg Banks] Aha. I think you're going to be arguing uphill to get it in. Could be. Perhaps none of this will see the light of day. But, while I've designed it to replace the current syntax, it can coexist with it for as long as necessary. and easy to work around if not wanted. Not so sure about that. My Menuconfig patch still has one bug, which I'm still thinking about the best way to fix, so I can't properly test this stuff yet - but with the Config.in files I've dealt with so far, I haven't found it hard to work around this semantic difference. There are lots of instances of things like if [ $CONFIG_FOO = y -o $CONFIG_FOO = m ]; then dep_tristate 'Bar' CONFIG_BAR $CONFIG_FOO ... fi which can be replaced by dep_if CONFIG_FOO tristate 'Bar' CONFIG_BAR ... dep_fi but few, if any, instances of if [ $CONFIG_FOO = y -o $CONFIG_FOO = m ]; then tristate 'Bar' CONFIG_BAR fi which would require the more complex dep_if CONFIG_FOO=y or CONFIG_FOO=m tristate 'Bar' CONFIG_BAR dep_fi (Not to mention the possibility that such instances are buggy and should have been a dep_tristate in the first place.) My primitives are all set to *not* ignore empty dependency values, if and when we can verify that the corpus is ready for that change. The mechanism is also there (come The Day) to change Oh no, the dreaded flag day. Heh. No, a flag day is where BIGNUM things have to be patched at once because there's no migration path. In this case there *is* a migration path, so the only things that break on The Day are things the gcml2 checker (and a grep through the makefiles for suspicious things like 'ifdef') has warned us about but we didn't bother to fix. Peter --- 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
[Kai Henningsen] Incidentally, wouldn't it make sense to use dep_if instead of if_dep? Yes, probably. I'll go ahead and change it in my tree, unless anyone objects violently. Peter --- 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
[Greg Banks]
Ok, we need to be a little bit careful about semantics here, or
there is going to be issues converting the existing corpus.
Agreed.
Currently the if syntax and dependencies are not the same thing;
the if condition is purely a visibility limit, and deps are both
value and visibility limits.
Good point. I considered that point and I think I have it covered in
my current patch (which still doesn't work - I was gone all weekend
and got nothing done), but I guess the *documentation* doesn't
specify.
if [ $CONFIG_FOO = y ]; then
bool '...' CONFIG_BAR
fi
is not semantically identical to
dep_bool '...' CONFIG_BAR $CONFIG_FOO
(even ignoring the issue) because in the second case CONFIG_FOO=n
forces CONFIG_BAR=n whereas in the first case it makes no difference
to the value of CONFIG_BAR, so CONFIG_BAR will retain the value from
previous definitions or defconfig.
My current implementation of if_dep is *not*, as previously theorised,
a drop-in two-way replacement for adding dependencies to the end of
dep_* statements. I currently have it short-circuiting, so statements
are in effect *not* executing in the 'n' case (or the 'm' case, for
bool / dep_bool).
In other words, my implementation matches current 'if [ ]' behavior,
and this was on purpose. I suppose this should be made clearer in the
documentation.
if_dep CONFIG_BAZ
bool '...' CONFIG_QUUX
fi_dep
is semantically equivalent to
if [ $CONFIG_BAZ = y -o $CONFIG_BAZ = m ]; then
dep_mbool '...' CONFIG_QUUX $CONFIG_BAZ
else
define_bool CONFIG_QUUX n
fi
No, at least not in my implementation. Like I said, my docs might be
unclear on this point.
I think we should focus more on first fixing problems with the
existing corpus which can be fixed without changing syntax, then
starting to think about language redesign for the 2.7 timeframe.
Agreed.
Adding a tristate value limit to int or hex makes no sense, nor
to choice. You'd have to define the semantics as if_dep affects
the visibility of all statements and the values of bools and
tristates only.
That's the plan, yes.
I think a better solution would be to provide separate iflike
statements, one which is a pure visibility limit like the old if
but with the syntax cleaner and the behaviour with regularised;
the other which does both visibility limit and a value limit on
dep_bools dep_tristates (but those only, the existing bool
tristate remain unchanged).
I think that is overengineering. If you really don't want value
limits, you use 'if_dep !CONFIG_FOO=n' which, in the case of
CONFIG_FOO={y,m}, does not restrict the block.
(This works because I currently specify that the = operator treats ''
as 'n'. I suppose this feature is worth debating, but I think it is
useful.)
Peter
---
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
[Kai Germaschewski] Seeing it from that point of view, it may actually turn into something which can agree with much more easily. Great! I've been hoping for your support - not only because I respect your judgment, but also because Linus takes patches from you. (: 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. OK.. 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've proposed this in the past - well, at least the part about making bool == dep_bool or dep_mbool, and tristate == dep_tristate. I was going to raise the issue again, after the if_dep debate settled down some. I didn't look into like choice statements, but I'd hope it's possible to add dependencies to them, too, for consistency. I agree. Actually, if we're changing 'choice' anyway, it should be redesigned. Status quo takes three arguments: choice 'prompt string' 'choice-text-1 CONFIG_CHOICE1 choice-text-2 CONFIG_CHOICE2' 'choice-text-default' This is bad because it pretty much requires multi-line strings, and because the choice texts cannot have spaces in them. In my opinion it should take a variable number of args: choice 'prompt string' 'choice text 1' CONFIG_CHOICE1 'choice text 2' CONFIG_CHOICE2 CONFIG_CHOICE_DEFAULT I suppose you could then extend it with dependencies by putting those at the end. That makes for minor parsing problems, since you have to detect which arguments are which - basically I guess you look for two CONFIG_* in a row. Alternatively, we could make the parsing job a little less fragile by using an explicit keyword like 'dep': choice 'prompt' 'text 1' CONFIG_1 'text 2' CONFIG_2 'text 3' CONFIG_3 CONFIG_1 dep CONFIG_ISA !CONFIG_ARM Translation: CONFIG_1 is the default, but the prompt is suppressed if CONFIG_ISA is unset, or if CONFIG_ARM is set. Eh? 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'. Already in my patches. Actually, I don't have an 'and' (Greg asked about this too), for two reasons. First, adjacent words are implicitly ANDed together anyway, so there's no need. Second, since OR takes low precedence and the implicit AND takes high precedence, having an explicit 'and' keyword would generate confusion about its precedence with regards to 'or'. I already rejected trying to do any sort of grouping - mostly because the shell parsers would choke on ( ) and nothing else looks as nice - so, since there is no way to group things, the precedence table needs to be as simple and clear as possible. I think my current proposal fits the bill. 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 I think a sensible default would be m - y in this case (like mbool) That's the current default for if_dep already. I do not know if it is worthwhile to add a != operator to complement the = operator, but perhaps it is, if only because people will expect it. I'll go ahead and add it to my Menuconfig patch, at least for now. It should be noted that in many cases, this whole distinction is unimportant, because the guard symbol (for example CONFIG_ISA) is already boolean. I'd be interested to see if these statements are actually sufficient to express all we've got today. [...] 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. Right. I'll try to find the time to convert a few large Config.in / config.in files today, and post a patch (along with my current version of Menuconfig). Speaking of which - would it help anyone evaluate this stuff if I produced a patched Configure to complement the patched Menuconfig? I haven't been hacking on Configure, because for my purposes, stuff is easier to test with Menuconfig. (I added a line to init/Config.in that does source test.in, so I can easily put tests in $(TOPDIR)/test.in. Works great.) (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') Reasonable people can disagree on this one. '' today means the user has never seen the question, so you would be changing existing semantics. I for one am fine with that, but others will probably argue for the status quo. According to MEC,
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
[Roman Zippel] I really hate to spoil the fun (: but could someone explain to me, why this is necessary? What problems does that fix? It's not necessary, technically - it doesn't directly fix any bugs. It falls under cleanup, and as such, it is supposed to make bugs harder to write and easier to spot. The problems it solves are problems of readability and awkwardness in the current [Cc]onfig.in corpus. Basically the current discussion revolves around the best way to evolve the config language to make it more suitable for its purpose. This is of course in contrast to what ESR and you have tried, which is to replace the whole thing. My main goal is to make it easier to write Config.in files, by making the syntax and semantics less awkward. Certainly one side effect is that it will be possible to do automatic (EXPERIMENTAL) and (OBSOLETE) tags, but that has never been the primary intent. * The current 'if' statement is really ugly and unintuitive, unless you are comparing it to Bourne shell syntax, in which case it is merely ugly and *somewhat* unintuitive. (It is still unintuitive because it offers only a subset of Bourne shell functionality, and that subset is arbitrarily defined.) If you use Bourne shell syntax outside the config language spec, your file may break subtly in Configure or Menuconfig, or spectacularly in xconfig (since xconfig doesn't use the shell). Since most people don't test their changes on all three parsers, they may not notice. * Current 'if' semantics are hard to get right in many common cases. For example, a guard variable may be either unset () or False (n). If you want something to depend on the guard variable, you have to cover both cases with AND or OR. Many people do not think to do this. I am trying to design a replacement statement which *does* cover common cases easily, while not losing any of the flexibility we have now. The current state of my proposal gives quite a bit *more* functionality than we have now - some config files have the potential to become considerably simpler / shorter. * By having *one* standard syntax for dependency declarations, the whole language spec is more consistent and, incidentally, easier to write a parser for. (The fact that *human* parsing is easier as well is a related but separate advantage.) None of that answers your real question: why not use either CML2 or your work? Answer: evolution, not revolution. You say you have tried hard to keep the existing rulebase functionally identical (something Eric, of course, did not do). Fine, but so did Keith Owens when he wrote kbuild 2.5, and look where that got him. I have looked through the kbuild2.5 makefiles, and there were many places where Keith deliberately enforced things that looked completely arbitrary (link order in particular) merely for the sake of having an apples-to- apples comparison. So what did Linus do? He refused to take Keith's patches directly, but instead accepted Kai's incremental fixups to the current build system, which is nothing like Keith's system. Kai, in turn, made so many tweaks to the current system that it now resembles - in functionality if not in implementation - kbuild2.5. (Yes, the current build system is missing some features, but considering that there have been no radical changes, it's pretty impressive what Kai has managed to wring out of it.) I'm taking pretty much the same approach: removing warts from the current config system, one by one, to see how clean it can get. Perhaps eventually someone will be able to merge in a completely different system, but if so, as Greg has said, what we are doing now will lay the ground-work for such a change, by removing a lot of kludges from the rulebase. The only reason I've seen so far is to make the generation of (EXPERIMENTAL) possible. Is this really that important to risk new problems? I happen to think the risk of new problems is relatively low. My experience with Menuconfig so far is that the types of features I am adding are relatively straightforward, and it's surprisingly easy to verify that things are all working correctly. I suppose xconfig will be the usual nightmare - perhaps Andrzej (the de facto xconfig maintainer) will help out when the time comes - but Configure and Menuconfig have presented no major problems so far. There *is* the risk of adding bugs when changing the rulebase, but those will be isolated to individual rule files, and should be easy to debug if and when they happen. Of course, Menuconfig is probably the easiest of the three, since it explicitly requires bash (Configure, OTOH, works with any /bin/sh), so I don't have to worry much about shell compatibility. I guess it wouldn't hurt to install bash 1.14 somewhere so I can make sure things will work on Red Hat 6.0. An old bash bug bit me once before, in Linux 2.2.19pre Peter --- This sf.net email is
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
[I wrote] I've come up with syntax I think I'm happy with. Thank you one and all for all the discussion and suggestions for improvement on my proposals. I've incorporated a lot of feedback. I know I promised to try and come up with a working prototype including some Config.in files, but some of the Menuconfig bits were harder than they looked, and I ran out of time tonight - I'm about to leave town for a couple of days. My Menuconfig currently doesn't work, and I haven't converted any Config.in files yet. Meanwhile, here is the documentation portion. Critiques are more than welcome, both for the proposal and for its documentation.. Peter --- 2.5.31/Documentation/kbuild/config-language.txt 2002-06-09 00:29:17.0 -0500 +++ 2.5.31w/Documentation/kbuild/config-language.txt2002-08-16 21:18:16.0 +-0500 @@ -84,8 +84,10 @@ to generate dependencies on individual CONFIG_* symbols instead of making one massive dependency on include/linux/autoconf.h. -A /dep/ is a dependency. Syntactically, it is a /word/. At run -time, a /dep/ must evaluate to y, m, n, or . +A /dep/ is a dependency list. Syntactically, it is zero or more +/word/s separated by whitespace. When evaluated, a /dep/ is +reduced to a single character y, m or n. See the following +section for details. An /expr/ is a bash-like expression using the operators '=', '!=', '-a', '-o', and '!'. @@ -116,12 +118,12 @@ Dependent statements: -dep_bool/prompt/ /symbol/ /dep/ ... -dep_mbool /prompt/ /symbol/ /dep/ ... -dep_hex /prompt/ /symbol/ /word/ /dep/ ... -dep_int /prompt/ /symbol/ /word/ /dep/ ... -dep_string /prompt/ /symbol/ /word/ /dep/ ... -dep_tristate/prompt/ /symbol/ /dep/ ... +dep_bool/prompt/ /symbol/ /dep/ +dep_mbool /prompt/ /symbol/ /dep/ +dep_hex /prompt/ /symbol/ /word/ /dep/ +dep_int /prompt/ /symbol/ /word/ /dep/ +dep_string /prompt/ /symbol/ /word/ /dep/ +dep_tristate/prompt/ /symbol/ /dep/ Unset statement: @@ -132,7 +134,22 @@ choice /prompt/ /word/ /word/ nchoice /prompt/ /symbol/ /prompt/ /symbol/ ... -If statements: +New-style if blocks: + +if_dep /dep/ + /statement/ + ... +fi_dep + +if_dep /dep/ + /statement/ + ... +else_dep + /statement/ + ... +fi_dep + +Old-style if blocks (deprecated): if [ /expr/ ] ; then /statement/ @@ -161,6 +178,69 @@ +=== Dependency lists + +A dependency list evaluates to a single character y, m or n. +Individual words in the list can include: + +The word or divides a list into two sub-lists, one on either +side of the or. The sub-lists are evaluated independently and +then combined, as described below. + +A /symbol/ is expanded to the current value of the symbol, or the +empty string if the symbol is unset. In the latter case, if +/symbol/ appears in a word by itself, the word is ignored. This +is for backward compatibility and may change in the future. + +If a /symbol/ has a $ prefix, that prefix is ignored, for +backward compatibility. This may become a syntax error in the +future. + +A word with a suffix of =X, where X is a quoted or unquoted +string, expands to y if the rest of the word evaluates to X, or +n otherwise. + +A word prefixed by ! expands to a transformation of the word: +!y becomes n; !n or ! become y; !m becomes m. The +! prefix is expanded only after expansion of /symbol/s and the += suffix. + +Once each word is expanded as described above, it should have a value +of y, m or n, or the empty value , which is discarded. If the +dependency list has multiple words, the words are reduced to a single +word as follows: + +If any word is n, the value of the list becomes n. + +Otherwise, if any word is m, the value of the list becomes m. + +Otherwise, the value of the list becomes y. + +If there are multiple sub-lists separated by or words, each sub-list +is reduced to a single word as described above, then they are combined +as follows: + + If any sub-list is y, the final result is y. + + Otherwise, if any sub-list is m, the final result is m. + + Otherwise, if all sub-lists are n, the final result is n. + +Finally, an empty /dep/ evaluates to y. + +If you think in terms of Boolean algebra, most of the above rules make +sense if you think of each primitive value (y, m and n) as two +bits: y=11, m=01, n=00. Adjacent words are implicitly ANDed +together, and the or statement, with lower precedence, performs an +OR between lists of words. The ! operator does not quite fit this +explanation, because !m = m, but that was specified for practical +reasons, to cover a common
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
[Brendan J Simon]
Either if_dep, else_dep and end_dep _or ifdep, elsedep, enddep.
I like it. My original if_dep was ifdep, but I thought people would
mistake it for the common verb 'ifdef' and misspell it that way. So I
vote for the _s.
[Greg Banks]
Yes, the _s should be consistent. How about using fi instead of
end for consistency with the current scheme?
H, not sure - the point is to get *away* from shell syntax. OTOH,
somehow fi_dep *does* seem more consistent than end_dep.
else_dep() is a simple matter of reversing the polarity of the guard.
Basically:
function else_dep () {
case $nest_ifdef in
'') {{{ syntax error: else without if }}} ;;
y|m) nest_ifdef=n ;;
n) nest_ifdef=y ;;
esac
}
I suppose Bourne-feature-completeness would demand 'elif_dep' as well.
That's not hard either, but is it overkill? I know Linus hates
overengineering, and to a much lesser extent so do I.
Peter
---
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
Greg, in regards to another question you had - no I don't think there
is value in having a variant if statement that treats 'm' differently.
You can already get the same effect by using 'CONFIG_FOO=y' or
'CONFIG_FOO=m' instead of plain 'CONFIG_FOO'.
You are much better than I at finding examples of weird stuff in the
config system, though, so let me know if this doesn't cover all cases.
[I wrote]
else_dep() is a simple matter of reversing the polarity of the guard.
No it's not - I just realised that this breaks nested if_dep.
I suppose Bourne-feature-completeness would demand 'elif_dep' as
well.
I also realised that else_dep and elif_dep are exactly the same except
that else_dep doesn't take a dep line. So else_dep now does double
duty:
if_dep CONFIG_FOO
...
else_dep CONFIG_BAR
...
else_dep CONFIG_BAZ !CONFIG_XYZZY
...
else_dep
...
fi_dep
Of course if one feels uncomfortable about an empty 'else_dep' line
one can always append a dummy 'y'.
Incremental patch (lightly tested) over the one earlier in the thread:
--- 2.5.31/scripts/Menuconfig 2002-08-15 03:57:59.0 -0500
+++ 2.5.31w/scripts/Menuconfig 2002-08-15 03:55:22.0 -0500
@@ -130,7 +130,7 @@
# Use boolean transforms, or nest conditionals.
function dep_calc () {
local neg arg ordep
- if [ $nest_ifdep = n ]; then
+ if [ $nest_ifdep = n -o $nest_ifdep = x ]; then
cur_dep=n;
return 1;
fi
@@ -171,7 +171,15 @@
nest_ifdep=$cur_dep
}
-function endif () {
+function else_dep () {
+ case $nest_ifdep in
+ y | m | x) nest_ifdep=x ;;
+ n) fi_dep; if_dep $@ ;;
+ *) ;; # syntax error: else without if, or similar
+ esac
+}
+
+function fi_dep () {
nest_ifdep=${nest_stack%%' '*}
nest_stack=${nest_stack#*' '}
}
---
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
[Giacomo A. Catenazzi] I don't like calling it or... It is error prone because it is a non binary system, thus can confuse the lazy developers. I had to call it something. I for one think 'or' is quite intuitive here. If you insist that OR can only be done on binary values, think of 'y'==3 and 'm'==1. Better min. You mean max. min would in this case be a logical AND. But nobody thinks of max as an infix operator, and infix is IMO the most natural way to express a low-precedence operator without explicit grouping. Also I don't like the construct if_dep that parse multiple lines. IMHO better a single line statment: if_dep ..cond.. then ..cml1_statment.. My goal here is to replace the current 'if' statement. I think the current syntax is ugly and looks too much like Bourne shell (which of course is not a coincidence). As such, a multi-line construct is necessary. There are some passages of kernel Config.in files that have 20 or 30 lines under a single conditional. Changing those to be line-by-line is not really an option. Peter --- 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
[Kai Germaschewski] 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. I accept that it is not pretty. But unless we can switch to mconfig or gcml2 or some other static parser for everything, we will need shell-parsable syntax. And I submit that the current pseudo-shell syntax using if [ ] is quite a bit uglier and less intuitive. The shell-syntax if [ ] might seem intuitive at first glance, if you already know the Bourne shell, but that leads you into the trap that you can use *any* Bourne shell syntax there, which of course you can't. For example, someone might try the following: if [ $CONFIG_FOO = y ] || [ $CONFIG_BAR = y ]; then or perhaps, being ksh wizards, they think they can use if [[ $CONFIG_FOO = y || $CONFIG_BAR = y ]]; then Oops. By using *exactly* the same syntax for dep_* and if_dep, I hope to *reduce* the confusion of exactly what functionality is or is not available. Currently we have a *completely arbitrary* subset of Bourne shell and /bin/test, which is Not Good. It is also, I believe, easier to implement a static parser for my 'if' replacement, since the dependency line bit can share common code. My Menuconfig patch illustrates this. 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). Note that the 'if_dep' statement is effectively boolean anyway, so the dependency line gets implicitly cast to bool, just as with dep_mbool. So the fact that 'm' is distinct from 'y' is really only important for dep_bool and dep_tristate. If people want to avoid using ! or 'or' or the '=x' suffix in dep_bool and dep_tristate lines - well, they've been getting along fine without them for years. This is similar to the fact that you can mix and match '-o' and '-a' in our current if statements, but the precedence rules are unclear, so nobody ever actually does it. We use nested 'if' statements instead. As for the ! operator, I originally suggested that !m==n, but it was pointed out to me that !m==m is more practical, since it corresponds to a common case in config code. In these Boolean relations there is more than one truth value - but note that the same is true in C. !!x does not in general yield x, and I don't think this confuses most people. 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. It's the cleanest syntax I can come up with - including the status quo, which if you didn't know it was supposed to be an imitation of Bourne shell, would look completely bizarre. Perhaps you prefer the status quo, for the simple reason that if we have to have something ugly it may as well be a *familiar* ugliness. That is a vald argument, though I disagree with it. Or do you have an alternative new syntax to propose? 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. I don't follow. What do you mean by real tristates for $CONFIG_? 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. Once again, we're comparing the above against if [ $CONFIG_X86 = y -o $CONFIG_X86_64 = y -o \ $CONFIG_IA64 = y ]; then bool 'ACPI support' CONFIG_ACPI fi if [ $CONFIG_SOUND = y -o $CONFIG_SOUND = m ]; then if [ $CONFIG_SOUND_ALSA != y -a $CONFIG_SOUND_ALSA != m ]; then source sound/oss/Config.in fi fi 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. If we can get mconfig or similar into the standard kernel and displace Configure and Menuconfig, we'll certainly have a lot more options. I agree that it would be nice to drop the requirement for shell parsing. I just don't know if it's a realistic goal, especially before 2.6. Peter --- 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]
Re: [kbuild-devel] RFC: kernel config: new dependency syntax
[Greg Banks]
I was thinking that with your proposed syntax we'd have a large
level of compatibility in both syntax and semantics between if_dep
and dep_bool, much more so than with if and dep_bool
As you said the other day, This is not a coincidence. (:
But technically, if_dep corresponds to dep_mbool, not dep_bool.
so people would be tempted to start moving code between them,
e.g. changing backwards and forwards between
if_dep CONFIG_EXPERIMENTAL
bool 'foo' CONFIG_FOO
fi_dep
...and...
dep_bool 'foo' CONFIG_FOO CONFIG_EXPERIMENTAL
Since CONFIG_EXPERIMENTAL is itself a bool, the ambiguity doesn't come
up. But I see your point.
if_dep interprets both 'y' and 'm' as True, just as dep_mbool does. I
considered having 'm' mean False, but in the real world I think
dep_mbool is more useful than dep_bool.
If you really want dep_bool semantics you can still get them:
if_dep CONFIG_EXPERIMENTAL=y
bool 'foo' CONFIG_FOO
fi_dep
It is my opinion that most people outside the kbuild-devel list
probably do not understand the difference between dep_bool and
dep_mbool, or if they do understand, they probably do not know for
sure which is which, without looking it up. I don't want to impose
the same learning curve on if_dep. Really, dep_mbool usually *is*
what you want, since it is typically used for sub-features of things
that can be modules.
Yes, you need a condition stack and the else inverts only the top of the
stack. GCML2 does something like this.
Yep, that's basically what I did, except that my stack is cumulative
so the 'else' has to handle that.
I don't see any value to adding an else-if ability. Like parentheses in
if_dep expressions, it's more complexity than is justified by the logic.
You're probably right. It was just that, since an empty dependency
line evaluates to y, the syntax for elif falls out pretty much for
free. User perception of total complexity is not free, though, so
I'll probably drop it.
Here's an interesting idea which could be powerful but might, once
again, cause too much confusion to be practical: what about an if_dep
variant that has the power to restrict the entire block to {m,n}?
This is the analogue of dep_tristate, and is something the current
if-statement can't do. If set to 'm', it would *not* affect dep_mbool
statements inside the block, but it *would* disable bool and dep_bool,
and restict tristate / dep_tristate to {m,n}.
This would enable some serious cleanup in e.g. drivers/scsi/Config.in,
where almost every line is individually dependent on CONFIG_SCSI. The
more I think about it, the more useful this starts to sound.
Peter
---
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
[John Alvord] I've been puzzling about this problem and the CML2 trainwreck. Maybe we can used advanced tools to remove the many bugs and inconsistancies and then switch to a better config tool. That's exactly what we're trying to do. Greg has the advanced consistency checking, and I've been trying to remove ambiguities and warts in the current rule corpus, and simultaneously come up with some extensions to the current language that will let us remove *more* warts. The extensions are designed to completely supplant certain existing constructs which I consider ugly and difficult to parse. To paraphrase Orwell: it was intended that when Newspeak had been adopted once and for all and Oldspeak forgotten, a buggy parser should be literally unimplementable, at least so far as implementation is dependent on clear syntax and reasonable semantics. Peter --- 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] Get rid of shell based Config.in parsers?
[Sam Ravnborg] Where comes the requirement that we shall keep the existing shell based config parsers? I don't make that argument - mconfig is the superior solution by far - but it is certainly the path of least resistance. As pertains to CONFIG_EXPERIMENTAL and (EXPERIMENTAL), it *is* possible to add such a feature to the shell-based parsers by changing the syntax slightly - specifically to lose the '$' on dependencies. Changing the syntax *does* have ramifications when it means adapting three separate parsers, but it can be done. Remembering the CML2 war there were no serious objections about shifting away from shell based parsers (but certainly a lot about the alternative selected). It would have been a big change and a big flag day, and among other problems, the rulebase conversion issue was handled wrong. Eric refused to start from a 1-1 equivalent rulebase, preferring to tweak the rulebase as he went along - partly just to fix bugs, partly to show off his new capabilities. Unfortunately, without the apples-to-apples comparison, many people distrusted the new system, superior though it was in many ways. This is the primary lesson to be learned from CML2. Anyone trying to redesign a subsystem such as the kernel config system needs to keep it in mind. (Yes, I know from the rest of your message that you learned it.) Peter --- 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] [patch] remove duplicated AGP Config.in
drivers/char/Config.in still has a complete copy of agp/Config.in. It's an exact cut-n-paste - the md5sums even match. (: --- 2.5.31/drivers/char/Config.in~ 2002-08-08 22:43:28.0 -0500 +++ 2.5.31/drivers/char/Config.in 2002-08-14 17:25:20.0 -0500 @@ -173,21 +173,7 @@ fi endmenu -dep_tristate '/dev/agpgart (AGP Support)' CONFIG_AGP $CONFIG_DRM_AGP -if [ $CONFIG_AGP != n ]; then - bool ' Intel 440LX/BX/GX and I815/I820/I830M/I830MP/I840/I845/I850/I860 support' CONFIG_AGP_INTEL - bool ' Intel I810/I815/I830M (on-board) support' CONFIG_AGP_I810 - bool ' VIA chipset support' CONFIG_AGP_VIA - bool ' AMD Irongate, 761, and 762 support' CONFIG_AGP_AMD - bool ' Generic SiS support' CONFIG_AGP_SIS - bool ' ALI chipset support' CONFIG_AGP_ALI - bool ' Serverworks LE/HE support' CONFIG_AGP_SWORKS - if [ $CONFIG_IA64 = y ]; then - bool ' Intel 460GX support' CONFIG_AGP_I460 - bool ' HP ZX1 AGP support' CONFIG_AGP_HP_ZX1 - fi -fi - +source drivers/char/agp/Config.in source drivers/char/drm/Config.in if [ $CONFIG_HOTPLUG = y -a $CONFIG_PCMCIA != n ]; then --- 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] RFC: kernel config: new dependency syntax
[I wrote]
Mutating the language, long-term, so that it looks less like sh and
more like a specialised language, is IMO a worthy goal. And I think
it can be done. The main thing to deal with is adding an
alternative syntax for 'if' statements which doesn't look like
test(1). More about that in a separate message.
I've come up with syntax I think I'm happy with. It supports most of
the current [ ] based if statement semantics, can be implemented in
shell, and (most importantly for me) drops those $ signs. This lays
the groundwork for stuff like better error checking and auto
(EXPERIMENTAL) tags.
I made a proof-of-concept patch for Menuconfig. The Configure patch
would be very similar; God only knows what xconfig or mconfig would
require.
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
If the dependency line evaluates to 'm' or 'y', the body is executed.
Now with our current dep_* syntax, this isn't very powerful. I've
made a few extensions which are, I believe, almost enough[*] to
displace the current use of test(1)-based 'if' statements. Some of
this syntax is not really needed for dep_* lines, but I *really* like
having a single backend function for all of dep_bool, dep_tristate and
if_dep.
[*] almost enough because I haven't implemented an 'else'
directive. It would be trivial, but I'm not sure what to call it.
'else' itself is a shell primitive, so the shell-based parsers
(Configure, Menuconfig) wouldn't like it.
* '$CONFIG_FOO' can and should be replaced with 'CONFIG_FOO' without
the $. My current patch accepts both; eventually we might drop
backwards compatibility.
* !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
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
dep_tristate 'Adaptec (new driver)' CONFIG_AIC7XXX_NEW !CONFIG_AIC7XXX_OLD
dep_tristate 'Adaptec (old driver)' CONFIG_AIC7XXX_OLD !CONFIG_AIC7XXX_NEW
The one thing I wanted to specify but didn't is an 'else' statement.
The problem is that I can't think what to call it - can't use 'else'
because the shell-based parsers (Configure, Menuconfig) will choke on
it. Any ideas?
Any other comments? Am I going in totally the wrong direction?
Peter
--- 2.5.31/scripts/Menuconfig 2002-06-09 00:27:32.0 -0500
+++ 2.5.31w/scripts/Menuconfig 2002-08-14 21:00:27.0 -0500
@@ -73,7 +73,10 @@
# - Support for multiple conditions in dep_tristate().
# - Implemented new functions: define_tristate(), define_int(), define_hex(),
# define_string(), dep_bool().
-#
+#
+# 14 Aug 2002, Peter Samuelson [EMAIL PROTECTED]
+# - add lots of new syntax for dependencies in 'dep_*' functions
+# - also use this syntax for a new 'if_dep' / 'endif' primitive
#
@@ -112,6 +115,67 @@
eval info=\$INFO_$1
}
+
+# Reduce a dependency line down to a single char [ymn].
+# Terms are implicitly ANDed together: 'y m' = 'm y' = m, '... n' = 'n ...' = n
+# Each term can be:
+# 'y', 'm', 'n' interpreted as-is
+# 'CONFIG_FOO' reduces to value of CONFIG_FOO, or 'n' if unset
+# 'or' OR operator, lower precedence than the implicit AND
+# specifics: 'y or ...' = '... or y' = y
+# if no 'y': 'm or ...' = '... or m' = m
+# term=value tested for equality, replaced with 'y' or 'n'
+# !term negate value of term: y-n, n-y, m-m, ''-y
+# Note that there is no grouping construct.
+# Use boolean transforms, or nest conditionals.
+function dep_calc () {
+ local neg arg ordep
+ if [ $nest_ifdep = n ]; then
+ cur_dep=n;
+ return 1;
+ fi
+ ordep=n
+ cur_dep=y # return value
+ for arg; do
+ neg=;
+ case $arg in
+ or)
+ case $ordep in
+ n) ordep=$cur_dep ;;
+ m) [ $cur_dep = y ] ordep=y ;;
+ esac
+ cur_dep=y; continue
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
[Greg Banks] + dep_tristate ' I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C Are you sure want this one there? I didn't like it either, but it's needed in a couple odd places. What would you suggest - moving the whole i2c menu up? Not all the way up to the new menu, but before the bits that depend on them, which are in drivers/video/ drivers/media/video and drivers/ieee1394 IIRC. It should be possible to take I2C back out of init/Config.in, in that case. I'll do that in my tree. +2 CONFIG_KMOD +2 CONFIG_MODULES +2 CONFIG_MODVERSIONS 2 CONFIG_RTC What does that mean? All I did there was to combine two toplevel menus into one. Did this do something bad? Apparently. In the stock kernel: warning:arch/mips/config.in:224:CONFIG_KMOD has overlapping definitions warning:init/Config.in:19:location of previous definition warning:arch/parisc/config.in:53:CONFIG_KMOD has overlapping definitions warning:init/Config.in:19:location of previous definition Weird. These should have triggered all along - any idea why they didn't? Well, they're fixed in my tree. It looks [trivial], but this one makes me uneasy. I mean, it's such an obvious bug - the toplevel Loadable module support menu appears twice - that I almost think it was somehow intentional. Did I mention Gordian knot? Yes, I believe you did. Does that make ESR Alexander the Great? (: OK, I see CONFIG_USB in arch/cris/drivers/Config.in - is there another instance I'm missing? There's two in the same file, lines 185 and 189. Right - they're mutually exclusive, so I thought it might only count as one. Anyway, fixed in my tree. related to config.in's using the same banner for a menu and a comment. mainmenu_option next_comment ... now *there's* a bit of syntax that needs to change. Even config-language.txt agrees. Peter --- 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
[Greg Banks]
Ok, here it is.
Thanks again. It will take some time to double-check what I termed
the false positives, but now you've reduced the interesting cases
down to 30 symbols.
(BTW, the format is great - I can use 'M-x compile' and 'M-x
next-error' and Emacs pulls up files and lines for me.)
Here are the problem cases - things known to break with my proposed
'n'=='' - and my proposed solutions. I'll see if I can roll a patch
later today:
CONFIG_SCSI should be defined earlier, like in the Block Devices
menu. Then again, 'sg' is not a block device so this isn't strictly
correct. Perhaps a kernel subsystems submenu under general setup,
or even as a toplevel menu.
CONFIG_I2C and CONFIG_USB are also widely used outside their own
subtrees. They should probably go in with the kernel subsystems
menu along with CONFIG_SCSI.
CONFIG_PROC_FS is needed by ISDN hysdn. That's actually in my opinion
more of a general kernel facility than a filesystem. Eh?
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?
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?
CONFIG_SOUND_ACI_MIXER - the miroSOUND radio driver wants something
from OSS sound. Really I think sound/Config.in Sound Card Support
should be moved to a sub-menu of drivers/media/Config.in Multimedia
Devices.
CONFIG_INPUT - arch/{alpha,mips,mips64}/config.in are broken. There's
a comment in other arch/*/config.in files to the effect that
drivers/input/Config.in must come before drivers/usb/input/Config.in.
These 3 explicitly do the opposite.
CONFIG_SOUND_GAMEPORT - defined in drivers/input/gameport/, used only
in sound/oss/. I'm not sure what's going on here - why a separate
define (there is also CONFIG_GAMEPORT), and why do some sound cards
require its presence? Also I'm a bit suspicious of the logic in
drivers/input/gameport/ - it's either buggy, or way too clever.
This one is just confusing. Not sure what to recommend. I'll
probably have to stare at the Makefiles and the C for awhile to see
what's actually going on.
---
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
[Sam Ravnborg] How about extending the language (side effect) to automagically append (EXPERIMENTAL) or (OBSOLETE) to the menu line, if dependent on those special tags? I've thought about that too. Menuconfig already has magic code to append ' (NEW)' if it hasn't seen a symbol before. Your proposed change, however, cannot be easily parsed until we make '$' optional (and deprecated) in dep_* tags. The existing Configure and Menuconfig borrow the /bin/sh parser which, if allowed to see $CONFIG_EXPERIMENTAL, will expand it too early to be of use. Peter --- 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
[Kai Germaschewski] 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. Yes. That's my current plan. 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. Ugly - I'd rather not have to do it that way. (: 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) sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any case it is not hard to support both syntaxes - once the transition is complete, or reasonably complete, we can change the semantics to 'n'=='', which in Configure/Menuconfig can only be enforced in the non-$ case (well, unless we use your 'source' statement idea). 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. The problem with intuitive for people who know sh is that people think Config.in *is* shell. They start putting in constructs which are not valid Config.in syntax but which *are* valid sh syntax, so they work with certain parsers but not others. Mutating the language, long-term, so that it looks less like sh and more like a specialised language, is IMO a worthy goal. And I think it can be done. The main thing to deal with is adding an alternative syntax for 'if' statements which doesn't look like test(1). More about that in a separate message. 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 ] See above - 'if' is due for an overhaul as well. o whatever we do, having a nice way to handle two exclusive drivers would be nice You mean the case where A=y implies B=n B=y implies A=n A=m implies B=m B=m implies A=m I agree. Not sure if it needs special casing or just better general facilities. I think it can be well served by the dep_* !CONFIG_FOO patch, where !y==n, !n==y, !==y, and !m==m. Then dep_tristate CONFIG_A !CONFIG_B dep_tristate CONFIG_B !CONFIG_A Peter --- 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
[I wrote] sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any case it is not hard to support both syntaxes - once the transition is complete, [Greg Banks] Does complete mean all the ports have also made the change and been merged back? Either that, or, Linus gets tired of seeing mixed syntax in his tree, does the 'sed' himself, and removes the compatibility parsing. Linus has never been afraid to force the hand of a port maintainer. Remember what happened to the old-style Rules.make syntax just before 2.4 went gold. Actually I suspect it would be more like the C99 thing: after the new syntax is added, we start doing [TRIVIAL] patches to clean out the old, and eventually once that is done we have the option of removing the old syntax or leaving it in as a known oddity. I'd favor removing it, but people who maintain exarboralities for both 2.4 and 2.6 would not thank me. I don't think it's good policy to have the $ and non-$ cases behaving differently if we can avoid it. A good reason to excise the $ case from the tree at first opportunity. Sure, it would cause complaints from people getting too many .rejs from personal trees. But dang it, it's just one line of sed. (Or 'ed' / 'perl -wpi' for in situ editing, depending on whether or not you're Al Viro.) I'm more concerned about subtle dependencies on execution order resulting from misuse of conditionals. Yeah, that's the real reason 'n'!='' is Considered Harmful (and warned about in the docs even now). Peter --- 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
[Greg Banks] define_bool CONFIG_QUUX y bool 'Set this symbol to ON' CONFIG_FOO if [ $CONFIG_FOO = y ]; then bool 'Here QUUX is a query symbol' CONFIG_QUUX fi It's (somewhat) well-known that things tend to fly apart when you try to redefine a symbol. I don't see it documented, but I suppose it should be. In any case, you're supposed to use else - see the example in config-language.txt under === define_hex. Peter --- 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
[Greg Banks] [I wrote] (BTW, the format is great - I can use 'M-x compile' and 'M-x next-error' and Emacs pulls up files and lines for me.) This is not a coincidence. Indeed not - if you hadn't already used that format I would have munged it. Grew up on gcc, so this is my favorite error message format. Yours too, I guess. (: CONFIG_SCSI should be defined earlier, like in the Block Devices menu. Then again, 'sg' is not a block device so this isn't strictly correct. Perhaps a kernel subsystems submenu under general setup, or even as a toplevel menu. Sounds like a good idea. You could put CONFIG_SERIAL and CONFIG_PCMCIA in there too. CONFIG_SERIAL and CONFIG_PCMCIA didn't generate any noise, though. Minimum necessary change and all that. It's easy enough to add later, if desired. Here's a start. It looks a little hacky but it does fix real issues. I decided to combine general setup, module config and major subsystems - the latter needs to come after modules but really belongs with general setup. Eh? I think the first patch belongs on trivial@rustcorp - what's the protocol there, just an email cc? Attach or inline? etc. Peter diff -urNXxpk 2.5.31/arch/alpha/config.in 2.5.31-1/arch/alpha/config.in --- 2.5.31/arch/alpha/config.in 2002-08-11 15:08:07.0 -0500 +++ 2.5.31-1/arch/alpha/config.in 2002-08-13 20:49:18.0 -0500 -340,6 +340,10 fi endmenu +# +# input before char - char/joystick depends on it. As does USB. +# +source drivers/input/Config.in source drivers/char/Config.in #source drivers/misc/Config.in -375,7 +379,6 endmenu source drivers/usb/Config.in -source drivers/input/Config.in source net/bluetooth/Config.in diff -urNXxpk 2.5.31/arch/mips/config.in 2.5.31-1/arch/mips/config.in --- 2.5.31/arch/mips/config.in 2002-08-11 15:08:07.0 -0500 +++ 2.5.31-1/arch/mips/config.in2002-08-13 20:48:35.0 -0500 -400,6 +400,10 fi endmenu +# +# input before char - char/joystick depends on it. As does USB. +# +source drivers/input/Config.in source drivers/char/Config.in source drivers/media/Config.in -485,7 +489,6 fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -urNXxpk 2.5.31/arch/mips64/config.in 2.5.31-1/arch/mips64/config.in --- 2.5.31/arch/mips64/config.in2002-08-11 15:08:07.0 -0500 +++ 2.5.31-1/arch/mips64/config.in 2002-08-13 20:49:00.0 -0500 -191,6 +191,10 fi endmenu +# +# input before char - char/joystick depends on it. As does USB. +# +source drivers/input/Config.in source drivers/char/Config.in #source drivers/misc/Config.in -232,7 +236,6 fi source drivers/usb/Config.in -source drivers/input/Config.in mainmenu_option next_comment comment 'Kernel hacking' diff -urNXxpk 2.5.31-1/arch/alpha/config.in 2.5.31-2/arch/alpha/config.in --- 2.5.31-1/arch/alpha/config.in 2002-08-13 20:49:18.0 -0500 +++ 2.5.31-2/arch/alpha/config.in 2002-08-13 22:07:23.0 -0500 -299,15 +299,12 fi endmenu -mainmenu_option next_comment -comment 'SCSI support' - -tristate 'SCSI support' CONFIG_SCSI - if [ $CONFIG_SCSI != n ]; then + mainmenu_option next_comment + comment 'SCSI support' source drivers/scsi/Config.in + endmenu fi -endmenu if [ $CONFIG_PCI = y ]; then source drivers/message/fusion/Config.in diff -urNXxpk 2.5.31-1/arch/arm/config.in 2.5.31-2/arch/arm/config.in --- 2.5.31-1/arch/arm/config.in 2002-08-11 15:08:07.0 -0500 +++ 2.5.31-2/arch/arm/config.in 2002-08-13 22:07:42.0 -0500 -559,15 +559,12 fi endmenu -mainmenu_option next_comment -comment 'SCSI support' - -tristate 'SCSI support' CONFIG_SCSI - if [ $CONFIG_SCSI != n ]; then + mainmenu_option next_comment + comment 'SCSI support' source drivers/scsi/Config.in + endmenu fi -endmenu if [ $CONFIG_ARCH_CLPS711X = y ]; then source drivers/ssi/Config.in diff -urNXxpk 2.5.31-1/arch/cris/config.in 2.5.31-2/arch/cris/config.in --- 2.5.31-1/arch/cris/config.in2002-07-27 04:14:32.0 -0500 +++ 2.5.31-2/arch/cris/config.in2002-08-13 22:08:01.0 -0500 -153,15 +153,12 fi endmenu -mainmenu_option next_comment -comment 'SCSI support' - -tristate 'SCSI support' CONFIG_SCSI - if [ $CONFIG_SCSI != n ]; then + mainmenu_option next_comment + comment 'SCSI support' source drivers/scsi/Config.in + endmenu fi -endmenu source drivers/ieee1394/Config.in diff -urNXxpk 2.5.31-1/arch/i386/config.in 2.5.31-2/arch/i386/config.in --- 2.5.31-1/arch/i386/config.in2002-08-11 15:08:07.0 -0500 +++ 2.5.31-2/arch/i386/config.in2002-08-13 22:05:49.0 -0500 -311,15 +311,12 fi endmenu -mainmenu_option next_comment -comment 'SCSI device support' - -tristate 'SCSI device support' CONFIG_SCSI - if [ $CONFIG_SCSI != n ]; then + mainmenu_option next_comment + comment 'SCSI device support' source
[kbuild-devel] [patch] kernel config 3/N - move sound into drivers/media
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. 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. diff -urNXxpk 2.5.31-2/arch/alpha/config.in 2.5.31w/arch/alpha/config.in --- 2.5.31-2/arch/alpha/config.in 2002-08-13 22:07:23.0 -0500 +++ 2.5.31w/arch/alpha/config.in2002-08-13 22:38:58.0 -0500 -366,15 +366,6 endmenu fi -mainmenu_option next_comment -comment 'Sound' - -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND != n ]; then - source sound/Config.in -fi -endmenu - source drivers/usb/Config.in source net/bluetooth/Config.in diff -urNXxpk 2.5.31-2/arch/arm/config.in 2.5.31w/arch/arm/config.in --- 2.5.31-2/arch/arm/config.in 2002-08-13 22:07:42.0 -0500 +++ 2.5.31w/arch/arm/config.in 2002-08-13 22:43:26.0 -0500 -630,22 +630,6 endmenu fi -if [ $CONFIG_ARCH_ACORN = y -o \ - $CONFIG_ARCH_CLPS7500 = y -o \ - $CONFIG_ARCH_TBOX = y -o \ - $CONFIG_ARCH_SHARK = y -o \ - $CONFIG_ARCH_SA1100 = y -o \ - $CONFIG_PCI = y ]; then - mainmenu_option next_comment - comment 'Sound' - - tristate 'Sound card support' CONFIG_SOUND - if [ $CONFIG_SOUND != n ]; then - source sound/Config.in - fi - endmenu -fi - source drivers/misc/Config.in source drivers/usb/Config.in diff -urNXxpk 2.5.31-2/arch/cris/config.in 2.5.31w/arch/cris/config.in --- 2.5.31-2/arch/cris/config.in2002-08-13 22:08:01.0 -0500 +++ 2.5.31w/arch/cris/config.in 2002-08-13 22:43:45.0 -0500 -205,15 +205,6 source fs/Config.in -mainmenu_option next_comment -comment 'Sound' - -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND != n ]; then - source sound/Config.in -fi -endmenu - source drivers/usb/Config.in mainmenu_option next_comment diff -urNXxpk 2.5.31-2/arch/i386/config.in 2.5.31w/arch/i386/config.in --- 2.5.31-2/arch/i386/config.in2002-08-13 22:05:49.0 -0500 +++ 2.5.31w/arch/i386/config.in 2002-08-13 23:06:04.0 -0500 -385,15 +385,6 endmenu fi -mainmenu_option next_comment -comment 'Sound' - -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND != n ]; then - source sound/Config.in -fi -endmenu - source drivers/usb/Config.in source net/bluetooth/Config.in diff -urNXxpk 2.5.31-2/arch/ia64/config.in 2.5.31w/arch/ia64/config.in --- 2.5.31-2/arch/ia64/config.in2002-08-13 22:08:38.0 -0500 +++ 2.5.31w/arch/ia64/config.in 2002-08-13 22:44:28.0 -0500 -217,15 +217,6 if [ $CONFIG_IA64_HP_SIM = n ]; then -mainmenu_option next_comment -comment 'Sound' - -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND != n ]; then - source sound/Config.in -fi -endmenu - source drivers/usb/Config.in source lib/Config.in diff -urNXxpk 2.5.31-2/arch/mips/config.in 2.5.31w/arch/mips/config.in --- 2.5.31-2/arch/mips/config.in2002-08-13 22:09:54.0 -0500 +++ 2.5.31w/arch/mips/config.in 2002-08-13 22:47:58.0 -0500 -471,17 +471,6 endmenu fi -if [ $CONFIG_DECSTATION != y ]; then - mainmenu_option next_comment - comment 'Sound' - - tristate 'Sound card support' CONFIG_SOUND - if [ $CONFIG_SOUND != n ]; then - source sound/Config.in - fi - endmenu -fi - if [ $CONFIG_SGI_IP22 = y ]; then source drivers/sgi/Config.in fi diff -urNXxpk 2.5.31-2/arch/mips64/config.in 2.5.31w/arch/mips64/config.in --- 2.5.31-2/arch/mips64/config.in 2002-08-13 22:10:16.0 -0500 +++ 2.5.31w/arch/mips64/config.in 2002-08-13 22:48:17.0 -0500 -219,15 +219,6 define_bool CONFIG_KCORE_ELF y fi -mainmenu_option next_comment -comment 'Sound' - -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND != n ]; then - source sound/Config.in -fi -endmenu - if [ $CONFIG_SGI_IP22 = y ]; then source drivers/sgi/Config.in fi diff -urNXxpk 2.5.31-2/arch/ppc/config.in 2.5.31w/arch/ppc/config.in --- 2.5.31-2/arch/ppc/config.in 2002-08-13 22:14:09.0 -0500 +++ 2.5.31w/arch/ppc/config.in 2002-08-13 22:54:57.0 -0500 -558,15 +558,6 source fs/Config.in -mainmenu_option next_comment -comment 'Sound' -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND != n ]; then - source sound/oss/dmasound/Config.in - source sound/Config.in -fi -endmenu - if [ $CONFIG_8xx = y ]; then source arch/ppc/8xx_io/Config.in fi diff -urNXxpk 2.5.31-2/arch/ppc64/config.in 2.5.31w/arch/ppc64/config.in --- 2.5.31-2/arch/ppc64/config.in 2002-08-13 22:14:24.0 -0500 +++ 2.5.31w/arch/ppc64/config.in2002-08-13 22:56:14.0 -0500 -197,15 +197,6 source fs/Config.in -mainmenu_option next_comment -comment 'Sound' -tristate 'Sound card support' CONFIG_SOUND -if [ $CONFIG_SOUND
[kbuild-devel] Re: [patch] kernel config 3/N - move sound into drivers/media
[I 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. [Kai Germaschewski] Hmmh, makes sense to me, but there will probably be people complaining sound config has disappeared for me ;) You are probably right. I still think it's the right thing to do. (: I do *not* like the recent proliferation of toplevel menu entries. Well, I think that's okay, but you should check back with _rmk_. True. The trouble with this sort of work is that you *have* to touch all the architectures, and sometimes change the behavior somewhat. That can mean stepping on toes now and then. 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. I thought about that - but didn't want to re-indent the whole file. I hate doing that. (: Also, there's a *reason* every arch has a separate config.in file - for maximum flexibility without putting lots of ifdefs in common code. To a certain extent I agree with you and I wish it were possible to eliminate the arch/*/config.in entirely, but it's not. ESR tried it with CML2 and was slapped down by Linus himself, as I recall. I don't want my humble efforts to end up the same way CML2 did. For that reason I'm trying very hard to make only small, incremental, obvious changes. Perhaps I'm a bit *too* timid. 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. What we need is an easy way to check for any arch. CONFIG_ARCH_S390 is the right idea (though s390x sets it as well, not sure if that's good or bad). Then again, such checks polluting the common code is exactly what the current system (with all its cut/paste code in arch/*/config.in) is supposed to prevent. Perhaps The Powers That Be like the status quo. 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. H ... I didn't see any clean way to keep the arm test. Thinking about it some more, I suppose one could do if [ $CONFIG_ARM = y ]; then if [ ... ]; then tristate CONFIG_SOUND fi else tristate CONFIG_SOUND fi It's still not pretty, but should work. I think I'll put that in drivers/media/Config.in. 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 ;) I'd been avoiding Config.help - I was afraid if I looked in it I would find entries I would have to move from one dir to another. (: I have no strong opinion either way, but I'd certainly like a drivers/Config.in. Agreed. 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 ;) Sorry about that - I agree. I only attached patches when I had more than one for a single mail, and then I forgot to switch back. Must recompile self with -finline-patches Peter --- 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
[I wrote] This stuff is trivial enough, and easy enough to test, that I think it could go in 2.4, yes. [Greg Banks] I think you're underestimating the Gordian knot that is the CML1 corpus. Yes, very possibly. 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. Thank you! That's what I wanted to know. I had no idea there existed this class of bug (yes it's a bug). I don't know why I should be surprised, since the 17 architectures all have separately-maintained config.in files, most of which were written by porting gurus, not 'make config' gurus. That one example is more than enough to convince me *not* to try changing the ignore empty deps rule for 2.4. 2.5 is a different matter, though.. In fact this is the first one gcml2 finds, I don't particularly feel like trawling through the other two hundred-odd. Some of them are harmless, I don't know how many. This is like the Stanford checker stuff. These are bugs. You have the means to find them automatically, but not the time or desire to fix them. Post a list and perhaps others will pitch in. Something like drivers/ide/Config.in:17: In dep_tristate CONFIG_BLK_DEV_IDESCSI: drivers/ide/Config.in:17: CONFIG_SCSI not defined for i386, ppc, ... In this case the fix would be to move CONFIG_BLK_DEV_IDESCSI to the SCSI subsystem, where in my opinion it belonged anyway. This would break down if there are any actual cycles - things which can't logically be moved to a place after the definitions of the facilities on which they depend. That we have to worry about this at all is an artifact of using a procedural langauge, rather than a declarative language like Prolog or CML2. I *really* don't want to go *there*, though. (: And != n in other contexts, like if [];then statements. That is true. But that should not affect the dep_* logic, should it? The point here is that people who aren't hip-deep in config language code don't think about them being separate. Ergo bugs. If it's your intention to change the semantics of , perhaps it would be better to add new statements which feature the new syntax and new semantics *only* and have no backwards compatibility baggage. An example of this approach is the nchoice statement, which does the same thing as choice but with a more civilized syntax. I've been thinking hard about a new sort of 'if' statement that doesn't look like a test command. (Yes, it's my mission to eventually get rid of the '$'s in config language. I think it can be done, piecemeal, over a long period of time. This is if we don't end up adopting a whole new language like CML2 or Roman's stuff.) Peter --- 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] config language dep_* enhancements
[Roman Zippel] with the latest modifications this can be written as: dep_tristate NEW !OLD dep_tristate OLD !NEW This still has the back reference and you have to run 'make config' twice to change NEW from n to y. I don't see this as a big problem. Most people don't use the bare Configure script anyway, except for 'make oldconfig'. With the ! patch, Menuconfig does the right thing here. It's possible to fix this: tristate DRV if [ DRV == y ]; then choice OLD NEW fi if [ DRV == m ]; then dep_tristate NEW DRV dep_tristate OLD DRV fi Simpler and perhaps more intuitive: tristate DRV dep_mbool DRV_OLD DRV dep_mbool COMMON_OPT DRV dep_mbool OLD_OPT1 DRV_OLD dep_mbool OLD_OPT2 DRV_OLD dep_mbool NEW_OPT1 DRV !DRV_OLD dep_mbool NEW_OPT2 DRV !DRV_OLD I don't see a real need for a separate symbol announcing DRV_NEW. Let the Makefile cope. Peter --- 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
[Greg Banks] Ah. If you're willing to knowingly feed Linus with patches that break current config behaviour, then OK we have a way to proceed. Things knowingly break in 2.5 all the time. I for one have no problem with this. Especially since the breakage is so easy to pinpoint, thanks to your script. I don't think there's any value to gratuitously breaking 2.4's config. That's the point of a stable series right? Correct. I for one have no intention of changing 2.4 semantics, except to expand them to allow '!' syntax, if I can finish that up. Ah, glad you asked, see attached output from the latest version of gcml2 (not yet released). Thank you thank you thank you! Exactly what I wanted! Now, while some (perhaps a lot) of these instances will break with the proposed new semantics, many will not. Starting from the top: =alpha warning:drivers/pcmcia/Config.in:22:forward declared symbol CONFIG_ARCH_SA1100 used in dependency list for CONFIG_PCMCIA_SA1100 In context: if [ $CONFIG_ARM = y ]; then dep_tristate ' SA1100 support' CONFIG_PCMCIA_SA1100 $CONFIG_ARCH_SA1100 $CONFIG_PCMCIA fi With the new semantics, there would be no need for the 'if' statement. CONFIG_ARCH_SA1100 is a sufficient guard, since non-ARM machines will never define it. The next 7 lines are similar, with CONFIG_PPC, CONFIG_MIPS and CONFIG_ARM as the guards. warning:drivers/block/Config.in:38:forward declared symbol CONFIG_SCSI used in dependency list for CONFIG_CISS_SCSI_TAPE This one is legit. It's a weird case where a single driver can be built with or without using the SCSI subsystem - in effect, two drivers sharing a single piece of hardware and presenting two views of it. My preferred fix is to move the 'tristate CONFIG_SCSI' to early in the Block Devices menu. ATA should be under Block Devices too, come to think of it, and perhaps a generic guard for non-IDE-non-SCSI RAID cards. The actual menus could come later under toplevel, or be nested within Block Devices. warning:drivers/ide/Config.in:21:forward declared symbol CONFIG_SCSI used in dependency list for CONFIG_BLK_DEV_IDESCSI See above. warning:drivers/ide/Config.in:84:forward declared symbol CONFIG_ARCH_ACORN used in dependency list for CONFIG_BLK_DEV_IDE_ICSIDE warning:drivers/ide/Config.in:88:forward declared symbol CONFIG_ARCH_ACORN used in dependency list for CONFIG_BLK_DEV_IDE_RAPIDE warning:drivers/ide/Config.in:91:forward declared symbol CONFIG_AMIGA used in dependency list for CONFIG_BLK_DEV_GAYLE warning:drivers/ide/Config.in:95:forward declared symbol CONFIG_ZORRO used in dependency list for CONFIG_BLK_DEV_BUDDHA warning:drivers/ide/Config.in:98:forward declared symbol CONFIG_ATARI used in dependency list for CONFIG_BLK_DEV_FALCON_IDE warning:drivers/ide/Config.in:101:forward declared symbol CONFIG_MAC used in dependency list for CONFIG_BLK_DEV_MAC_IDE warning:drivers/ide/Config.in:104:forward declared symbol CONFIG_Q40 used in dependency list for CONFIG_BLK_DEV_Q40IDE warning:drivers/ide/Config.in:107:forward declared symbol CONFIG_8xx used in dependency list for CONFIG_BLK_DEV_MPC8xx_IDE warning:drivers/net/Config.in:28:forward declared symbol CONFIG_ARCH_EBSA110 used in dependency list for CONFIG_ARM_AM79C961A warning:drivers/net/Config.in:34:forward declared symbol CONFIG_ALL_PPC used in dependency list for CONFIG_MACE warning:drivers/net/Config.in:38:forward declared symbol CONFIG_ALL_PPC used in dependency list for CONFIG_BMAC warning:drivers/net/Config.in:48:forward declared symbol CONFIG_GSC_LASI used in dependency list for CONFIG_LASI_82596 warning:drivers/net/Config.in:239:forward declared symbol CONFIG_PPC_ISERIES used in dependency list for CONFIG_VETH All obviously tied to a specific arch. Most but not all are guarded by ARCH_* symbols, but that doesn't matter - with the new semantics they work with or without extra guards. All in all, by asserting that 'n' == '', you can drop all the 'define_bool FOO n' from the arch/*/config.in files (like CONFIG_SBUS on i386 or CONFIG_PCI on s390), and you can drop a *lot* of guard 'if' statements. A few things would actually break, like not defining CONFIG_SCSI soon enough. I think it's worth it. It will take some time to go through your 260 unique warnings (984 total), of course. BTW - speaking of the length of your warnings list - what would be *really* nice would be a way to determine that a particular forward declared symbol is actually a never-in-this-arch declared symbol. That would eliminate most of the false positives. If for example we can determine that we will never define CONFIG_ZORRO on this arch, we can safely assume that anything which depends on CONFIG_ZORRO *should* be suppressed. (Modulo outright bugs where someone wrote $CONFIG_ZORRO for something that does not in fact require zorro.) Peter --- This sf.net email is sponsored by: Dice - The leading online
[kbuild-devel] Re: 64bit clean drivers was Re: Linux 2.4.20-pre1
[Peter Samuelson] !y == n !m == n !n == y [Roman Zippel] I would define !m as m, e.g. it would allow dep_tristate CONFIG_OLD !$CONFIG_NEW dep_tristate CONFIG_NEW !$CONFIG_OLD You know, that never even occurred to me. Your scheme is not strictly logical, but it is much more practical, since it is perfect for expressing a relatively common (and currently awkward) case. I'm convinced. Now we have !y == n !m == m (significant for dep_tristate and dep_mbool) !n == n BTW, does anyone have a problem with my proposal (for 2.5, not necessarily 2.4) for '/dep_/s/ \$CONFIG/ CONFIG/g' ? That is, -dep_tristate CONFIG_FOO_X CONFIG_FOO CONFIG_BAR !CONFIG_BAZ +dep_tristate CONFIG_FOO_X $CONFIG_FOO $CONFIG_BAR !$CONFIG_BAZ Advantages: - the config files are more readable, especially when using ! - can support the old syntax with no extra code and most importantly - resolves the parsing difficulty with detecting an undefined value in dep_* statements. Currently the undefined value is documented as ignored, but try to avoid the situation. which leads to - allows us to drop all those 'define_bool CONFIG_FOO n' statements whose main purpose was to avoid the empty value Eh? I posted a patch earlier; it was trivial, despite having a syntax error in Configure (deleted a 'while...do', forgot the 'done') which only proves that I don't test stuff very rigorously. Menuconfig actually shrunk, due to factoring. If and when I get my head around xconfig, we'll see how ugly this stuff does or doesn't get, but then again, if xconfig were made uglier, would anyone notice? Peter --- 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] config language dep_* enhancements
[Greg Banks]
I like the basic idea here, and I'm pleased that someone has the
courage to tackle some of the brokenness of the kconfig language (if
only because it will provide me with a precedent when I try to
submit some of my patches ;-).
Thanks for the feedback. (:
This applies to 2.4.20pre and (except changelog bits) to 2.5.30 with
offsets.
You're willing to potentially perturb 2.4?
This stuff is trivial enough, and easy enough to test, that I think it
could go in 2.4, yes. Obviously xconfig would need to be dealt with
in sync with the others, which I'm not doing during the prototyping /
idea-mongering stage.
The last statement is inconsistent with the shell code and the
explanations of the dep_* statements, which sensibly preserve the
current semantics where an undefined symbol has a distinct fourth
value which is not y, m or n.
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.
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. Can you provide a rationale for why the current
behavior is desirable? It seems to me that it only encourages buggy
Config.in code (since == n in other contexts like the #defines),
and I don't see any benefits other than that it's the status quo.
[Not to demean the status quo - in 2.4 it is probably appropriate.]
+In addition, the /dep/ may have a prefix !, which negates the
+sense of the /tristate/: !y and !m reduce to n, and !n
+reduces to y.
Perhaps negates isn't quite the right word in four-state logic.
I wasn't sure what else to call it. Besides, as explained above, it's
intended (rightly or wrongly) to be 3-state logic, where two states
represent a form of true. (:
Perhaps the /dep/ may have a prefix !, which transforms the
/tristate/ as follows: ... This is particularly appropriate in light
of Roman's argument (which I buy) in favor of !m == m.
+function dep_calc () {
+ local neg arg
+ cur_dep=y # return value
+ for arg; do
+ neg=;
+ case $arg in
+ !*) neg=N; arg=${arg#?} ;;
+ esac
+ case $arg in
+ y|m|n) ;;
+ *) arg=$(eval echo \$$arg) ;;
Don't you want to check at this point that arg starts with CONFIG_?
Also, how about quoting \$$arg ?
I suppose one could add sanity checks / diagnostics, but there are no
other valid cases, so that's all they would be. I'm not really trying
to produce a config.in 'lint' - leave that to the static parsers like
gcml2, xconfig and mconfig.
Peter
---
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] [patch] config language dep_* enhancements
:40.0 -0500
+++ 2.4.20pre1p/scripts/Configure 2002-08-08 22:31:49.0 -0500
@@ -48,6 +48,15 @@
#
# 24 January 1999, Michael Elizabeth Chastain, [EMAIL PROTECTED]
# - Improve the exit message (Jeff Ronne).
+#
+# 8 Aug 2002, Peter Samuelson [EMAIL PROTECTED]
+# for dependencies in dep_* functions:
+# - deprecate '$' (dep_bool 'foo' CONFIG_FOO CONFIG_BAR CONFIG_BAZ)
+# - allow negation:
+# dep_bool 'New Foo' CONFIG_FOO !CONFIG_OLDFOO
+# dep_bool 'Old Foo' CONFIG_OLDFOO !CONFIG_FOO
+# (Note that since the !CONFIG_OLDFOO is a forward reference, it
+# is meaningless for the line-based interface.)
#
# Make sure we're really running bash.
@@ -232,6 +241,28 @@
}
#
+# dep_calc reduces a dependency line down to a single char [ymn]
+#
+function dep_calc () {
+ local neg arg
+ cur_dep=y # return value
+ for arg; do
+ neg=;
+ case $arg in
+ !*) neg=N; arg=${arg#?} ;;
+ esac
+ case $arg in
+ y|m|n) ;;
+ *) arg=$(eval echo \$$arg) ;;
+ esac
+ case $neg$arg in
+ m) cur_dep=m ;;
+ n|Ny|Nm) cur_dep=n; return ;;
+ esac
+ done
+}
+
+#
# dep_tristate processes a tristate argument that depends upon
# another option or options. If any of the options we depend upon is a
# module, then the only allowable options are M or N. If all are Y, then
@@ -248,18 +279,16 @@
var=$2
need_module=0
shift 2
- while [ $# -gt 0 ]; do
- case $1 in
- n)
+ dep_calc $@
+ case $cur_dep in
+ n)
define_tristate $var n
return
;;
m)
need_module=1
;;
- esac
- shift
- done
+ esac
if [ $need_module = 1 ]; then
if [ $CONFIG_MODULES = y ]; then
@@ -299,15 +328,13 @@
ques=$1
var=$2
shift 2
- while [ $# -gt 0 ]; do
- case $1 in
+ dep_calc $@
+ case $cur_dep in
m | n)
define_bool $var n
return
;;
- esac
- shift
- done
+ esac
bool $ques $var
}
@@ -316,8 +343,8 @@
ques=$1
var=$2
shift 2
- while [ $# -gt 0 ]; do
- case $1 in
+ dep_calc $@
+ case $cur_dep in
n)
define_bool $var n
return
diff -urN 2.4.20pre1/scripts/Menuconfig 2.4.20pre1p/scripts/Menuconfig
--- 2.4.20pre1/scripts/Menuconfig 2002-06-14 15:09:40.0 -0500
+++ 2.4.20pre1p/scripts/Menuconfig 2002-08-08 22:32:09.0 -0500
@@ -77,8 +77,14 @@
# 12 November 2001, Keith Owens [EMAIL PROTECTED]
# Escape double quotes on eval so the quotes are still there on the second
# evaluation, required to handle strings with special characters.
-#
-
+#
+# 8 Aug 2002, Peter Samuelson [EMAIL PROTECTED]
+# for dependencies in dep_* functions:
+# - deprecate '$' (dep_bool 'foo' CONFIG_FOO CONFIG_BAR CONFIG_BAZ)
+# - allow negation:
+# dep_bool 'New Foo' CONFIG_FOO !CONFIG_OLDFOO
+# dep_bool 'Old Foo' CONFIG_OLDFOO !CONFIG_FOO
+# (Yes, forward references DTRT in Menuconfig.)
#
# Change this to TRUE if you prefer all kernel options listed
@@ -202,6 +208,28 @@
}
#
+# Reduces a dependency line down to a single char [ymn]
+#
+function dep_calc () {
+ local neg arg
+ cur_dep=y # return value
+ for arg; do
+ neg=;
+ case $arg in
+ !*) neg=N; arg=${arg#?} ;;
+ esac
+ case $arg in
+ y|m|n) ;;
+ *) arg=$(eval echo \$$arg) ;;
+ esac
+ case $neg$arg in
+ m) cur_dep=m ;;
+ n|Ny|Nm) cur_dep=n; return ;;
+ esac
+ done
+}
+
+#
# Create a tristate radiolist function which is dependent on
# another kernel configuration option.
#
@@ -216,26 +244,13 @@
function dep_tristate () {
ques=$1
var=$2
- dep=y
- shift 2
- while [ $# -gt 0 ]; do
- if [ $1 = y ]; then
- shift
- elif [ $1 = m ]; then
- dep=m
- shift
- else
- dep=n
- shift $#
- fi
- done
- if [ $dep = y ]; then
- tristate $ques $var
- elif [ $dep = m ]; then
- mod_bool $ques $var
- else
- define_tristate $var n
- fi
+ shift 2
+ dep_calc $@
+ case $cur_dep in
+ y) tristate $ques $var ;;
+ m) mod_bool $ques $var ;;
+ n) define_tristate $var n ;;
+ esac
}
#
@@ -245,41 +260,23 @@
function dep_bool () {
ques=$1
var=$2
- dep=y
shift 2
- while [ $# -gt 0 ]; do
- if [ $1 = y ]; then
- shift
- else
- dep=n
Re: [kbuild-devel] Some feedback on using kbuild
[CCs trimmed] [Sam Ravnborg] Obviously the kernel build system should work for everyone irrespective of the SCM system in use. This put at least the following demands: 1) Separate OBJ and SRC tree 2) That kbuild does not touch any files in the SRC tree Agreed. It looks like Kai is close to that point. Actually VPATH does all the work for you if you let it, though it looks as though Kai (along with kaos) is taking a more manual approach to get more control. (Come to think of it, VPATH can almost do shadow trees - though it would fail to comprehend different layers of Makefiles.) The functionality to support shadow trees are best located in an SCM tool. If the developer or group in question does not use a SCM tool - or maybe a non-coherent setup with two different SCM tools then there is a need to support this at another place. The best place is in between the kbuild and the trees managed. [Greg Banks] However in the real world we need to plan for the case where the SCM is too dumb to do this and too (ahem) precious to be fixed to do this, or even nonexistant, so we end up having to do it in kbuild. This is the same reason why we have the extraordinary complexity of autoconf and automake for usermode programs: it's regrettably necessary to deal with imperfect and unfixable platforms. Ah, but note that the Linux kernel build does *not* use autoconf or automake. Why not? Because the platform *is* seen as fixable after all. If your old, weird platform has strings.h instead of string.h - tough, you'll have to fix your platform before you compile mkdep.c or split-include.c. If you don't happen to have a perror() - tough again. We assume not only a decent ANSI C compiler - we assume a specific range of gcc versions. Etc. It no SCM tool is used then a simple script that takes all updates from one or more separate SRC trees and copy them to a common place could do it. And then afterwards we've got to untangle this mess again, completely reliably and automatically. The beauty of having proper shadow trees is that the trees are kept completely separate at all times except in the compiler. There is *no* danger of ending up sending the wrong patch to the wrong place or checking the wrong file into the wrong SCM. There is that. But if you regard cobble together a build-only source tree as the first stage of your build process, this shouldn't be a problem. [...] In some (most?) SCM systems, the checkout process on a file resets the timestamp to when it was checked in. CVS does this. Maybe there's a way to turn it off, I don't know. Huh? Not for me. It sets current time on anything *I* check out. Maybe there's a way to turn that screwy feature *on* I agree with Keith, shadow trees rock. I think they are probably the single most useful feature of kbuild 2.5. I'll have to take your word for it - I guess I'm still at Keith's early stages where he was arguing against them before seeing how useful they apparently really are. Peter --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Some feedback on using kbuild
[Greg Banks] I think the problem of Makefile bits in shadow trees is really quite difficult. Keith's solution of pre-processing Makefiles and Makefile.appends from all the shadow trees into a combined Makefile doesn't handle all the cases but is the best attempt I've seen so far. Agreed.. So now we assume BK? What's next, Python 2.1? Touché. No, my point was not that we can assume BK, but that we can assume the developer is willing to install whatever tools he needs to get the job done. I think the assumption is valid, assuming the developer has some choice in the matter - i.e., do not dictate a specific SCM or even a specific version of gcc (though there is a fairly limited range of acceptible gccs). This would be the case if the build process were simple and linear and consisted of just cobbling together a combined source tree and then building a kernel image. But in my experience it comprises a number of loops where I go back and fix simple compile errors (either my own or the latest IDE breakage from the mainline kernel) and do a partial rebuild. A solution where I have to cobble together 174 MB of kernel source every time I fix a one-line compile error is not useful. Another good point. You seem to be full of those. Anyway, the cobble together script will most likely build a symlink tree, not a whole separate copy, so you probably wouldn't have to rebuild it *every* compile. At least, if I were writing an ad hoc shadow tree preprocessor, that's how I'd do it. Then when you are just fixing one-liners, you aren't adding or removing files from the tree so you don't rebuild the link forest. Here's part of a brand new checkout: Ah, I wasn't thinking 'cvs co / export', I was thinking 'cvs update', which is sane. If you have a brand new checkout, you probably don't have a preexisting set of object files yet, so I'm not convinced that you can actually break your compile this way. (I do agree it's a design bug in cvs.) Peter --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Some feedback on using kbuild
[Sam Ravnborg]
This does not stop any attemp to make a simple wrapper that
creates and maintain a BUILD_TREE.
To check timestamps and link accordinly should not take too much
time, at least not at the second run.
[Greg Banks]
Ok, why don't you and Peter Samuelson get together, create such a thing and
we can compare it against kbuild2.5? If it's simple and a win, great!
Not sure about a win - but the following is certainly simple. It took
me 5 or 10 minutes. Perhaps there are cases it doesn't handle, but
I'm thinking it should work for most things.
TOTALLY UNTESTED, since it's intended solely as a proof of concept.
Also, I don't have any shadow trees already set up.
Peter
#!/bin/sh
# mkshadow: a hack to make a build tree from shadow source trees
#
# If something doesn't like the symlinks, replace 'ln -s' with 'ln'.
# Then you get hard links which should work anywhere, but which easily
# get out of sync with reality when you patch / edit the original
# files, depending on your editor.
if [ -z $KBUILD_SRCTREE_000 ]; then
echo no KBUILD_SRCTREE_000, nothing to do
exit 0
fi
obj=$KBUILD_OBJTREE
test -n $obj || obj=.
src=$(set | sed -ne '/^KBUILD_SRCTREE_[0-9][0-9][0-9]=/s//p')
test -n $src || src=.
cd $obj
for s in $src; do
if [ ${s#/} = $s ]; then
echo source tree '$s' is not absolute
exit 1
elif [ $(cd $s; pwd -P) = $(pwd -P) ]; then
echo source tree $(pwd -P) is also the object tree
echo this is not allowed
exit 1
fi
(cd $s; find * -type d) | xargs mkdir -p;
(cd $s;
exec find * \( -type d -exec mkdir \{} \; \) -o \
\( -type f ! -name \*.prepend ! -name \*.append -print \) ) |
while read f; do
rm -f $f;
ln -s $s/$f $f
done
done
for s in $src; do
(cd $s;
exec find * -type f -name \*.prepend ) |
while read f; do
base=${f%.prepend}
if [ -f $base ]; then mv $base $base.; else touch $base.; fi
cat $s/$f $base. $base
rm $base.
done
(cd $s;
exec find * -type f -name \*.append ) |
while read f; do
base=${f%.append}
if [ -f $base ]; then mv $base $base.; else touch $base.; fi
cat $s/$f $base. $base
rm $base.
done
done
---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Some feedback on using kbuild
[I wrote]
(cd $s; find * -type d) | xargs mkdir -p;
(cd $s;
exec find * \( -type d -exec mkdir \{} \; \) -o \
\( -type f ! -name \*.prepend ! -name \*.append -print \) ) |
while read f; do
This is redundant - the second mkdir is not needed.
Should be:
(cd $s; exec find * -type d) | xargs mkdir -p;
(cd $s;
exec find * -type f ! -name \*.prepend ! -name \*.append) |
while read f; do
Still untested,
Peter
PS - I still (unlike Sam) like Keith's kbuild2.5. I think it is a
cleaner and more flexible design than the existing makefiles. I just
don't see the need for explicit shadow tree support. (Separate src
and obj dirs are *definitely* needed, though.)
As Kai continues to hack on the existing Rules.make system, I've
changed my mind about what an unfixable mess it was. Obviously some
of its flaws were fixable after all (or some features of kbuild2.5
were mergeable after all, depending on how you look at it). I still
prefer kbuild2.5, but by a significantly smaller margin than I did
before Kai started.
---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: remove CML2 support in kbuild-25
[Dominik Brodowski] So my suggestion is that in a first step the Makefile.in in each directory could be parsed to the existing form of Makefiles[*], with the rest of the build system staying the same. This Makefile.in - Makefile (per directory) parsing could be done as first step of make bzImage in the existing kbuild-24. I was going to say that this would not work at all because the paradigms for 24 and 25 are just too different ... but then I noticed that the vast majority of makefiles in the kbuild25-common patches are not really aware of the advanced kbuild25 features. Assuming someone were willing to write a parser to handle the common functions - select(), ifsel(), expsyms(), link_subdirs(), and a few others - a lot of Makefiles could go in this way, transformed at runtime to something that uses Rules.make. Anyone want to write such a parser? You'd call it from Rules.make. The hardest part would probably be getting the vmlinux link right - kbuild25, being non-recursive, doesn't have to worry about intermediate linking of a master object file in each directory. The first thing that should be sent independently to Linus is probably the asm-offsets stuff. It is mostly independent of the makefile structure. Peter ___ 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
[kbuild-devel] Re: Makefile.in help required
[kaos] Can anybody do an up to date set of Makefile.in files for 2.4.18 and 2.5.5? Working on it ... hope to have something in a few hours, unless someone beats me to it. Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Makefile.in help required
[Peter Samuelson] I'm working on the 2.4.18 version (Keith's latest is -pre1), unless someone else gets one out first.. Done, see http://wire.cadcamlab.org/misc/kbuild/ . This was much easier than 2.5 as it didn't have ALSA. (: I will try to find time to test all this later today. Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Stattically includeing a device driver
[[EMAIL PROTECTED]] I want to know where all i have to make entries in the source code of linux so that while building the Linux kernel i can include my device driver in the kernel. There are files in many of the directories of the kernel called 'Config.in'. Find an appropriate one and add an entry for your driver. Consult the file Documentation/kbuild/config-language.txt for the formal definition of this file format, which is based on but NOT equivalent to shell syntax. 1. Where I have to write Makefile so that make utility can know to execute this Makefile. This Makefile is required for to create node. /dev/mydev Normally you do not create device files when building the kernel -- because the kernel may be (and in fact often is) built on a machine other than the target where it will run. Your best bet is to include the necessary 'mknod' command in your documentation - the help entry, or a README that the help entry refers to. You really cannot rely on any sort of post-install script running, except the module installation stuff in the main Makefile (but that's no place to put mknod commands either). 2. Where i have to put my device driver source code. Find a subdirectory under the kernel source - probably something under 'drivers'. If you only have one or two files that compile into your driver, just drop it into a directory with similar stuff. If it's several files, you may wish to create your own subdirectory, which is a bit more complicated because you have to write your own makefile instead of just adding a line or two to an existing one. 3. Where i have to make entry so that make Xconfig can have this entry so that while configuring kernel it should appear. See comment above about 'Config.in' files. Also note that if you want to provide a help text for the option, the file to do that is 'Config.help', which should be in the same directory as the Config.in you are editing. If you have trouble hacking the appropriate Config.in, Config.help and Makefile files, please post a link to your current driver and we can help you. (Since you are talking about linking the driver statically into the kernel, I know you are releasing it under the GPL anyway, as per license requirements.) More over Still where and what entier i have to make in the source file to statically include my device driver in the kernel. Depends on what type of driver. If it's a network driver, you have to add an entry to drivers/net/Space.c. For a SCSI card driver, you do something funky with including the scsi_module.c template. For most other drivers, you can just add the declaration module_init(your_init_function); and that will be called automatically during boot. You will need linux/init.h. * * * A little grepping could have told you pretty much all of the above. The source is your friend. HTH, Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: make xconfig whinges about Configure.help
[A Guy Called Tyketto] Just an FYI.. when one runs 'make xconfig', and goes to request help on a certain option given, a message comes up: Known issue. Configure.help has been split up, menuconfig and xconfig don't know this yet. If you want to fix it, feel free. It's probably not all that hard - just remember what directory you read Config.in from and look for Configure.help there. The current config tools are (it is believed) approaching the end of their lifecycle, so most of the usual suspects aren't terribly eager to hack on them in 2.5. That's probably why this isn't fixed yet. Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: kbuild for linux 2.4.x
[Brendan J Simon] OK. I saw the instructions. kbuild-2.5-2.4.17-1 says to patch against the linus-2.4.17 kernel where as kbuild-2.5-2.4.16-ppc-2 says to patch against the marcelo kernel. I did a search on google and found Marcelo's directory of kernels. Are these specially patched kernels for PPC or are they stock standard kernels. Marcelo is the official maintainer of 2.4 now. He released both 2.4.16 and 2.4.17. I'm not sure why someone would refer to the marcelo kernel except as a synonym for standard kernel. Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
[esr] * The `vitality' flag is gone from the language. Instead, the autoprober detects the type of your root filesystem and forces its symbol to Y. [Russell King] This seems like a backwards step. What's the reasoning for breaking the ability to configure the kernel for a completely different machine to the one that you're running the configuration/build on? As Eric keeps saying - autoconfigure is OPTIONAL. It is merely one way to generate a .config, not the only way. Answers including Aunt Tillies or Penelopes won't be accepted. 8) (: Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: CML2-2.1.3 is available
[esr] The version I just released does exactly that. Well, not exactly; it actually looks at fstab -- /proc/mounts gives you '/dev/root' rather than a physical device name in the root entry. /etc/fstab is hardly guaranteed to be accurate either. The kernel mounts the root device based on its command line and any pivot_root() calls you make, not based on /etc/fstab. [In practice, I imagine most people don't lie to fstab. The fsck init script would get annoyed.] But the horse's mouth, in this case, is /proc/sys/kernel/real-root-dev, a 16-bit decimal int which represents a device number in MAJOR*256+MINOR format. There *may* also the 'root=' asciiz string in /proc/cmdline, which will be a 4-digit hex number, but that is not reliable - because of pivot_root() among other things. On my system, real-root-dev gives 8453, which means /dev/hde5, which is on ide2. According to /proc/ide/ide2/config, it is a PCI device of type 105a:4d30 [Promise Ultra100], so you can derive CONFIG_BLK_DEV_PDC202XX as well as CONFIG_BLK_DEV_IDEDISK. Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: State of the new config build system
[Alan Cox]
find $TOPDIR -name *.cf -exec cat {} \; Configure.help
[Horst von Brand]
cat `find $TOPDIR -name *.cf` Configure.help #;-)
[Arnaldo Carvalho de Melo]
whatever is faster, do you have trustable benchmark numbers? ;)
Fewer forks vs. increased parallelism ... depends on the nature of your
bottlenecks, I guess, and cold vs. hot cache. Or you could have it
both ways:
find $TOPDIR -name \*.cf | xargs -n10 cat Configure.help
...where 10 is tuned by benchmarking. (:
Yes, its a joke, have a nice 2002 all!
Yeah, same from me..
Peter
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Handling boolean subsets of objects
[kaos] select_cond(CONFIG_ISDN CONFIG_ISDN_PPP slhc.o) Both configs must be selected, either as 'y' or 'm'. The first config defined how the object is compiled. I am worried that this might be confusing, some users are bound to get the config options in the wrong order. Any ideas for a less ambiguous construct? select_cond(CONFIG_ISDN slhc.o CONFIG_ISDN_PPP) In fact, you *could* overload select() for this, as long as you can differentiate between CONFIG options and targets. Come to think of it, does it really matter what order the CONFIG options come in? Isn't this more or less just like dep_tristate, which does a boolean AND of the existing options anyway (say m==1, y==3)? Peter ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
