Skip to contentSkip to conversation

linux kernel conf 0.6

DISCUSSION Roman Zippel 5 participants 15 messages Sep 16, 2002 – Oct 3, 2002

lore
Share & tools
lore
#0 lore raw

Hi,

At http://www.xs4all.nl/~zippel/lc/lkc-0.6.tar.gz you can find the latest version of the new config system. Changes this time:
- update to 2.5.35
- I included my convert script and prepare/fixup patch to convert all archs
- qconf got a split screen mode
- the save bug is fixed
- the converter mostly ignores "define_bool CONFIG_FOO n" now, they are only used for type definitions. They were only needed to keep the old config system working, but shouldn't be needed anymore, this allows to generate slightly better dependencies in the generated configs.

bye, Roman

#1 lore raw

Hi Roman, sorry if you get this twice. first mail did not show up.

I have been working on integrating lkc with kbuild. Here is the result.

Rules.make
- Added infrastructure to support host-ccprogs, in other words support tools written (partly) in c++.

scripts/lkc/Makefile*
- As kbuild does not distingush between individual objects, used for a given target, but (try to) build them all, I have found a solution where I create one Makefile for each executable. I could not see a clean way to integrate this in kbuild, and finally decided that in this special case a number of Makefiles did not hurt too much.

flex/bison
- Prepared for "_shipped" files.
Rename lex.zconf.c to lex.zconf.c_shipped etc. in the version reday to go in the kernel.

Sam

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas:

#	           ChangeSet	1.555   -> 1.556  
#	          Rules.make	1.70    -> 1.71   
#	               (new)	        -> 1.1     scripts/lkc/Makefile.qconf
#	               (new)	        -> 1.1     scripts/lkc/Makefile.conf
#	               (new)	        -> 1.1     scripts/lkc/Makefile.mconf
#	               (new)	        -> 1.1     scripts/lkc/lex.zconf.c_shipped
#	               (new)	        -> 1.1     scripts/lkc/Makefile
#	               (new)	        -> 1.1     scripts/lkc/zconf.tab.h_shipped
#	               (new)	        -> 1.1     scripts/lkc/zconf.tab.c_shipped

#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/09/19 [email protected] 1.556
# [PATCH] Adaptions to make lkc kbuild compatible
# --------------------------------------------
#

Rules.make +34 -2
diff -Nru a/Rules.make b/Rules.make
@@ -391,19 +391,51 @@
 
 quiet_cmd_host_cc_o_c = HOSTCC  $(echo_target)
 cmd_host_cc_o_c       = $(HOSTCC) -Wp,-MD,$(depfile) \
-			$(HOSTCFLAGS) $(HOST_EXTRACFLAGS) -c -o $@ $<
+			$(HOSTCFLAGS) $(HOST_EXTRACFLAGS) \
+			$(HOSTCFLAGS_$(@F)) -c -o $@ $<
 
 $(host-progs-multi-objs): %.o: %.c FORCE
 	$(call if_changed_dep,host_cc_o_c)
 
 quiet_cmd_host_cc__o  = HOSTLD  $(echo_target)
-cmd_host_cc__o        = $(HOSTCC) $(HOSTLDFLAGS) -o $@ $($@-objs) \
+cmd_host_cc__o        = $(HOSTCC) $(HOSTLDFLAGS) -o $@ $($@-objs) $($@-ccobjs) \
 			$(HOST_LOADLIBES)
 
 $(host-progs-multi): %: $(host-progs-multi-objs) FORCE
 	$(call if_changed,host_cc__o)
 
 targets += $(host-progs-single) $(host-progs-multi-objs) $(host-progs-multi) 
+
+# Compile c++ programs on the host
+# ===========================================================================
+host-ccprogs-single  := $(foreach m,$(host-ccprogs),\
+$(if $($(m)-objs),,$(if $($(m)-ccobjs),,$(m))))
+
+host-ccprogs-multi := $(foreach m,$(host-ccprogs),$(if $($(m)-objs),$(m)))
+host-ccprogs-multi += $(foreach m,$(host-ccprogs),$(if $($(m)-ccobjs),$(m)))
+host-ccprogs-multi := $(sort $(host-ccprogs-multi))
+
+host-ccprogs-multi-objs   := $(foreach m,$(host-ccprogs-multi),$($(m)-objs))
+host-ccprogs-ccmulti-objs := $(foreach m,$(host-ccprogs-multi),$($(m)-ccobjs))
+
+$(host-ccprogs-single): %: %.cc FORCE
+        $(call if_changed_dep,host_cc__c)
+
+# .c -> .o
+$(host-ccprogs-multi-objs): %.o: %.c FORCE
+	$(call if_changed_dep,host_cc_o_c)
+
+# .cc -> .o
+$(host-ccprogs-ccmulti-objs): %.o: %.cc FORCE
+	@echo '? $?'
+	$(call if_changed_dep,host_cc_o_c)
+
+$(host-ccprogs-multi): %: $(host-ccprogs-multi-objs) \
+                          $(host-ccprogs-ccmulti-objs) FORCE
+	$(call if_changed,host_cc__o)
+
+targets += $(host-ccprogs-single)     $(host-ccprogs-multi) \
+	   $(host-ccprogs-multi-objs) $(host-ccprogs-ccmulti-objs) 
 
 endif # ! modules_install
 endif # ! fastdep
scripts/lkc/Makefile new file +51 -0

51 lines not on this page · raw message

scripts/lkc/Makefile.conf new file +9 -0
diff -Nru a/scripts/lkc/Makefile.conf b/scripts/lkc/Makefile.conf
@@ -0,0 +1,9 @@
+###
+# Makefile for the conf executable, part of the lkc suite of programs
+
+host-progs := conf
+conf-objs := conf.o $(sharedobjs)
+
+all: conf
+include $(TOPDIR)/Rules.make
+
scripts/lkc/Makefile.mconf new file +9 -0
diff -Nru a/scripts/lkc/Makefile.mconf b/scripts/lkc/Makefile.mconf
@@ -0,0 +1,9 @@
+###
+# Makefile for the mconf executable, part of the lkc suite of programs.
+
+host-progs := mconf
+mconf-objs  := mconf.o $(sharedobjs)
+
+all: mconf
+include $(TOPDIR)/Rules.make
+
scripts/lkc/Makefile.qconf new file +43 -0

43 lines not on this page · raw message

#2 lore raw

Hi,

Quoted 2 lines · Sam Ravnborg

I have been working on integrating lkc with kbuild. Here is the result.

Thanks, nice work. :)

Quoted 3 lines

Rules.make
- Added infrastructure to support host-ccprogs, in other words support tools written (partly) in c++.

There are all compiled with gcc instead of g++, are you sure that will ok with all supported gcc versions?

Quoted 7 lines

scripts/lkc/Makefile*
- As kbuild does not distingush between individual objects, used for a given target, but (try to) build them all, I have found a solution where I create one Makefile for each executable. I could not see a clean way to integrate this in kbuild, and finally decided that in this special case a number of Makefiles did not hurt too much.

Here I thought about using "ifeq ($(MAKECMDGOALS),...)" to keep them in a single file. Did you try something like this?

Quoted 4 lines

flex/bison
- Prepared for "_shipped" files.
Rename lex.zconf.c to lex.zconf.c_shipped etc. in the version reday to go in the kernel.

This works quite well for users, but it's very annoying for the developer. Kai, any chances to use md5sum for this at some point, e.g. with a helper script like this:

set -e
src=$1
dst=$2
shift 2

test -f $dst && tail -1 $dst | sed 's,/\* \(.*\) \*/,\1,' | md5sum -c && touch $dst && exit 0 echo "$@"
"$@"
echo "/* $(md5sum $src) */" >> $dst

The only problem with this script is that it only supports a single input and output file.

Something else I'd like to have for later is the ability to compile $(sharedobjs) as a shared library and install it somewhere so it can be used by external programs.

bye, Roman

#3 lore raw
Quoted 4 lines · Roman Zippel
Quoted 2 lines

I have been working on integrating lkc with kbuild. Here is the result.

Thanks, nice work. :)

Yup, I improved things a bit further.

Quoted 6 lines
Quoted 3 lines

Rules.make
- Added infrastructure to support host-ccprogs, in other words support tools written (partly) in c++.

There are all compiled with gcc instead of g++, are you sure that will ok with all supported gcc versions?

I fixed that.

Quoted 10 lines
Quoted 7 lines

scripts/lkc/Makefile*
- As kbuild does not distingush between individual objects, used for a given target, but (try to) build them all, I have found a solution where I create one Makefile for each executable. I could not see a clean way to integrate this in kbuild, and finally decided that in this special case a number of Makefiles did not hurt too much.

Here I thought about using "ifeq ($(MAKECMDGOALS),...)" to keep them in a single file. Did you try something like this?

That's now handled without obvious hacks.

Quoted 14 lines
Quoted 4 lines

flex/bison
- Prepared for "_shipped" files.
Rename lex.zconf.c to lex.zconf.c_shipped etc. in the version reday to go in the kernel.

This works quite well for users, but it's very annoying for the developer. Kai, any chances to use md5sum for this at some point, e.g. with a helper script like this:

set -e
src=$1
dst=$2
shift 2

Quoted 4 lines

test -f $dst && tail -1 $dst | sed 's,/\* \(.*\) \*/,\1,' | md5sum -c && touch $dst && exit 0 echo "$@"
"$@"
echo "/* $(md5sum $src) */" >> $dst

I'm not particularly fond of these md5sum hacks. I don't think it's all that annoying for the developer, either, it's basically just a alias make="make LKC_GENPARSER=1"

(Of course, you'll have to update the _shipped files eventually, but there isn't really any way around that either way)

One might consider setting LKC_GENPARSER based on a test if bison/flex are in the path.

Quoted 3 lines

Something else I'd like to have for later is the ability to compile $(sharedobjs) as a shared library and install it somewhere so it can be used by external programs.

Well, later ;)

--Kai

I created a combined patch with lkc-0.6, Sam's patch and my things on top of current 2.5-bk (And I would strongly suggest to make further releases like this, if people need to first figure out how to install and what to run, they won't test lkc at all). As a result, it's fairly large, so I put it on

	http://zephyr.physics.uiowa.edu/~kai/lkc/lkc-0.6-A

--Kai

#4 lore raw

One cosmetic thing I mentioned to Roman, Config.new needs to be changed to something better, like conf.in or build.conf or somesuch.

#5 lore raw
Quoted 2 lines · Jeff Garzik

One cosmetic thing I mentioned to Roman, Config.new needs to be changed to something better, like conf.in or build.conf or somesuch.

I agree. (But I'm not particularly good at coming up with names ;) build.conf is maybe not too bad considering that there may be a day where it is extended to support "<driver>.conf" as well.

One other thing I wanted to mention but forgot was that lkc now does a quiet "make oldconfig" when .config changed or does not exist, which is changed behavior.

I intentionally only printed a message and errored out in this case, and I think that's more useful, particularly for people doing

make all 2>&1 > make.log

which now may take forever waiting for input.

--Kai

#6 lore raw
Quoted 7 lines · Kai Germaschewski
Quoted 1 line · Jeff Garzik

One cosmetic thing I mentioned to Roman, Config.new needs to be changed to something better, like conf.in or build.conf or somesuch.

I agree. (But I'm not particularly good at coming up with names ;) build.conf is maybe not too bad considering that there may be a day where it is extended to support "<driver>.conf" as well.

We want to make sure the config format is extensible in case we want to add Makefile rules or some other metadata (i.e. <driver>.conf contains all config/make info needed to build a driver, just drop it in)

Quoted 2 lines

One other thing I wanted to mention but forgot was that lkc now
does a quiet "make oldconfig" when .config changed or does not exist, which is changed behavior.

Can you elaborate a bit on that? 'make oldconfig' is one of the things we want to keep working as-is... That was a downside of ESR's system. If you're saying "silent" as in, if-no-changes-occurred or defconfig-copied-as-is, that's cool...

Jeff

#7 lore raw
Quoted 22 lines · Jeff Garzik
Quoted 10 lines · Kai Germaschewski
Quoted 2 lines · Jeff Garzik

One cosmetic thing I mentioned to Roman, Config.new needs to be changed to something better, like conf.in or build.conf or somesuch.

I agree. (But I'm not particularly good at coming up with names ;) build.conf is maybe not too bad considering that there may be a day where it is extended to support "<driver>.conf" as well.

We want to make sure the config format is extensible in case we want to add Makefile rules or some other metadata (i.e. <driver>.conf contains all config/make info needed to build a driver, just drop it in)

Quoted 3 lines

One other thing I wanted to mention but forgot was that lkc now does a quiet "make oldconfig" when .config changed or does not exist, which is changed behavior.

Quoted 4 lines

Can you elaborate a bit on that? 'make oldconfig' is one of the things we want to keep working as-is... That was a downside of ESR's system. If you're saying "silent" as in, if-no-changes-occurred or defconfig-copied-as-is, that's cool...

Roman probably knows better than I do, but anyway.

AFAICS, "quiet" only means the same thing as the traditional "make oldconfig", but suppressing questions where the answers are known. (Which I think is fine)

I was just referring to the following, which really is not in the subtle change category:

-------------------------------------------------------------
[kai@zephyr linux-2.5.make]$ rm .config [kai@zephyr linux-2.5.make]$ make
***
*** You have not yet configured your kernel!
***
*** Please run some configurator (e.g. "make oldconfig" or *** "make menuconfig" or "make xconfig").
***
make: *** [.config] Error 1
-------------------------------------------------------------

whereas lkc changes this to run (the quiet) make oldconfig automatically.

Same thing for

-------------------------------------------------------------
[kai@zephyr linux-2.5.make]$ cp ../config-2.5 .config [kai@zephyr linux-2.5.make]$ make
make[1]: Entering directory /home/kai/src/kernel/v2.5/linux-2.5.make/scripts' make[1]: Leaving directory /home/kai/src/kernel/v2.5/linux-2.5.make/scripts'
***
*** You changed .config w/o running make *config? *** Please run "make oldconfig"
***
-------------------------------------------------------------

Since people run automated builds, erroring out is IMHO preferable to dropping into interactive mode, which likely happens when you run make oldconfig.

--Kai

#8 lore raw
Quoted 2 lines · Kai Germaschewski

On Sun, 22 Sep 2002, Jeff Garzik wrote:
AFAICS, "quiet" only means the same thing as the traditional "make oldconfig", but suppressing questions where the answers are known. (Which I think is fine)

yeah, that's fine with me too

Quoted 14 lines

I was just referring to the following, which really is not in the subtle change category:

-------------------------------------------------------------
[kai@zephyr linux-2.5.make]$ rm .config [kai@zephyr linux-2.5.make]$ make
***
*** You have not yet configured your kernel!
***
*** Please run some configurator (e.g. "make oldconfig" or *** "make menuconfig" or "make xconfig").
***
make: *** [.config] Error 1
-------------------------------------------------------------

Quoted 1 line

whereas lkc changes this to run (the quiet) make oldconfig automatically.

hmmmm, looks like something got broken somewhere, then.

The proper behavior for this example is
cp arch/$arch/defconfig .config

Do a 'make oldconfig' or 'make config' with no .config, in a 2.4 kernel.

Please fix... :/

Quoted 13 lines

Same thing for

-------------------------------------------------------------
[kai@zephyr linux-2.5.make]$ cp ../config-2.5 .config
[kai@zephyr linux-2.5.make]$ make
make[1]: Entering directory /home/kai/src/kernel/v2.5/linux-2.5.make/scripts' make[1]: Leaving directory /home/kai/src/kernel/v2.5/linux-2.5.make/scripts'
***
*** You changed .config w/o running make *config?
*** Please run "make oldconfig"
***
-------------------------------------------------------------

Quoted 1 line

Since people run automated builds, erroring out is IMHO preferable to dropping into interactive mode, which likely happens when you run make oldconfig.

agreed

Jeff

#9 lore raw
In reply to Kai Germaschewski

Hi,

Quoted 6 lines · Kai Germaschewski
Quoted 2 lines

One cosmetic thing I mentioned to Roman, Config.new needs to be changed to something better, like conf.in or build.conf or somesuch.

I agree. (But I'm not particularly good at coming up with names ;) build.conf is maybe not too bad considering that there may be a day where it is extended to support "<driver>.conf" as well.

Maybe it should start with a capital letter like Makefile/Config.in, so it's at the top of a directory listing.

Quoted 6 lines

I intentionally only printed a message and errored out in this case, and I think that's more useful, particularly for people doing

make all 2>&1 > make.log

which now may take forever waiting for input.

You should have tried this first :) :

$ make | cat
make[1]: Entering directory `/home/roman/src/linux-lkc/scripts'
make[1]: Leaving directory `/home/roman/src/linux-lkc/scripts'
make[1]: Entering directory `/home/roman/src/lc'
make[1]: `conf' is up to date.
make[1]: Leaving directory `/home/roman/src/lc'
./scripts/lkc/conf -s arch/i386/config.new
#
# using defaults found in .config
#
*
* Restart config...
*
Enable loadable module support (MODULES) [Y/n/?] y
  Set version information on all module symbols (MODVERSIONS) [N/y/?] (NEW) aborted!

Console input/output is redirected. Run 'make oldconfig' to update configuration.

make: *** [include/linux/autoconf.h] Error 1

bye, Roman

#10 lore raw
Quoted 8 lines · Roman Zippel
Quoted 6 lines

I intentionally only printed a message and errored out in this case, and I think that's more useful, particularly for people doing

make all 2>&1 > make.log

which now may take forever waiting for input.

You should have tried this first :) :

Yup, obviously ;) Sorry about that.

Quoted 17 lines
$ make | cat
make[1]: Entering directory `/home/roman/src/linux-lkc/scripts'
make[1]: Leaving directory `/home/roman/src/linux-lkc/scripts'
make[1]: Entering directory `/home/roman/src/lc'
make[1]: `conf' is up to date.
make[1]: Leaving directory `/home/roman/src/lc'
./scripts/lkc/conf -s arch/i386/config.new
#
# using defaults found in .config
#
*
* Restart config...
*
Enable loadable module support (MODULES) [Y/n/?] y
  Set version information on all module symbols (MODVERSIONS) [N/y/?] (NEW) aborted!
Quoted 3 lines

Console input/output is redirected. Run 'make oldconfig' to update configuration.

make: *** [include/linux/autoconf.h] Error 1

I'm still not happy at least for the ".config does not exist" case. Since when I forget to "cp ../config-2.5 .config", I don't really want "make oldconfig", I want to do the forgotten cp. I think there's hardly anyone who wants oldconfig in that case, rather menuconfig/xconfig or a cp like I mentioned. Since kbuild/lkc does not know, it shouldn't make that (bad) guess.

If .config exist but is not current, I think in 99% of the cases we really want make oldconfig, so that's fine.

--Kai

#11 lore raw

Hi,

Quoted 3 lines · Kai Germaschewski

I'm still not happy at least for the ".config does not exist" case. Since when I forget to "cp ../config-2.5 .config", I don't really want "make oldconfig", I want to do the forgotten cp.

Adding this check to the silent mode is trivial.

bye, Roman

#13 lore raw
In reply to Kai Germaschewski
Quoted 8 lines · Kai Germaschewski
Quoted 8 lines
Quoted 7 lines

scripts/lkc/Makefile*
- As kbuild does not distingush between individual objects, used for a given target, but (try to) build them all, I have found a solution where I create one Makefile for each executable. I could not see a clean way to integrate this in kbuild, and finally decided that in this special case a number of Makefiles did not hurt too much.

Quoted 4 lines
Quoted 2 lines

Here I thought about using "ifeq ($(MAKECMDGOALS),...)" to keep them in a single file. Did you try something like this?

That's now handled without obvious hacks.

Applying $(sort ) to create a unique list of obj files does not solve this issue, only hide it.
kbuild will compile all .o files originating from .c files when building conf and mconf.
Likewise when building qconf, all .o files originating from both .c _and_ .cc files will be built.
In other words the current solution leverage on the fact that the only problematic object files is qconf.o based on qconf.cc.

It is OK that the first "make oldconfig" - automatic or not - needs to compile one extra .o file (mconf.o), since this is relatively fast.

PS. linux-isdn.bkbits.net/linux-2.5.kconfig has not showed up yet - mentioned the patch you posted a diff for.

Sam

#14 lore raw
In reply to Kai Germaschewski

Hi,

(I almost forgot to reply to this one, sorry for the delay.)

Quoted 6 lines · Kai Germaschewski

I'm not particularly fond of these md5sum hacks. I don't think it's all that annoying for the developer, either, it's basically just a alias make="make LKC_GENPARSER=1"

(Of course, you'll have to update the _shipped files eventually, but there isn't really any way around that either way)

Where's the problem with md5sum? If the rules are usually not visible anyway, why do we use the _shipped postfix at all? The depencies are hidden this way as well, so make won't even try to regenerate the file. The developer has to remember that extra argument to get the file regenerated, what is IMO more hacky than using md5sum.

bye, Roman