[kbuild-devel] kbuild 2.5 menuconfig
I have started using of kbuild recently, latest on top of vanilla 2.4.16. Executing make -f Makefile-2.5 menuconfig gave me a few suprises. 1) The 'old-style' way to call GCC and friends was used, displaying a verbose list of options. 2) When menuconfig completed I was asked next to run make dep. As I have understood make dep is never required when using kbuild. My thoughts was that especially 2) was a leftover, waiting for inclusion in 2.5, but wanted to report it. /Sam ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Your opinion on CML2 and kbuild-2.5
On Fri, Feb 15, 2002 at 11:22:00AM +0100, Giacomo Catenazzi wrote: [Not a single word about the battle ongoing at LKLM...] kbuild-2.5: It does the right things! And this should be enought to tell you that it should be included in the next kernels. When Keith brought up the inclusion of kbuild-2.5 last time the general statement was that kbuild-2.5 had one fundamental error - speed. I have tested it a while back, and my result was not as bad as the roumours said about kbuild-2.5. Light .config, Pentium 266 with 64 MB RAM. kbuild-2.4 make dep + make bzImage ~55 minutes kbuild-2.5 make installable~60 minutes Then I added one more driver. kbuild-2.4 make dep + make bzImage ~7 minutes kbuild-2.5 make installable~2 minutes So my conclusion was that one single change where *I* had to run make dep made it worthwhile to shift to kbuild-2.5. I know that *I* have to run make dep far more often than all the kernel hackes - they know what they are doing in contrast. With respect to kbuild-2.5 inclusion, I would vote for the distributed configuration scheme that Linus et al. suggested a while ago. [driver.conf that included makefile.in, configure.help etc.] When kbuild-2.5 has been extended to support it, and the link-order have been solved then it is due time for inclusion. Jeff Garzik Keith O. had some discussion about the link-order problem a while ago, but at that point in time Keith stopped the discussion whith the statement that he did not care about 2.5, with reference to the refusual from Linus to accept among others the LINK_FIRST - LINK_LAST patch. I dunno what the conclusion on the link-order issue was. What I read between the lines is that kbuild-2.5 should not only fix the kbuild-2.4 bugs[*], but should also address the scalability issues that Linus raised - before he accepts it. [*] Bugs that I see, but kernel hackers are not hit by - because they know what they are doing. Personal I would like to see kbuild-2.5 included ASAP. Among other stuff I like the compressed output during compilation. Sam ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] [PATCH] kbuild: Remove 2048 symbol limit in tkparse
tkparse limit the number of symbols to 2048.
This patch makes the array dynamic avoiding this problem in the future.
The problem showed up in one of the powerpc tree's.
Credit for this patch goes to Keith Owens, I just extracted it from kbuild-2.5.
Sam
--- tkparse.h.orig Fri May 31 22:03:24 2002
+++ tkparse.h Fri May 31 21:42:03 2002
-115,7 +115,7
char global_written;
};
-extern struct variable vartable[];
+extern struct variable *vartable;
extern int max_varnum;
/*
--- tkparse.c.orig Fri May 31 22:03:14 2002
+++ tkparse.c Fri May 31 21:42:03 2002
-74,12 +74,12
/*
- * Find index of a specyfic variable in the symbol table.
+ * Find index of a specific variable in the symbol table.
* Create a new entry if it does not exist yet.
*/
-#define VARTABLE_SIZE 4096
-struct variable vartable[VARTABLE_SIZE];
+struct variable *vartable;
int max_varnum = 0;
+static int vartable_size = 0;
int get_varnum( char * name )
{
-88,8 +88,13
for ( i = 1; i = max_varnum; i++ )
if ( strcmp( vartable[i].name, name ) == 0 )
return i;
-if (max_varnum VARTABLE_SIZE-1)
- syntax_error( Too many variables defined. );
+while (max_varnum+1 = vartable_size) {
+ vartable = realloc(vartable, (vartable_size += 1000)*sizeof(*vartable));
+ if (!vartable) {
+ fprintf(stderr, tkparse realloc vartable failed\n);
+ exit(1);
+ }
+}
vartable[++max_varnum].name = malloc( strlen( name )+1 );
strcpy( vartable[max_varnum].name, name );
return max_varnum;
-818,5 +823,6
do_source( - );
fix_conditionals ( config_list );
dump_tk_script ( config_list );
+free(vartable);
return 0;
}
[kbuild-devel] [PATCH] kbuild: Allow strings with special characters in config file
Escape double quotes on eval so the quotes are still there on the second evaluation.
This is required to handle strings with special characters.
Credit for this patch goes to Keith Owens, I simply extracted it from kbuild-2.5.
Sam
--- Menuconfig.orig Fri May 31 21:55:40 2002
+++ Menuconfig Fri May 31 21:42:16 2002
@@ -73,6 +73,10 @@
# - Support for multiple conditions in dep_tristate().
# - Implemented new functions: define_tristate(), define_int(), define_hex(),
# define_string(), dep_bool().
+#
+# 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.
#
@@ -105,11 +109,11 @@
eval x=\$$1
if [ -z $x ]; then
eval `sed -n -e 's/# \(.*\) is not set.*/\1=n/' -e /^$1=/p
arch/$ARCH/defconfig`
- eval x=\${$1:-$2}
+ eval x=\${$1:-\$2\}
eval $1=$x
eval INFO_$1=' (NEW)'
fi
-eval info=\$INFO_$1
+eval info=\\$INFO_$1\
}
#
@@ -151,7 +155,7 @@
}
function define_string () {
- eval $1=$2
+ eval $1=\$2\
}
#
@@ -333,7 +337,7 @@
while [ -n $2 ]
do
- if eval [ _\$$2 = _y ]
+ if eval [ \_\$$2\ = \_y\ ]
then
current=$1
break
@@ -543,9 +547,9 @@
# we avoid them:
if expr $answer : '0$' '|' $answer : '[1-9][0-9]*$' '|'
$answer : '-[1-9][0-9]*$' /dev/null
then
- eval $2=$answer
+ eval $2=\$answer\
else
- eval $2=$3
+ eval $2=\$3\
echo -en \007
${DIALOG} --backtitle $backtitle \
--infobox You have made an invalid entry. 3
43
@@ -576,9 +580,9 @@
if expr $answer : '[0-9a-fA-F][0-9a-fA-F]*$' /dev/null
then
- eval $2=$answer
+ eval $2=\$answer\
else
- eval $2=$3
+ eval $2=\$3\
echo -en \007
${DIALOG} --backtitle $backtitle \
--infobox You have made an invalid entry. 3
43
@@ -676,9 +680,9 @@
do
if [ $2 = $choice ]
then
- eval $2=y
+ eval $2=\y\
else
- eval $2=n
+ eval $2=\n\
fi
shift ; shift
@@ -941,9 +945,9 @@
[ _ = _$ALT_CONFIG ] break
- if eval [ -r $ALT_CONFIG ]
+ if eval [ -r \$ALT_CONFIG\ ]
then
- eval load_config_file $ALT_CONFIG
+ eval load_config_file \$ALT_CONFIG\
break
else
echo -ne \007
@@ -1067,12 +1071,12 @@
#
function bool () {
set_x_info $2 n
- eval define_bool $2 $x
+ eval define_bool \$2\ \$x\
}
function tristate () {
set_x_info $2 n
- eval define_tristate $2 $x
+ eval define_tristate \$2\ \$x\
}
function dep_tristate () {
@@ -1138,19 +1142,19 @@
}
function define_hex () {
- eval $1=$2
+ eval $1=\$2\
echo $1=$2$CONFIG
echo #define $1 0x${2##*[x,X]}$CONFIG_H
}
function define_int () {
- eval $1=$2
+ eval $1=\$2\
echo $1=$2$CONFIG
echo #define $1 ($2) $CONFIG_H
}
function define_string () {
- eval $1=$2
+ eval $1=\$2\
echo $1=\$2\$CONFIG
echo #define $1 \$2\$CONFIG_H
}
@@ -1160,7 +1164,7 @@
}
function define_tristate () {
- eval $1=$2
+ eval $1=\$2\
case $2 in
y)
@@ -1199,7 +1203,7 @@
set -- $choices
while [ -n $2 ]
do
- if eval [ _\$$2 = _y ]
+ if eval [ \_\$$2\ = \_y\ ]
then
current=$1
break
Re: [kbuild-devel] Some feedback on using kbuild
On Mon, Jun 24, 2002 at 12:41:28AM +0200, Arnd Bergmann wrote: Why do you see so much added value in kbuild support for shadow trees compared to what a proper SCM tool give you? For my (linux on s390) purpose, shadow trees are the most important feature of kb25, because they allow us to use a proper SCM at all. Currently, we use a CVS repository that includes the official Linux tree as well as our closed source drivers. I would love to use Bitkeeper, but that's only possible if we can easily seperate the free from the the nonfree stuff without having two complete (incompatible) repositories. Shadow trees allow just that. So basically you need a tool to merge two directory structures without touching unchanged files. You could say that this is what you get for free in kbuild-2.5. But I do not see this as part of the kernel build system. Do you need this feature then create a small script that do exactly what you need and run it before the build process. The script should basically just copy modified files to the build tree. My point is that the kernel build system should not be cluttered with functionality that belongs in supporting tools. Hmm, and I did not see why you could not use BitKeeper or some other SCM for both the free anf non-free stuff?? A matter of dollars to spend? For most other people, the added value is that they don't have to use the same SCM tool as anyone else. Giving the user a tarball with a driver (or multiple ones, for that matter) is just so much easier than telling him/her how to patch the source with all things that can go wrong there. When the functionality in question touches common files this approach does no longer work. Therefore keep half solution out of the kernel build system. Sam --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [patch] config language dep_* enhancements
On Tue, Aug 13, 2002 at 01:23:19PM +1000, Greg Banks wrote: 977missing-experimental-tag 113spurious-experimental-tag 145variant-experimental-tag 30 inconsistent-experimental-tag 13 missing-obsolete-tag 41 spurious-obsolete-tag 25 variant-obsolete-tag How about extending the language (side effect) to automagically append (EXPERIMENTAL) or (OBSOLETE) to the menu line, if dependent on those special tags? Sam --- 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] Get rid of shell based Config.in parsers?
On Wed, Aug 14, 2002 at 10:22:55AM +1000, Greg Banks wrote: The trouble is actually achieving that in shell-based parsers where shell code cannot tell whether $CONFIG_EXPERIMENTAL has been used in a condition. Where comes the requirement that we shall keep the existing shell based config parsers? 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 is possible to replace Configure and menuconfig rather easy and then see if a new xconfig showed up based on the new parsers. This would allow us to do much more advanced semantic checks, and give proper warnings to catch errors early. The first versions should obviously not introduce new syntax, that should evolve over time. I dislike seeing arguments that this is not easy/possible in shell based parsers. If the chosen technology does not fit the problem domain then it's about time to shift technology. Sam --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [patch] config language dep_* enhancements
On Mon, Aug 19, 2002 at 07:27:50PM +1000, Greg Banks wrote: I'm not optimistic that a switch to a new language or even a new parser for the old language will ever happen. I asked Linus specifically about the replacement of the shell based parsers. The answer were quite simple: - It should be convinient to use a new parser. - Fast compilation, no errors etc. It's doable. In http://marc.theaimsgroup.com/?l=linux-kernelm=101387128818052w=2 David Woodhouse gives an idea of what would be necessary to get a new language+parser accepted. Can you achieve that yet? David suggest to use randomly generated configurations, but they lack one important feature. They are always valid, and a new system shall be able to deal with hand-edited .config files in the same way as oldconfig. Sam --- 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] linux kernel conf 0.3
On Tue, Aug 27, 2002 at 02:24:40AM +0200, Roman Zippel wrote: To install simply run 'make install KERNELSRC=..' and to uninstall 'make uninstall KERNELSRC=..', only 'make [oldconfig|config|menuconfig| xconfig]' is implemented right now, but the rest is easy to do. I tested it only against 2.5.31/i386, but other versions should work as well, as long as the rulebase is ok. Found a slot to give it a spin: 1) Did not apply cleanly to 2.5.31. Makefile caused a reject. Other hunks went ok, but with an offset. 2) When browsing in menuconfig the menus are repositioned depending of the length of the menu lines - irritating. Using this in pure text-mode 80X25. 3) The tag (NEW) disappear first time you touch an option. 4) ISDN part is missing. 5) Tried to delete endmenu on line 610 in arch/i386/config.in: ./scripts/lkc/mconf arch/i386/config.new none:0:parse error This error message is not good enough. I would like to see the language extended with some rules ala: A statement shall be opened and closed in the same file. This would make it trivial when reacing end-of-file to check if there is any pending statements. I have no idea how much will break if this is enforced. Greg's gcml may be the best tool to investigate that - Greg? General I dislike the requirement to convert all existing config.in files to support the new syntax. You already have the machinery to do the conversion online as needed, so why not detect if config.in is newer than config.lkc and if thats the case regenerate config.lkc. Then the different sub-systems and architectures could transform to the new syntax as they wish. As we can see with designated initialisers that will happen over a relatively short period of time - but the maintaneres will bring the changes to Linus. The syntax I sort of like, it's more readable than the old one. But I would like those who are better familiar with the old syntax to comment on this as weel. May the new syntax is simply not powerfull enough?? Linus asked for fast compilation. I will suggest removing -O2. The speed gained in execution can well be lost in compiling. For the next patch you should consider integrating it with kbuild. That's anyway where you will end up if it should go in the kernel. Sam --- 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] linux kernel conf 0.3
On Fri, Sep 06, 2002 at 03:45:45PM +1000, Greg Banks wrote: It seemed easy to add a check to gcml2 for if statements beginning and ending in the same file, so last night I did it. The result is... zero such cases in 2.5.33. The idea popped up when I noticed the missing endmenu in the appletalk/Config.in file recently. mconfig bailed out with an syntax error in arch/i386/config.in or similar. Thought it would be nice to point out where the actual error occured, and the easiest implementation IMO was to check that all statements opened in a file, was closed at end-of-file. And you proved it was easy at least in gcml2. Sam --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.7
On Sat, Sep 28, 2002 at 04:25:43PM +0200, Roman Zippel wrote:
Hi,
At http://www.xs4all.nl/~zippel/lc/ you can find the latest version of the
new config system.
Played with 0.7.1 just a little. Looks good so far.
1) Old tools zapped file: tags around filenames.
An issue (which was also mentioned by Jeff Garzik) is the help text
format. Jeff likes to have an endhelp, where I think it's redundant.
2) The current way forces the layout of the help text. I would prefer a way
that allowed the tools to use the space available instead.
Then a . followed by newline could be interpreted as forced-new-line
or similar.
If endhelp is needed for that I vote for this as well.
3) The syntax seems to be:
config SYMBOL
type-of-symbol optional-text
I would like optional-text to become mandatory. Then you could bail out
with an error when it does not exist.
An empty string should be legal , to cope with symbols not having any
associated text today.
4) Did not find the documentation you mentioned, but on the other hand I
applied only the 2.3.39 diff.
Minor details:
5) Show All intuitively is a shortcut for selecting all the three
possibilities {NAME, RANGE, DATA}, but is about showing all symbols.
6) The ARCH specific options does not fit well into the tree.
GENERIC_ISA_DMA in top of tree, X86_SMP in bottom of tree.
Visible only with SHOW ALL enabled.
7) I can step down in the tree but I need to select each sibling in the tree
induvidially. I expected to be able to select Cirrus logic under ALSA, and
let the selection boil up to the top.
8) File|Save followed by File|Quit. Still it ask if I want to save, even
no changes made inbetween.
9) Renames a file in a source statement:
[sam@mars lkc-2.5.39]$ make xconfig
make[1]: `qconf' is up to date.
./scripts/lkc/qconf arch/i386/Build.conf
can't find file ssound/arm/Build.conf
make: *** [xconfig] Error 1
Error shall tell where the file is sourced. [.../Build.conf:27]
10) Deleted endmenu tag in sound/Build.conf:
[sam@mars lkc-2.5.39]$ make xconfig
make[1]: `qconf' is up to date.
./scripts/lkc/qconf arch/i386/Build.conf
none:0:parse error, unexpected $
make: *** [xconfig] Error 1
Some errorhandling needs to be improved a little.
Sam
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Wed, Oct 02, 2002 at 09:59:00PM -0500, Kai Germaschewski wrote: Hi, I'd appreciate to get comments on the appended patch. It's mostly cleanups and the like, but the interesting part is the last cset, which is actually fairly small: Tried out what I pulled from linux-2.5.make 1) warning present in Makefile 2) Annoying /././ when doing make dep 3) Did a ld built-in.o in scripts, despite obj-y is empty - When i changed = to := to fix next error ar failed. ifdef O_TARGET replaced with ifdef obj-y to make it work 4) Could not link, no *.o file were used as parameters to ld cmd_link_o_target := $(if $(strip $(obj-y)),\ $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(obj-y), $^),\ rm -f $@; $(AR) rcs $@) $(O_TARGET): $(obj-y) FORCE @echo X $^ @echo $(obj-y) - $@ Result: make[1]: Entering directory `/home/sam/src/linux/kernel/bk/kai-make/init' Generating /home/sam/src/linux/kernel/bk/kai-make/include/linux/compile.h (unchanged) X main.o version.o do_mounts.o FORCE ./main.o ./version.o ./do_mounts.o - built-in.o ld -m elf_i386 -r -o ld: unrecognized option '-o' ld: use the --help option for usage information It seems that make strips ./ in front of all .o files listed in obj-y Utilising $(filter-out FORCE,$(obj-y) did the trick for me. [sam@mars kai-make]$ make -v GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Hmmm, was the stuff present at bkbits incomplete? Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Thu, Oct 03, 2002 at 09:26:18PM +0200, Sam Ravnborg wrote: Hmmm, was the stuff present at bkbits incomplete? Just checked, yes the attached patch was never. And fixes I think all the above. A new round of testing needed Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Wed, Oct 02, 2002 at 09:59:00PM -0500, Kai Germaschewski wrote: Hi, I'd appreciate to get comments on the appended patch. -obj-$(CONFIG_ACPI_INTERPRETER) := $(patsubst %.c,%.o,$(wildcard *.c)) +obj-y := dsfield.o dsmthdat.o dsopcode.o dswexec.o dswscope.o \ + dsmethod.o dsobject.o dsutils.o dswload.o dswstate.o Should that have been: obj-$(CONFIG_ACPI_INTERPRETER) := dsfield.o dsmthdat.o dsopcode.o... Looks wrong to me that you remove the CONFIG_ dependency. Same is true for the rest of this cset. +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 ) -multi-used-y := $(filter-out $(list-multi),$(__multi-used-y)) Here is list-multi removed. SUBDIRS += $(patsubst %/,%,$(filter %/, $(init-y) $(init-m))) I prefer first assignment to be := not += This is true for several places including several makefiles as well. -export CPPFLAGS EXPORT_FLAGS NOSTDINC_FLAGS OBJCOPYFLAGS +export CPPFLAGS EXPORT_FLAGS NOSTDINC_FLAGS OBJCOPYFLAGS LDFLAGS Did not see this change justified. -export NETWORKS DRIVERS LIBS HEAD LDFLAGS MAKEBOOT +$(warning $(SUBDIRS)) Warning shall be deleted ifndef O_TARGET ifndef L_TARGET -O_TARGET := built-in.o +O_TARGET := $(obj)/built-in.o +endif endif This change result in ld being called for directories like: $(TOPDIR)/scripts $(TOPDIR)/scripts/lxdialog $(TOPDIR)/Documentation/DocBook If obj-y is empty then do not define O_TARGET? Another more general comment. There seem to no consistency in the variables used in the first section of the makefile. There is a mixture of lower and upper case variables: O_TARGET, host-progs etc. This is confusing. Furthermore the construct: obj-y := some.o dot.o .o module.o Seems illogical to me. What does obj-y mean to me?? mandatory-objs := some.o dot.o .o module.o It a litte longer, but occur only once (typical) per makefile. Thats not something I propose for now, more to be seen as a general comment about striving for consistency in the interface to rules.make. first_rule: $(if $(KBUILD_BUILTIN),$(O_TARGET) $(L_TARGET) $(EXTRA_TARGETS)) \ Where comes the requirement that EXTRA_TARGETS needs to be buildin? -cmd_link_multi = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $($(basename $@)-objs),$^) +cmd_link_multi = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(addprefix $(obj)/,$($(subst $(obj)/,,$(@:.o=-objs,$^) Keep a variable without obj appended would make this readable I think. Now it's testing time.. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Thu, Oct 03, 2002 at 10:01:20PM +0200, Sam Ravnborg wrote: Now it's testing time.. 1) In order to make it link I had to change the following in rules.make: # If the list of objects to link is empty, just create an empty O_TARGET cmd_link_o_target = $(if $(strip $(obj-y)),\ - $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(obj-y), $^),\ + $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter-out +FORCE,$(obj-y)),\ rm -f $@; $(AR) rcs $@) Otherwise no objects were on the commandline because make strips ./ 2) Top-level Makefile still uses make -C therefore apths are relative to first subdirectory as seen here: CC udf/balloc.o CC udf/dir.o CC udf/file.o CC udf/ialloc.o 3) acpi failed to compile due to -Idrivers/acpi/include, but current directory is drivers. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Thu, Oct 03, 2002 at 03:38:22PM -0500, Kai Germaschewski wrote: On Thu, 3 Oct 2002, Sam Ravnborg wrote: On Thu, Oct 03, 2002 at 10:01:20PM +0200, Sam Ravnborg wrote: Now it's testing time.. [...] You must be missing some of the changes (My first push to bkbits was incomplete, since I did inadvertently edit Makefile without checking it out, I do that mistake all the time...). It's fixed in the current repo. This time I applied the patch you sent in the mail. Checking bkbits Yep, the latest csets on bkbits fixes some of this. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: RfC: Don't cd into subdirs during kbuild
On Thu, Oct 03, 2002 at 03:38:22PM -0500, Kai Germaschewski wrote: You must be missing some of the changes (My first push to bkbits was incomplete, since I did inadvertently edit Makefile without checking it out, I do that mistake all the time...). It's fixed in the current repo. Did a pull from bkbits at 18:30 CET, something like 09:30 pacific I think. In general. I like where you are heading, both the make -f, but also the cleanup done in the top-level Makefile. It makes it much easier to integrate my (ours) new make clean stuff - but that shall wait until this is in the kernel. Comments looking at the two new csets: 1) In the descend macro you test for ifeq ($(KBUILD_VERBOSE),1) To make it consistent I suggest to use ifneq ($(KBUILD_VERBOSE),0) As done earlier in the Makefile 2) Needed the following to make my kernel compile (make mrproper defconfig all) = Rules.make 1.76 vs edited = --- 1.76/Rules.make Thu Oct 3 04:51:25 2002 +++ edited/Rules.make Fri Oct 4 20:38:37 2002 @@ -161,7 +161,7 @@ # This sets version suffixes on exported symbols # --- -MODVERDIR := include/linux/modules/$(obj) +MODVERDIR := include/linux/modules # # Added the SMP separator to stop module accidents between uniprocessor @@ -191,7 +191,7 @@ # files (fix-dep filters them), so touch modversions.h if any of the .ver # files changes -quiet_cmd_cc_ver_c = MKVER include/linux/modules/$(obj)/$*.ver +quiet_cmd_cc_ver_c = MKVER include/linux/modules/$*.ver cmd_cc_ver_c = $(CPP) $(c_flags) $ | $(GENKSYMS) $(genksyms_smp_prefix) \ -k $(VERSION).$(PATCHLEVEL).$(SUBLEVEL) $@.tmp Otherwise if failed first time it included modversions.h 3) This is just to make output nicer with KBUILD_VERBOSE=0 = drivers/pci/Makefile 1.15 vs edited = --- 1.15/drivers/pci/Makefile Wed Oct 2 21:54:34 2002 +++ edited/drivers/pci/Makefile Fri Oct 4 20:59:55 2002 @@ -29,7 +29,9 @@ obj-y += syscall.o endif -host-progs := gen-devlist +host-progs := gen-devlist +quiet_cmd_gendevlist = DEVLIST $ +cmd_gendevlist= ( cd $(obj); ./gen-devlist ) $ include $(TOPDIR)/Rules.make @@ -40,6 +42,6 @@ # And that's how to generate them $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist - ( cd $(obj); ./gen-devlist ) $ + $(call cmd,gendevlist) $(obj)/classlist.h: $(obj)/devlist.h And the same for zorro: = drivers/zorro/Makefile 1.6 vs edited = --- 1.6/drivers/zorro/Makefile Wed Oct 2 21:54:34 2002 +++ edited/drivers/zorro/Makefile Fri Oct 4 21:05:54 2002 @@ -7,7 +7,9 @@ obj-$(CONFIG_ZORRO)+= zorro.o names.o obj-$(CONFIG_PROC_FS) += proc.o -host-progs := gen-devlist +host-progs := gen-devlist +quiet_cmd_gendevlist = DEVLIST $ +cmd_gendevlist = ( cd $(obj); ./gen-devlist ) $ include $(TOPDIR)/Rules.make @@ -18,4 +20,4 @@ # And that's how to generate them $(obj)/devlist.h: $(src)/zorro.ids $(obj)/gen-devlist - ( cd $(obj); ./gen-devlist ) $ + $(call cmd,gendevlist) --- 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: linux kernel conf 0.8
On Wed, Oct 09, 2002 at 02:01:50PM +0200, Roman Zippel wrote: On Tue, 8 Oct 2002, Linus Torvalds wrote: Some things made me go eww (but on the whole details): - I'd prefer the Config.in name, since this has nothing to do with building, and everything to do with configuration. Another suggestion about naming: Take for example drivers/net: cat Config.* | wc = 2149 lines A bit a structure could be needed here. Net.conf = Name equals directory with upper-case first letter - Cover the whole directory, and either implicit or explicit include other .conf files in that directory 3c5xx.conf = All the configuration for the 3c5xxx chipset drivers rrunner.conf = All configuration for rrunner driver So letting the naming convention be directory name with upper-case start letter - as the entry to a directory. Additional configuration in sensibly named configuration files. I do not see the split of configuration happen before 2.6, except in some special cases though. But I wanted to let the naming convention support that. source statements could look like: source driver/net = since Net.conf is implicit But I would prefer the files spelled out. On Tue, 8 Oct 2002, Linus Torvalds wrote: - I assume that the scripts are generated from the current Config.in and Config.help files, and it would make me slightly happier to see the diff as a automatic script + diff to fix it up, just for doc purposes. All this is in the archive. Keep both versions please. It's much easier just to apply a patch, but I see why Linus ask for the other solution. I know what version has preference ;-) Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
On Wed, Oct 09, 2002 at 11:47:16AM -0700, Linus Torvalds wrote: On Wed, 9 Oct 2002, Sam Ravnborg wrote: ls rrunner* should show me not only the implementation [.c + .h] but also the configuration. I agree with you, but only if we _always_ have one config file per driver. Which is not necessarily the wrong thing to do. The question here is what we aim at. And we aim at getting the configuration less centralized as compared with what we have today. I still remember the thread were you suggested the drivers.conf principle. And I liked it then, and I like it today. What I had to add a new driver to the kernel was to add the following three files: driver.c, driver,h driver.conf Even the makefile stuff could be retreived from driver.conf. But as long as most drivers are in grouped config files, they should be things like Config.3com etc. Looking at existing big config files (video, networking), they do _not_ group according to driver, but according to other criteria (ie PCI card, 100/1000 Mbit, 3com, Sparc-specific etc). But there is a good reason why they do it. Take a look at dirvers/video/Config.in for example. See the size of the big if's. They span several pages if not the whole file. Why they do this is simple. Only check for PCI once, and group all PCI stuff there. With the syntax Roman propose we see instead that _each_ config option check for PCI. Which is good IMHO. The most logical grouping should be utilised, and grouping based on bustype is not the grouping that we aim for. We aim to group similar drivers together, if they happens to be for the same bus or not should not matter. But the whole argumentation boils down to something rahter simple: 1) Shall we group configuration files together 2) Shall we group related files together And in mu opinion, if we decide not to use the filesystem namespace to group similar files, then the incentive to break things out in smaller files are mostly gone. Except in the case where I sumbit a new driver and want to keep my changes to the kernel file to a bare minimum, but then why not let the config file be grouped with the rest of the driver. Well I have raised my points, if you still prefer Config.* then let's stick to that. This should but be the reason to delay lkc-roman. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
On Wed, Oct 09, 2002 at 12:28:44PM -0700, Randy.Dunlap wrote: The kernel would still have the text-mode configurator. The way I read the original post by Christoph Hellwig - nope. If the kernel config library is outside the kernel then the text-mode versions will fail as well. Recall that the text-mode version are no longer shell scripts, but based on a nice YACC grammar and coded in C. I do not want to go somewhere for special tools just to configure the kernel. Basic stuff such as make and gcc is ok to locate elsewhere - in specific versions as well. But not some basic kernel only configurator. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
[cc: trimmed] On Thu, Oct 10, 2002 at 10:18:06AM -0400, Jeff Garzik wrote: Personally I don't care about Config dependency checking... they are not modified often enough to affect me, and even if they did, dependency checking based on changes to Config files can get ugly, AFAICS. I just do a bk -r co -Sq and am done with it... I care a lot about Config dependency checking, and you are not within the group of people that I care about in this respect. kernel-hackers has no problem realising that a make oldconfig is needed. But I care about NN that follows 2.6 development, and update his/her tree each time a new version is posted at kernel.org. This group of people needs dependency checking on Config files - as can be seen by the number of reports that boils down to run make oldconfig. Which we btw. have not seen the last couple of weeeks, but I still think is good. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: linux kernel conf 0.8
On Thu, Oct 10, 2002 at 01:32:11PM -0400, Jeff Garzik wrote: The kernel is written for people with a clue. For people without a clue, they should use a vendor kernel or ESR's Aunt-Tillie-friendly system. Dumbing-down the kernel is never the right answer. Well I'm not talking about dumbing-down the kernel. What I'm talking about is to keep existing functionality. For sure the kernel is made for people with a clue, but still people with a clue sometimes makes stupid mistakes. A build system that catches obvious stupid mistakes is IMHO a good thing. But it shall not that for any cost, and the normal incremental build shall continue to be as fast as possible. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [upatch] tweak for !KBUILD_VERBOSE output
On Sun, Nov 03, 2002 at 10:58:26AM -0600, Peter Samuelson wrote: With !KBUILD_VERBOSE output, you can't tell whether a CC or LD line is for a module or for the kernel proper. Sure, most people probably don't care, but *I* do. Hence this patch. Output: CC vmlinux-object.o CC [M] standalone-module.o CC (M) partial-module.o LD built-in.o LD [M] composite-object.o Nice. 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... Sam --- 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: [PATCH] [kbuild] Possibility to sanely link against off-directory .so
On Wed, Nov 06, 2002 at 07:52:30PM +0100, Petr Baudis wrote: Hello, this patch (against 2.5.46) introduces two special variables which make it actually possible to have .so as the only product of build in some directory and to link something against .so being built in another directory. The variable host-cshlib-extra makes it possible to explicitly mention shared objects to be built and the variable $(foo-linkobjs) allows user to specify additional objects to link foo against, while not creating any dependencies of foo on the objects. The changes are minimal while dramatically extending possibilities for messing with the shared objects and they should have no unwanted side-effects, and it appears to actually work for me. Please apply. There is only one user of shared libaries today, thats Kconfig. And Kconfig is the only user of C++ as well. There is quite a lot of added complexity in Makefile.lib + Makefile.build only to support this. Being the one that introduced it, I would like to see it go away again. Rationale behind this is that the current added complexity has an penalty when compiling a kernel, and I would like to move the complexity to the only user. Care to try that approach? Sam --- 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] [RFC/CFT] Separate obj/src dir
Based on some initial work by Kai Germaschewski I have made a working prototype of separate obj/src tree. Usage example: #src located in ~/bk/linux-2.5.sepobj mkdir ~/compile/v2.5 cd ~/compile/v2.5 sh ../../kb/v2.5/kbuild Prints out: SRCTREE=/home/sam/bk/linux-2.5.sepobj OBJTREE=/home/sam/compile/v2.5 And then the normal make process starts after a short period. The kbuild shell script takes a verbatim copy of all Makefiles, all Kconfig files and all defconfigs. I did not even look into using symlinks, I was not sure how they work across NFS and the like. The VPATH feature of make is used to let make locate the src in the directory where the kbuild script is located. I had to do some trikery with the CFLAGS to make it work. The processing done in the flags define in Makefile.build is rather unpleasent and I have another solution in mind I will give a try soon. I will try to include files via a directory in the root of OBJTREE and then create symlinks towards the directories present in SRCTREE - but need to play a bit more with that. Another drawback is that when a .h file exist in the SRCTREE but not in the OBJTREE the generated dependencies will point out the .h file located in SRCTREE. This happens for generated .h files, and therefore a simple check is made in kbuild to check that the SRCTREE is cleaned/mrpropered. kconfig did not have an option to read the Kconfig files + defconfig from somewhere else than current directory, therefore they are copied. But that should be trivial to do. Possible solutions: 1) Command line option: -r path-to-rrot-of-tree 2) Deduct it from the argument given, but then kconfig needs to know a bit too much about the kernel src tree. 3) Utilise the environment variable $(srctree), which is anyway valid. Comments expected... Sam = Makefile 1.346 vs edited = --- 1.346/Makefile Sat Nov 9 05:08:32 2002 +++ edited/Makefile Mon Nov 18 23:07:59 2002 @@ -136,13 +136,18 @@ export quiet Q KBUILD_VERBOSE # Paths to obj / src tree - +ifneq ($(wildcard .tmp_make_config),) +include .tmp_make_config +src := $(srctree) +obj := . +VPATH := $(srctree) +else src:= . obj:= . srctree := . objtree := . - -export srctree objtree +endif +export srctree objtree VPATH # Make variables (CC, etc...) @@ -304,7 +309,7 @@ set -e $(if $(filter .tmp_kallsyms%,$^),, echo ' Generating build number' - . scripts/mkversion .tmp_version + $(CONFIG_SHELL) $(src)/scripts/mkversion .tmp_version mv -f .tmp_version .version $(Q)$(MAKE) -f scripts/Makefile.build obj=init ) @@ -406,7 +411,11 @@ include/asm: @echo ' Making asm-asm-$(ARCH) symlink' +ifeq ($(srctree),$(objtree)) @ln -s asm-$(ARCH) $@ +else + @ln -s $(src)/include/asm-$(ARCH) $@ +endif # Split autoconf.h into include/linux/config/* @@ -585,7 +594,7 @@ tar -cvz $(RCS_TAR_IGNORE) -f $(KERNELPATH).tar.gz $(KERNELPATH)/. ; \ rm $(KERNELPATH) ; \ cd $(TOPDIR) ; \ - . scripts/mkversion .version ; \ + $(CONFIG_SHELL) $(src)/scripts/mkversion .version ; \ rpm -ta $(TOPDIR)/../$(KERNELPATH).tar.gz ; \ rm $(TOPDIR)/../$(KERNELPATH).tar.gz = scripts/Makefile.build 1.11 vs edited = --- 1.11/scripts/Makefile.build Thu Nov 14 17:08:38 2002 +++ edited/scripts/Makefile.build Tue Nov 19 20:39:41 2002 @@ -84,26 +84,34 @@ $(multi-objs-y:.o=.s) : modname = $(modname-multi) $(multi-objs-y:.o=.lst) : modname = $(modname-multi) +# Allow gcc to locate header files in srctree, if we use separate objtree +ifeq ($(srctree),$(objtree)) +flags = $($(1)) +else +flags = -I$(obj) -I$(srctree)/$(src) $($(1)) $(patsubst -I%,-I$(srctree)/%,$(filter +-I%,$($(1 +endif + quiet_cmd_cc_s_c = CC $(quiet_modtag) $@ -cmd_cc_s_c = $(CC) $(c_flags) -S -o $@ $ +cmd_cc_s_c = $(CC) $(call flags,c_flags) -S -o $@ $ %.s: %.c FORCE $(call if_changed_dep,cc_s_c) quiet_cmd_cc_i_c = CPP $(quiet_modtag) $@ -cmd_cc_i_c = $(CPP) $(c_flags) -o $@ $ +cmd_cc_i_c = $(CPP) $(call flags,c_flags) -o $@ $ %.i: %.c FORCE $(call if_changed_dep,cc_i_c) quiet_cmd_cc_o_c = CC $(quiet_modtag) $@ -cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $ +cmd_cc_o_c = $(CC) $(call flags,c_flags) -c -o $@ $ %.o: %.c FORCE $(call if_changed_dep,cc_o_c) quiet_cmd_cc_lst_c = MKLST $@ -cmd_cc_lst_c = $(CC) $(c_flags) -g -c -o $*.o $ sh scripts/makelst $*.o System.map $(OBJDUMP) $@ +cmd_cc_lst_c = $(CC) $(call flags,c_flags) -g -c -o $*.o $ \ +sh $(src)/scripts/makelst $*.o System.map $(OBJDUMP) $@ %.lst: %.c FORCE $(call if_changed_dep,cc_lst_c) @@ -116,17 +124,14 @@ $(real-objs-m) : modkern_aflags := $(AFLAGS_MODULE) $(real-objs-m:.o=.s): modkern_aflags := $(AFLAGS_MODULE) -a_flags = -Wp,-MD,$(depfile) $(AFLAGS) $(NOSTDINC_FLAGS)
[kbuild-devel] Re: [RFC/CFT] Separate obj/src dir
On Tue, Nov 19, 2002 at 03:22:45PM -0500, Richard B. Johnson wrote: I have a question; What problem is this supposed to solve? Two problems (at least): 1) You want to compile your kernel based on two different configurations, but sharing the same src. No need to have a duplicate of all src. - There are other ways to do this using symlinks 2) You have the src located on a read-only filesystem. I have been told this is the case for some SCM systems. People has requested this feature at several occasions, and here it is based on the current build system. It's not ready for inclusion (obviously), and you shall also see this as a way to check that this is considered usefull by someone. Sam --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [RFC/CFT] Separate obj/src dir
On Tue, Nov 19, 2002 at 12:31:15PM -0800, Larry McVoy wrote: It can be really nice to maintain a bunch of different architectures at the same time from the same tree. It also makes it really easy to clean a tree. On the other hand, I do wonder whether ccache could be used to get the same effect. Sam? I have never taken the time to look into ccache, so I dunno. Sam --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [RFC/CFT] Separate obj/src dir
On Tue, Nov 19, 2002 at 03:46:28PM -0500, Richard B. Johnson wrote: Different configurations are handled with different .config files. And different .config files results in different kernels. Please note that .config files are also located in OBJTREE. Cosider something like the following: ~/bk/linux-2.5 ~/compile/arm = Used to check that the kernel compiles for ARM ~/compile/allmod = My config with a lot of modules ~/compile/machine = The config I use on my machine ~/compile/work= That's my sandbox All configurations share the same src. During the last copule of days we have seen some header file clean-ups. It would have been nice if they tried compiling in all four configurations listed above. But if I switch .config then it is often a recompile of everything, whereas the above setup can minimize it. The header file cleanup is maybe not the best example because touching a few key header files requires recompilation of everything anyway. But my point is that there is a good use of different configurations based on the same src. Others that have asked for separate obj dir may step in here, explaining why they thougt it was good. Sam --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [RFC/CFT] Separate obj/src dir
On Tue, Nov 19, 2002 at 02:48:09PM -0600, Kai Germaschewski wrote: Wrt the original patch, I like it, one preliminary comment is that I think symlinks are nicer than copying. They are faster, shouldn't cause any trouble on NFS, make uses stat and not lstat, so it gets the timestamps right, too. And if you edit a Makefile/Kconfig in the source tree, you rather want that to take effect immediately, I guess ;) Second try on the script. Create symlinks as suggested, and optimised find a liitle. Sam #!/bin/sh # # This script is used to build a kernel from a separate directory. # The location of this script is assumed to be the root of # the kernel tree. # Usage: # kernel src located in: # ~/kernelsrc # compile in: # ~/compile # cd ~/compile = Change to the directory where the compile shall take place # ../kernelsrc/kbuild # # Arguments to kbuild is the same as used to make in the kernel build # kbuild prints out SRCTREE and OBJTREE when started, and then makes a mirror # of relevant files from the kernelsrc. # files we do not care about in the kernel src RCS_FIND_IGNORE=-name SCCS -o -name BitKeeper -o -name .svn -o -name CVS OBJTREE=$PWD cd `dirname $0` SRCTREE=$PWD cd $OBJTREE echo OBJTREE $OBJTREE echo SRCTREE $SRCTREE if [ $SRCTREE != $OBJTREE ]; then if [ -f $SRCTREE/.config -o -d $SRCTREE/include/asm ]; then echo '$SRCTREE contains generated files, please run make mrproper in the SRCTREE' else for a in `cd $SRCTREE; \ find \( $RCS_FIND_IGNORE \) -prune -o -name Makefile\* -o -name Kconfig\* -o -name defconfig`; do if [ ! -d `dirname $a` ]; then mkdir -p $a fi ln -fs $SRCTREE/$a $a done ( echo srctree := $SRCTREE; echo objtree := $OBJTREE; ) .tmp_make_config touch Rules.make make $* fi else rm -f .tmp_make_config make $* fi --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Separate obj/src dir
On Tue, Nov 19, 2002 at 02:51:54PM -0600, Brian Jackson wrote: Sam Ravnborg writes: I wonder how hard it would be to do this for other files types. It would be sort of handy to be able to copy a single file out of the source tree into the build tree, and have the build use the copy in the build tree. Example: you want to test a one liner in drivers/scsi/sd.c, you could just copy sd.c into the build tree, and make the change and test it out. That could be a huge space savings. That would help out those of us that are stuck with tiny hard drives in our laptops :) It actually works. But that is a side-effect and not something I had planned. I tried your example and kbuild uses the sd.c located in OBJTREE if present. make searches lokal directory before VPATH directory. And when sd.c is deleted the commandline changes and the original file is compiled again. But I can see several drawbacks with this, especially dealing with .h files, or .c files included by other .c files. So this is not a trustable feature. Sam --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Need General Information
On Tue, Jan 07, 2003 at 02:07:21PM -0800, John van V. wrote: Hi, I have been compiling kernels for a branch of a security project called Devil-Linux, also on sourceforge. It has been a hit or miss process for me. Unlike GNU compliant software compiles, I have been unable to standardize kernel compiles. What does Kbuild offer, can it help me in this process ?? Could you be a bit more specific about what you ask for? - Writing kbuild compliant makefiles? - Compile modules outside the tree? - Utilise kbuild for something else? - And btw. 2.4 or 2.5? Will be glad to help, but need to understand what you ask for. Sam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converter cml1-kconfig?
On Sun, Jan 12, 2003 at 10:31:05AM -0800, John van V. wrote: Hello, could you please give me an over view of what this all does... Could you please be a bit more specific in your questions. Do you request info about hte cml1 - Kconfig converter, or just Kconfig itself? Kconfig is a simple language used to configure the Linux kernel. Kconfig is tailored to the kernel, and therefore choices are often n : Do not include this y : includes this functionality m : include this functionality as a module Different functionalities can depend on each other. The Kconfig files are read by the kconfig backend and visualised by one of the front ends. conf (config) : List all choices mconf (menuconfig): utilising ncurser displays a nice menu based program qconf: (xconfig): Using QT list all choices in a grapical tree structure gconf: (): Same as qconf, based on GTK-2.0. (Under development, looks good) Take a peek in Documentation/kbuild/config-language.txt (or similar name) Try to browse a few kconfig files Try to configure a kernel This should give you a good understanding on the functionality. Finally - if you hope for more feedback then be a bit more precise, and reply to follow-up questions. Sam --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converter cml1-kconfig?
On Sun, Jan 12, 2003 at 05:47:53PM +0100, Robert Schwebel wrote: Hi, is a standalone converter script from cml1 to kconfig still available somewhere? I remember having read that there was one during the 2.5 inclusion. Digged up this URL: http://www.xs4all.nl/~zippel/lc/ Sam --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] kbuild-devel is dead? [Was: Suggestion for addition to the root Makefile]
On Sat, Mar 01, 2003 at 02:59:06PM -0600, Michael Elizabeth Chastain wrote: BTW I think this list is nearly dead. Agree. One reason for this is that a couple of times when new stuff has been ready for inclusion, Linus complained that it was developed in a 'closed forum' - and he wants public review on lkml for non-trivial stuff. At least thats my primary reason to select lkml in preference of kbuild-devel. Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Problems with make menuconfig of linux2.6.0-test5
On Sat, Sep 13, 2003 at 08:56:36PM +0200, Martin Schaffner wrote: 4) I can't invoke make menuconfig if I don't have write access to the linux kernel directory (useful to just look at a configuration of a write-protected source tree) When the patch to enable separate output directory is merged you can execute 'make menuconfig' in a tree with read-only src. Te necessary tools will be build in the directory you specify with O= Sam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] make -j2 doesn't work anymore
On Thu, Oct 09, 2003 at 11:33:39AM -0400, Burton Windle wrote: Hello. It seems that if you build your kernel with simply 'make -j 2' instead of 'make -j 2 bzImage', the make system only uses one process instead of the number specified (I only see one cpp process, and the build takes twice as long as normal). Works for Me (TM).. The best way to check is to look at the output. If you see the compiler shifting between two directories you know it works. Sample output: CC arch/i386/kernel/cpu/mcheck/p5.o CC kernel/printk.o CC arch/i386/kernel/cpu/mcheck/p6.o As you can see the kernel is being built in arch/i386/kernel/cpu in parallel with kernel/ If you still see this error then it most be a problem local to your setup - if more people saw it they would have complained. Sam --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Compile line output
On Thu, Oct 23, 2003 at 01:39:46PM -0400, Aamir Rashid wrote: Hi Folks, A couple of basic question(s) regarding kbuild-2.5: 1) With the default kbuild-2.5, my kernel compile line is something like: CC drivers/block/loop.o CC drivers/block/nbd.o CC drivers/net/tulip/eeprom.o CC drivers/net/tulip/interrupt.o CC drivers/net/tulip/media.o CC drivers/net/tulip/timer.o CC drivers/net/tulip/tulip_core.o How do I get to see the COMPLETE COMPILE LINE which shows me all the compiler flags, include paths etc.? 'make help' explains you how. Try make V=1 Sam --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Clean alternative to $subst(...,...,$(CFLAGS))
On Mon, Oct 20, 2003 at 11:44:28AM -0700, Adam Litke wrote: I am working on a patch which requires all .c files to be compiled with the -pg option. However, there are two specific files for which -pg must not be used. Below is the current way I am accomplishing this. Hi Adam. I have tried to think of a better solution - and I see now easy and clean way to do this within kbuild. If you could convince the gcc people to implement -no-pg it would be easy. Any chance the last two files can be compiled with -pg also with a few changes? I do not see why debugging info can harm here. Sam --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] missing features in 2.6 arch/ppc64/boot/Makefile
On Thu, Oct 16, 2003 at 05:07:54PM +0200, Olaf Hering wrote: Hello, the 2.6 arch/ppc64/boot/Makefile misses 2 features from 2.4. Unfortunately, they are not yet part of the main 2.4 tree. I attach the Makefile for reference. I cant figure out how to add these 2 things to 2.6. Which of the three boot loaders are you concerned about? simple, openfirmware or prep. Would make it easier to prepare something for you. Sam --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Clean alternative to $subst(...,...,$(CFLAGS))
On Fri, Oct 24, 2003 at 12:56:55PM -0700, Adam Litke wrote: On Fri, 2003-10-24 at 11:39, Sam Ravnborg wrote: Any chance the last two files can be compiled with -pg also with a few changes? I do not see why debugging info can harm here. Functions inside files compiled with -pg get instrumented with a call to the symbol 'mcount' after the prologue. If the file that defines the function mcount is compiled with -pg, you get stuck in infinite recursion because each call to mcount will trigger another call to mcount, etc. That could be solved if you define mcount in assembly, thus preventing the instrumentation. Also in misc.o, the mcount symbol is not visible and attempts to call it generate linker errors. These are just two of the reasons why it is necesary. misc.o is special for sure. Untested - but a solution could be to add -qt to both CFLAGS_MODULE and CFLAGS_KERNEL They should not be picked up by misc.o Requires the following (white space damaged) patch = scripts/Makefile.build 1.41 vs edited = --- 1.41/scripts/Makefile.build Sun Oct 5 08:50:46 2003 +++ edited/scripts/Makefile.build Fri Oct 24 23:47:43 2003 @@ -82,8 +82,8 @@ # --- # Default is built-in, unless we know otherwise -modkern_cflags := $(CFLAGS_KERNEL) quiet_modtag := $(empty) $(empty) +$(real-objs-y): modkern_cflags := $(CFLAGS_KERNEL) $(real-objs-m): modkern_cflags := $(CFLAGS_MODULE) $(real-objs-m:.o=.i) : modkern_cflags := $(CFLAGS_MODULE) @@ -191,7 +191,7 @@ # Compile assembler sources (.S) # --- -modkern_aflags := $(AFLAGS_KERNEL) +$(real-objs-y) : modkern_aflags := $(AFLAGS_KERNEL) $(real-objs-m) : modkern_aflags := $(AFLAGS_MODULE) $(real-objs-m:.o=.s): modkern_aflags := $(AFLAGS_MODULE) Sam --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Makefile INSTALL_MOD_PATH
On Fri, Oct 31, 2003 at 10:12:42AM -0500, PDock wrote: Not being a rpm user I have been using the command line O= option. Please give consideration to the following modification to the linux-2.6 makefile: # OK, Make called in directory where kernel src resides # Do we want to locate output files in a separate directory? ifdef O ifeq ($(origin O), command line) KBUILD_OUTPUT := $(O) export INSTALL_MOD_PATH := $(O) endif endif *** With this change 'make O=/your/path modules_install' does not alter the build hosts /lib/modules which I meekly submit should be the default behavior when using the O= option. Not being a list subscriber I apologize if this has been covered. The correct way to do it is to use: make INSTALL_MOD_PATH=/dir/ ... Extract from top-level makefile: # # INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory # relocations required by build roots. This is not defined in the # makefile but the arguement can be passed to make if needed. # Sam --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] using source files from other directories
On Sun, Nov 09, 2003 at 06:45:28PM +0100, Andi Kleen wrote: Hallo, The x86-64 port is reusing several source files from the i386 port. Originally in 2.4 this was done using symlinks created in the Makefile; but that was changed in 2.6 when the separate obj directory support was added. Currently it uses e.g in arch/x86_64/kernel/Makefile for the cpuid driver: obj-$(CONFIG_X86_CPUID) += cpuid.o cpuid-$(CONFIG_X86_CPUID) += ../../i386/kernel/cpuid.o Try this: obj-$(CONFIG_X86_CPUID) += cpuid.o cpuid-$(subst m,y,$(CONFIG_X86_CPUID)) += ../../i386/kernel/cpuid.o A workaround - not what I consider 'the solution'. Sam --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Kernel 2.6 small typo in top level README
On Fri, Jan 16, 2004 at 04:20:36PM -0500, ezra peisach wrote: If this is the incorrect place, I am sorry - but this is the closest I could find make modules_install not install_modules.. Thanks for the reminder, I will push a patch when Linus returns. Sam --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] UML make -j problem
On Mon, Jan 19, 2004 at 11:00:15AM +0100, Ingo Molnar wrote: one problem the UML build has in 2.6 is that 'make -j' does not work after a 'make clean'. The problem is the building of two binaries in arch/um/util/, which needs the kbuild infrastructure but which tools are also used for the 'prepare' stage. what would be the cleanest solution? Dunno right now. I have to finish some ppc stuff, then next task is to take a closer look at UML. I will try to sort out your -j issue as well as the other pending request I have queued. Sam --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] linux 2.6.1 - ide.ko has unresolved symbols if compiled as module
On Mon, Jan 19, 2004 at 09:34:09AM +0100, Stefan Bergler wrote: I tried to selelct / compile the ide part as module within the kernel, with only CD-Rom support. 'make all' worked fine. Building IDE as a module has been known broken for some time now. It should be OK in 2.6.2-rc1, Bartomlej (the IDE maintainer) has put some effort in it the last week. Note: I tried to contact Michael Elizabeth Chastain, as listed in Maintainers, but looks as if he is no longer maintining it. This list, and Michael in the past, are focussing on kbuild, the kernel build system. What you see is a specific IDE issue which shall be addresses to the maintainer for that part. Today Kai Germaschewski and I are kbuild maintainers, which is also listed in 2.6.2-rc1 MAINTAINERS. Sam --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Query regarding extra-y targets
On Wed, Jan 21, 2004 at 12:13:06PM +0530, Hariprasad Nellitheertha wrote: The problem with this is that the target is not built when we build LKCD as a module, as CONFIG_CRASH_DUMP is set to m. I read the kbuild documentation and there does not seem to be anything equivalent to extra-y when it comes to modules. In order to overcome the problem, I used an ifdef-endif wrapper as below. ifdef CONFIG_CRASH_DUMP extra-y := kerntypes.o endif Two type of solutions exits. You can always define a symbol in your Kconfig file with the bool type and use that in the Makefile. So it looks like: extra-$(CONFIG_KERN_TYPES) += kerntypes.o Note: I prefer '+=', which allow you to just add an extra line anywhere in the file. The second type of solution is simply to replace the m with an y. Several syntaxes are supported: extra-$(patsubst,m,y,$(CONFIG_CRASH_DUMP)) += kerntypes.o extra-$(subst,m,y,$(CONFIG_CRASH_DUMP)) += kerntypes.o extra-$(CONFIG_CRASH_DUMP:m=y) += kerntypes.o The first one is the most widely used construction. So if you go for solution 2, then use patsubst. Sam --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] linux 2.6.1 - ide.ko has unresolved symbols if compiled as module
On Wed, Jan 21, 2004 at 05:44:26PM -0500, Michael Elizabeth Chastain wrote: Sam Ravnborg writes: Today Kai Germaschewski and I are kbuild maintainers, which is also listed in 2.6.2-rc1 MAINTAINERS. Right. I still spam-filter the kbuild-devel mailing list, but that's the extent of my activity. I'm working on gdb now. Any reason to keep kbuild-devel around still? I do not need it, but I follow what is going n here - of course. In MAINTAINERS for 2.6 I left it out. BTW, I still get mail frequently from mandrake users (and now gentoo users too) about menuconfig problems with their distros. Is there a good FAQ URL I can point people to for that? Not that I am aware off. But I have not seen the ALSA problem reported lately. Maybe you should request Marcelo to remove your mail address from Configure? That may help long-term. Sam --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] linux 2.6.1 - ide.ko has unresolved symbols if compiled as module
On Tue, Jan 27, 2004 at 01:24:19AM -0500, Michael Elizabeth Chastain wrote: Maybe you should request Marcelo to remove your mail address from Configure? That may help long-term. You're right, I'll go do that. What is Marcelo's address? You can reach him at: Marcelo Tosatti [EMAIL PROTECTED] For your convinience I prepared the following patch. I expect you to send it on to Marcelo. Sam = MAINTAINERS 1.124 vs edited = --- 1.124/MAINTAINERS Thu Jan 8 22:47:10 2004 +++ edited/MAINTAINERS Tue Jan 27 20:54:43 2004 @@ -480,11 +480,9 @@ S: Supported CONFIGURE, MENUCONFIG, XCONFIG -P: Michael Elizabeth Chastain -M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://kbuild.sourceforge.net -S: Maintained +S: Orphan CONFIGURE.HELP P: Steven P. Cole @@ -1062,8 +1060,6 @@ KERNEL BUILD (Makefile, Rules.make, scripts/*) P: Keith Owens M: [EMAIL PROTECTED] -P: Michael Elizabeth Chastain -M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://kbuild.sourceforge.net S: Maintained = scripts/Configure 1.3 vs edited = --- 1.3/scripts/Configure Tue Sep 24 09:49:53 2002 +++ edited/scripts/ConfigureTue Jan 27 20:56:27 2004 @@ -8,7 +8,7 @@ # enough. # # Raymond Chen was the original author of Configure. -# Michael Elizabeth Chastain ([EMAIL PROTECTED]) is the current maintainer. +# Many improvements by Michael Elizabeth Chastain. # # 050793 - use IFS='@' to get around a bug in a pre-version of bash-1.13 # with an empty IFS. = scripts/Menuconfig 1.7 vs edited = --- 1.7/scripts/Menuconfig Sun May 26 13:14:41 2002 +++ edited/scripts/Menuconfig Tue Jan 27 20:58:07 2004 @@ -20,7 +20,7 @@ # script. # # William Roadcap was the original author of Menuconfig. -# Michael Elizabeth Chastain ([EMAIL PROTECTED]) is the current maintainer. +# Many improvements by Michael Elizabeth Chastain. # # 070497 Bernhard Kaindl ([EMAIL PROTECTED]) - get default values for # new bool, tristate and dep_tristate parameters from the defconfig file. @@ -844,8 +844,7 @@ sed 's/^/ Q /' MCerror cat EOM -Please report this to the maintainer [EMAIL PROTECTED]. You may also -send a problem report to [EMAIL PROTECTED]. +You may report this to [EMAIL PROTECTED]. Please indicate the kernel version you are trying to configure and which menu you were trying to enter when this error occurred. @@ -906,9 +905,8 @@ the /usr/src/linux/scripts/lxdialog directory and issuing the make clean all command. -If you have verified that your ncurses install is correct, you may email -the maintainer [EMAIL PROTECTED] or post a message to -[EMAIL PROTECTED] for additional assistance. +If you have verified that your ncurses install is correct, you may post +a message to [EMAIL PROTECTED] for additional assistance. EOM cleanup = scripts/README.Menuconfig 1.1 vs edited = --- 1.1/scripts/README.Menuconfig Tue Feb 5 18:40:36 2002 +++ edited/scripts/README.MenuconfigTue Jan 27 21:01:19 2004 @@ -189,6 +189,6 @@ He will not be able to assist. William Roadcap was the original author of Menuconfig. -Michael Elizabeth Chastain [EMAIL PROTECTED] is the current maintainer. +Many improvements by Michael Elizabeth Chastain. END OF FILE = scripts/tkcond.c 1.1 vs edited = --- 1.1/scripts/tkcond.cTue Feb 5 18:40:36 2002 +++ edited/scripts/tkcond.c Tue Jan 27 20:58:56 2004 @@ -2,7 +2,7 @@ * tkcond.c * * Eric Youngdale was the original author of xconfig. - * Michael Elizabeth Chastain ([EMAIL PROTECTED]) is the current maintainer. + * Many improvements by Michael Elizabeth Chastain. * * This file takes the tokenized statement list and transforms 'if ...' * statements. For each simple statement, I find all of the 'if' statements = scripts/tkparse.c 1.2 vs edited = --- 1.2/scripts/tkparse.c Sat May 4 15:53:16 2002 +++ edited/scripts/tkparse.cTue Jan 27 21:00:28 2004 @@ -2,7 +2,7 @@ * tkparse.c * * Eric Youngdale was the original author of xconfig. - * Michael Elizabeth Chastain ([EMAIL PROTECTED]) is the current maintainer. + * Many improvements by Michael Elizabeth Chastain. * * Parse a config.in file and translate it to a wish script. * This task has three parts: @@ -41,8 +41,7 @@ * all others now, * * TO DO: - * - xconfig is at the end of its life cycle. Contact [EMAIL PROTECTED] if - * you are interested in working on the replacement. + * - xconfig is at the end of its life cycle. */ #include stdio.h --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ kbuild-devel mailing list [EMAIL PROTECTED]
[kbuild-devel] Re: [RFC] External kernel modules
On Mon, Feb 02, 2004 at 07:01:21AM +0100, Andreas Gruenbacher wrote: I propose the attached patch: It adds symbol version dump/load functionality to modpost: When compiling the kernel, the module versions are dumped to a file. When compiling external modules, the dumped symbols are first loaded. Also, to allow a read-only kernel source tree and not interfere with the kernel sources, the .tmp_versions/ directory is placed in the external module's directory. Furthermore, the patch adds clean/distclean/mrproper make targets with reasonable semantics for external modules, and also adds a modules_add target that installs the external modules into /lib/modules/$(KERNELRELEASE). (The modules_install target could be used, but it has different semantics, so I have used a different name instead.) Thanks, I will take a closer look during the week. Did you consider using the make O=dir support, so .tmp_versions were created in the output directory? Sam --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: External kernel modules, second try
On Sun, Mar 07, 2004 at 01:44:58AM +0100, Andreas Gruenbacher wrote: Hello, here is the patch I posted previously that adds support for modversions in external kernel modules that are built outside the main kernel tree (first posting archived here: http://lwn.net/Articles/69148/). Relative to the original version, the attached version also works when compiling with O=. Hi Andreas. I have started to look into this. The changes im Makefile when you use SUBDIRS as a flag does not look pretty. What I have in mind is something like this: - Get rid of current use of SUBDIRS. It is no longer used in any arch Makefiles. - Introduce a KBUILD_EXTMOD variable that is only set when building external modules - Introduce a new method to be used when compiling external modules: make M=dir-to-module - Keeping the SUbDIRS notation for backward compatibility - When using SUBDIRS or M= the 'modules' target is implicit. - make clean and make mrproper/distclen only deletes files in the external module directory (as done in your patch) - Error out if any updadtes are requires in the kernel tree - Find a magic way to include a Kconfig file for the external module - Allow kbuild Makefiles to be named Kbuild, so local stuff can be in a file named Makefile file note: this can be achieved using makefile/Makefile today but it makes sense since there is not much 'Make' syntax left in kbuild makefiles today. Above will not be made in one go. My next step is to make a patch for the first four steps - to see the actual impact on current makefiles. Comments welcome! Could you explain what is the actually gain of using the modversions file your patch creates. (modpost changes) The patch also adds a modules_add target that does the equivalent of modules_install for one external module. Looks good. The third change is to remove one instance of temporary file creation inside the main kernel tree while external modules are built. I think there are still other cases where temp files in the kernel tree are used. IMHO they should all go away, so that a ``make -C $KERNEL_SOURCE modules SUBDIRS=$PWD'' works against a read-only tree. Agree - should be easy to test using a CD. Are there an easy way to mount just a directory structure RO? Sam --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: External kernel modules, second try
On Sun, Mar 07, 2004 at 03:01:31PM +0100, Arjan van de Ven wrote: and it's missing the symbols from module files. sure but the module files are generally installed... I'm aiming for a situation where I can build external modules, using an almost clean kernel src tree. Which means that my make clean on steroids patch maybe is a bit too effective. The distintion point could be: make clean leaves only enough to build external modules. Otherwise we need a third (fourth) cleaning target, which is not desireable. Sam --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: External kernel modules, second try
On Sun, Mar 07, 2004 at 02:32:14PM +0100, Andreas Gruenbacher wrote: What I have in mind is something like this: - Get rid of current use of SUBDIRS. It is no longer used in any arch Makefiles. - Introduce a KBUILD_EXTMOD variable that is only set when building external modules - Introduce a new method to be used when compiling external modules: make M=dir-to-module - Keeping the SUbDIRS notation for backward compatibility - When using SUBDIRS or M= the 'modules' target is implicit. Why not keep the SUBDIRS notation for external modules only then? That's what was documented to work since a long time; I see no big benefit in changing it if it can be avoided. Since a long time is from 2.5.5x roughly. The SUBDIRS= notation is not intuitive, and the M= notation follow the other similar options: O=, C=. SUBDIRS will be kept, but warned for in 2.7. Removed when 2.8 opens or similar. So I see no breakage here. - Find a magic way to include a Kconfig file for the external module This is where it gets pretty messy. You would also have a different configuration in the external module. I have no clear idea how that can work reasonably cleanly. If the solution becomes messy then I will just drop it. I do not see a big need here anyway. It will also create troubles: Can we modify .config etc. - Allow kbuild Makefiles to be named Kbuild, so local stuff can be in a file named Makefile file note: this can be achieved using makefile/Makefile today but it makes sense since there is not much 'Make' syntax left in kbuild makefiles today. The Makefile can already include both the kbuild and local stuff (same snippet I sent you in personal communication already): I know - but the incentive here was to seperate stuff out that does not belong in a Kbuild makefile. In 2.7 I may write a simple parser to create one single big Makefile, and then it will be good to have very simple Makefiles only. Now with mainline, when building external modules they will end up not having modversions. This is caused by the way .tmp_versions is handled, and is a real problem. There are two different ways how we are building external modules today: (1) after the kernel source tree was just compiled, so the kernel source tree still contains all the object files, (2) in a separate step, against an almost clean kernel source tree. Almost-clean means the tree contains a set of configuration files, and the modversions dump file. The modversions dump file elegantly solves both cases. You already convinced me about the usefullness of the modversions file. Can you try to make a patch that _only_ incorporate the modversions functionality. This we could ask Andrew to apply when reviewed. See it as first step. Then I will try to work out something for the functionality outlined before. Agree - should be easy to test using a CD. Are there an easy way to mount just a directory structure RO? Not sure what you mean exactly. My main motivation is this: we have a whole bunch of external modules that we build one after the other. Those external modules are notoriously nasty: We had cases where the modules fondled in kernel headers in the original tree. Of course then the next modules would build against a broken tree. To stop and detect such madness, I want to give modules a kernel source tree to which they have no write access, by chowning to a different user. Trees on read-only media are irrelevant IMHO. Actually we agree, I just did not think of chowing the files/dirs to catch the problems. Sam --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: External kernel modules, second try
On Sun, Mar 07, 2004 at 05:45:22PM +0100, Andreas Gruenbacher wrote: All in all, in the end I changed my mind. I now think that it's better to build modules against a clean kernel source tree that additionally has the modversions file copied in. This already works when using O=. With the SUBDIRS= approach, the kernel source tree must include a few compiled files (scripts/ stuff), and it cannot be read-only. I'm still undecided whether it makes sense to disallow the SUBDIRS= approach completely and only allow building with O=. (Note that this doesn't change the modversion dump file argument.) When building with SUBDIRS=, you ideally want a (read-only) kernel source tree that can adapt to different configurations (e.g., by doing like this: make -C $KERNEL_SOURCE modules SUBDIRS=$PWD FLAVOR=bigsmp This is already possible. You can do: make -C $KERNEL_SRC SUBDIRS=$PWD O=output-dir modules or with my proposed syntax: make -C $KERNEL_SRC M=$PWD O=output-dir The files relevant for the module will be located in the $PWD dir, since they use absolute paths. ), the default being the running kernel. I do not want to have potentially distro specific solutions. So it depends if we can find a solution that most will agree on. Sam --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Re: [RFC] External kernel modules
On Tue, Mar 09, 2004 at 12:22:04PM +0300, Sergey V. Udaltsov wrote: Hi all At some point, Andreas offered some patch to fix the broken build process for external modules (http://www.mail-archive.com/[EMAIL PROTECTED]/msg02079.html). What is the current status of this issue? We (Andreas and I) are working on it. I had some issues with his patch that I want to fix up. But my pay-the-bill job is demanding these days so slow progress only. The basic idea behind Andrea's patch will be used including the modversions file. I hope to have something ready during this week. But I hope to have a go-forward from Arjan and Andreas before sugmitting to Andrew. Sam --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] possible? building only one module
On Sun, Mar 21, 2004 at 09:44:50AM -0500, Joachim Förster wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! I am just a beginner with kbuild and I've got one question: I know that it is possible to make fs/fat/ to get the objects which are in this directory. But now I selected fat to be a module. Now the question: is it possible to say make fs/fat/ something to have this one module (fat.ko) being built. The above syntax will build fat as a module as well. But only the .o file, not the .ko file. Here you have to use 'make modules', which as a side-effect will make sure all other modules are up-to-date. Background: Is it even possible to extract the kernel source tree and then only build one selected module and its dependencies? No, not if your .config has more modules specified. Sam --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: architectures with their own config PCMCIA
On Wed, Aug 11, 2004 at 10:17:25PM +0200, Adrian Bunk wrote: On Sat, Aug 07, 2004 at 08:12:56PM +0200, Arnd Bergmann wrote: ... On Samstag, 7. August 2004 19:25, Adrian Bunk wrote: Is there eny reason for such options that are never visible nor enabled, or could they be removed? Yes, the reason is that some other options depend on them. We added the PCMCIA option to arch/s390/Kconfig to stop kbuild from asking about some drivers that won't work anyway. E.g. drivers/scsi/pcmcia starts with menu PCMCIA SCSI adapter support depends on SCSI!=n PCMCIA!=n MODULES which evaluate to true if the PCMCIA option is not known. Changing that to menu PCMCIA SCSI adapter support depends on SCSI PCMCIA MODULES solves this in a different way, but I'm not 100% sure if it still has the same meaning. Roman, is it intentional that PCMCIA!=n is true if there's no PCMCIA option, or is it simply a bug? Roman, a related Q. Why not error out, or at least warn when encountering an unknow symbol in a 'depends on' statement? I took a quick look, but did not initially see how to actually implemnt it. Considering something in the bottom of menu_finalize()? Sam --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Linking an external module with a pre-built external library
On Wed, Sep 29, 2004 at 04:17:17PM +, Harshad Toke wrote: Hi, I have a kernel module foo.o that needs to be linked with an existing lib.a. This library has been already built and should be used only at the link step of the external module. I could not find a way to achive this. If I specify something llike this : obj-m := foo.o foo-objs := foo1.c foo2.c lib/lib.a Then make fails giving an error ***no rule to make path/lib/lib.a Also tried with foo-y but was not successful. Any suggestions on how to achive this ? Rename your file to lib.a_shipped then kbuild should be happy. Sam --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Trivial patch to kernel/power/Kconfig
On Sat, Oct 16, 2004 at 09:25:48AM -0400, Jim Nelson wrote: Fixes misspelling in kernel/power/Kconfig in 2.6.9-rc4 diff -u kernel/power/Kconfig.orig kernel/power/Kconfig Hi Jim. Can you please resend everything to linux-kernel. There they will get proper peer-review - the audience here is limited. Keep it as one change/mail as you did so far. And if you forget a patch then include the changelog also in the second mail. That will make it much easier to apply the patch. If no one object I will take the patches after a day or two on linux-kernel. Sam --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Can't get make O= with external module to work
On Fri, Nov 05, 2004 at 10:04:15AM -0600, Timur Tabi wrote: I'm trying to compile an external module and use the O= kbuild option, but it's not working for me: make -C /usr/ammasso/src/sles9/2.6.5-32smp SUBDIRS=/home/ttabi/sb/starcore/software/host/linux/sys/devccil O=/home/ttabi/sb/starcore/software/host/linux/sys/devccil/obj_2.6.5-32smp_debug make[1]: Entering directory `/usr/ammasso/src/sles9/2.6.5-32smp' /usr/ammasso/src/sles9/2.6.5-32smp/Makefile:438: .config: No such file or directory When compiling modules O= is used to point out where output of the original kernel compile is placed - not where output for the external module is placed. So make -C $KERNELSRC O=$KERNELOUTPUT M=$PWD is the better syntax (M= and SUBDIRS= has same effect). KERNELSRC equals /usr/ammasso/src/sles9/2.6.5-32smp in your example KERNELOUTPUT equals ??? in your example You may say it is inconsistent, improvements are welcome. Sam --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] same name of a source file and kernel object
On Thu, Nov 04, 2004 at 04:54:54PM +0530, Anupam Kapoor wrote: hi all, we have bunch of source files making up linux-26 driver and we are using kbuild for creating the final kernel module. the problem is that the name for our kernel object (foo.ko) clashes with one of the sources (foo.c). kbuild barfs at this. changing the name of the kernel module, requires some un-needed changes our scripts, so if it can be avoided, it would be great. the question is: is it possible to have a kernel object called foo.ko when we already have a source file called foo.c ? Yes. And with no special magic. Please post your Makefile and I will take a look. Sam --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Can't get make O= with external module to work
On Sat, Nov 13, 2004 at 07:55:54PM -0600, Timur Tabi wrote: Sam Ravnborg wrote: Today it is not possible to tell kbuild to store output files in a different directory when building external modules. So for an external module located in .../external/foo output files for the module will be stored in ../external/foo no matter usage of O= I understand that now, and I think that needs to change. It's pretty low on my todo list. And first step is to find a suitable syntax for it. Patches is as always welcome. Sam --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] using $(src) in EXTRA_CFLAGS
On Tue, Nov 16, 2004 at 10:47:57PM -0600, Eric Sandeen wrote: I'm trying to make the XFS makefile work either embedded in the kernel tree at fs/xfs/Makefile, or as an out of tree makefile (make -C /path/to/kernel M=), and keep O= working properly as well. We currently have EXTRA_CFLAGS set in the fs/xfs/quota/Makefile, things like: EXTRA_CFLAGS += -I $(TOPDIR)/fs/xfs -I $(TOPDIR)/fs/xfs/linux-2.6 There is no need to specify full path. The kernel is always build with top of output tree as current directory so a much simpler version is enough: EXTRA_CFLAGS += -Ifs/xfs -Ifs/xfs/linux-2.6 Note: No space between -I and fs/ due to a kbuild limitation. When using O= kbuild will transform the above to: -Ifs/xfs -I$(srctree)/fs/xfs -Ifs/xfs/linux-2.6 -I$(srctree)/fs/xfs/linux-2.6 So we will find the right .h files. Sam --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] using $(src) in EXTRA_CFLAGS
On Wed, Nov 17, 2004 at 07:54:47AM -0600, Eric Sandeen wrote: Sam Ravnborg wrote: There is no need to specify full path. The kernel is always build with top of output tree as current directory so a much simpler version is enough: EXTRA_CFLAGS += -Ifs/xfs -Ifs/xfs/linux-2.6 But what about the case where I wish to use the same Makefile to work out of tree, where the xfs code is not embedded in fs/xfs? i.e. using the make -C /path/to/tree M=`pwd` modules method... Is cwd still the top of the tree? How then to specify path to the out-of-tree build? Then cwd will be same dir as where the Makefile is placed. So just make sure to use same directory structure for XFS no matter if it is in the kernel or outside the kernel. Sam --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] using if_changed with implicit rules
On Mon, Nov 29, 2004 at 03:36:52PM -0600, Eric Sandeen wrote: if I have something like: quiet_cmd_systune = SYSTUNE $ cmd_systune = $(dir $)/gen_systune.pl \ $ \ $(obj)/$(*F)_systunes.c \ $(obj)/$(*F)_systunes.h \ $(*F)_systunes %_systunes.c %_systunes.h: %_systunes.data $(src)/gen_systune.pl FORCE $(call if_changed,systune) I get my nice pretty-printed output for V=0. Always test with V=1 also! but the instructions for if_changed say that the targets must be listed in $(targets) or the target will always be built... can if_changed work together with an implicit rule? Yes, you just use: targets += $(wildcard %_systunes.c %_systunes.h) Sam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Compile external module with seperate source and object directories
On Wed, Jan 12, 2005 at 10:39:56PM -, Ross C Mcilroy wrote: The dependancies between these files and the created object files were handled using the VPATH variable in the previous makefile, however this doesn't seem to work with the 2.6 kernel (I assume because VPATH is already defined in the root kernel makefile). The linux kernel module make therefore doesn't find the required source files. Is this possible with the new external module build process? kbuild does not support storing output files in a separate directory for external modules so the answer is no. The request has been few - and the solution has not been obvoius. So there is niether plan to add this to kbuild. But if someone can come with a nice minimal patch it will be considered. Sam --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: changing local version requires full rebuild
Do you use echo -mylocalver localversion to change the local version? Sam No, I do makemenuconfig to edit the version. Is that right? That is fine too. When building - do you use separate output dir? Sam --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] sorting out the kerntypes mess
Hi Christoph The various dumping projects like lkcd and the s390 VM dump require debug information for the kernel, and they're using a mechanism that compiles a small file containing nothing but includes for interesting types into a Kerntypes file for the debugger. Unfortunately the various current ways to generate it are a little messy and thus we don't have support for it in mainline. As a clean way to implement it and supports multiple files that can be linked into Kerntypes (e.g. arch or subsystem-specific) I'd like to suggest the following additions to the kernel build system: kerntypes-y += object files KERNTYPEFLAGS += compile flags Which build all objects listed in kerntypes-y with the CFLAGS from KERNTYPEFLAGS (defaulting to CFLAGS) into a top-level Kerntypes file. First trying to understand exactly what you want. So you expect kerntypes-y := file.o to be present in one or a few places outside arch/ And then in one or a few files within arch/ the arch specific types are brought in with kerntypes-y := archfile.o And kbuild shall link the resuting files to a single kerntypes.o file to be located in the root of the kernel output dir. There are a few (solveable) issue with this. - kbuild needs to keep track of all kerntypes.y files. This is done for the kernel with a built-in.o file that links all .o files for a given dir and subdirs. In this was the final link is just a few built-in.o files (+ a bitmore). - Addind kerntypes-y would make kbuild infrastructure even more scary than today. There most be some very good reasons to add more complexity to the current implmentation. Maybe a simpler solution could be deployed: One file for all of the kernel located in kernel/kerntypes.o Then the arch makefile can link in their relevant files in a post processing step like when we build bzImage and the like. This requires much less support in common kbuild files. Unfortunately I'm a little lost in the current kbuild infrastructure so some help would be very welcome. If we can agree on something I will give it a try. Sam --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH] make 'make help' show all *config targets and update descriptions slightly.
On Mon, Jan 24, 2005 at 10:05:48PM +0100, Jesper Juhl wrote: make help doesn't show make randconfig nor make config as options and the description of oldconfig could be better (IMHO). Patch below adds the missing targets to the help and updates the description of oldconfig. Applied - the help for oldconfig definitely got better. Sam --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Cannot compile linux-2.4.29
On Sun, Feb 06, 2005 at 02:56:55PM -0800, David Butcher wrote: Hello, I am able to compile (and run) linux-2.4.27 successfully. I downloaded the soruce for linux-2.4.29 from www.kernel.org on Feb 6 2005 and unpacked it in a directory adjacent to the built\d directory for 2.4.27 All previous builds from www.kernel.org have built successfully. This build fails with what looks like a recursive call to a macro. I executed: make oldconfig make dep make Please save your .config, Do a make mrproper and follow the above stpes once more. That may very well cure it. Sam --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] How to convert a .o file to .ko module for 2.6 kernel
Hi, In Documentation/kbuild/ its only written how to make a .ko file from Source file.But i need to know to make a .ko file from a .o file not from source file. In modules.txt there is a section about including a .o file in a module. This is what you need. You cannot just randomly convert a .o file to a .ko file. Sam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Help in Makefile for Kernel module
Hi Suzzane However I would like to know if it is possible to have a Makefile inside the foobard directory that will link foobar1.o and foobar2.o into one say foobar.o and have the below line as: The lowest granularity the kbuild system works with is a module. So what you can do is to define a module in the foobard/ directory. Then you would stick a dependency on this module in your top-level module in maind/. The Makefile's would look like this: Makefile (stripped all the conditional stuff): obj-m := maind/ foobard/ foobard/Makefile: obj-m := foobard.o foobard-y := foobar1.o foobar2.o maind/Makefile: obj-m := main.o Sam --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Doubt what is the difference of compiling module in SuSE and Redhad , Mandrake
On Fri, May 06, 2005 at 12:27:12PM -0700, karthik wrote: Hi , Can anybody tell me what is the difference in compiling a module in SuSE distribution and other LInux distribution like Redhad or Mandrake. In 2.6 kernel a module compiled in one version(say 2.6.4) of SuSE is not loading in another version(say 2.6.8) of SuSE, even when we convert the module.o to module.ko in the latest version of SUSE. Please read Documentation/kbuild/modules.txt If you follow instructions herein you will no longer: convert module.o to module.ko. And as long as you do wrong stuff like that you are lucky that your module actually loaded with some kernel version. Sam --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RE: kbuild-devel digest, Vol 1 #594 - 4 msgs
On Mon, May 09, 2005 at 10:03:21AM -0700, karthik r wrote: Hi , But the problem with me is that we cannot release the source code. That does not in any way prevent you from creating a Makefile according to text in modules.txt? Or is it so that you only have access to the .o file and no access to source. If the altter is the case than you are in trouble and I doubt you will succeed. Sam --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: kconfig: trivial cleanup
On Thu, Jul 28, 2005 at 05:56:25PM +0200, [EMAIL PROTECTED] wrote: Replace all menu_add_prop mimicking menu_add_prompt with the latter func. I've had to add a return value to menu_add_prompt for one usage. I've rebuilt scripts/kconfig/zconf.tab.c_shipped by hand to reflect changes in the source (I've not the same Bison version so regenerating it wouldn't have been not a good idea), and compared it with what Roman itself did some time ago, and it's the same. So I guess this can be finally merged. I've applied the aptch - despite the strange formatting. See menu.c. Sam --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [RFD] kconfig - introduce cond-source
On Sun, Jul 31, 2005 at 02:50:03AM +0200, Roman Zippel wrote: Hi, On Sun, 31 Jul 2005, Sam Ravnborg wrote: In a couple of cases I have had the need to include a Kconfig file only if present. The current 'source' directive works as one would expect. It bails out if the file is missing. I don't really like it, it's an open invitation to abuse. I'd rather like to see the user first, which might need it. Understood. I will save this until I have a very good example where I need it. Sam --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] error about rp_filter
Hi Adrian. This is better suited for netdev, so I've forwarded your mail there. [It was originally sent to kbuild-devel] Sam On Fri, Aug 05, 2005 at 06:44:59PM +0300, Adrian Buciuman wrote: Hello, rp-filter is default off (see ip-sysctl.txt and proc.txt or test it), but comments in Documentation/Configure/help--- 2.4 kernels net/ipv4/Kconfig --- 2.6 kernels have led some (look at /etc/rc.d/rc.ip_forward on Slackware) to believe it is default on. Regards, Adrian Buciuman --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH 0/3] Link lxdialog with mconf directly
On Mon, Dec 12, 2005 at 01:41:59AM +0100, Petr Baudis wrote: The following series revives one three years old patch, turning lxdialog to a library and linking it directly to mconf, making menuconfig nicer and things in general quite simpler and cleaner. The first two patches make slight adjustements to kbuild in order to make liblxdialog possible. The third patch does the libification itself and appropriate modifications to mconf.c. Why not just copy over relevant files to scripts/kconfig? Then no playing tricks with libaries etc. is needed, and everythings just works. It is only 8 files and prefixing them with lx* would make them stand out compared to the rest. It is not like there is any user planned for the lxdialog functionality in the kernel, and kconfig users outside the kernel I beleive copy lxdialog with rest of kconfig files. Btw. the work you are doing are clashing with a general cleanup effort of lxdialog I have in -mm at the moment. I received only very limited feedback = looks ok. Integrating principles from your old patch was on my TODO list. I have something in the works that uses linked list instead of a preallocated array, to keep the dynamic behaviour. I will probarly make a version with the linked list approach but otherwise use your changes to mconf.c. But it will take a few days until I get to it. Sam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH 0/3] Link lxdialog with mconf directly
On Mon, Dec 12, 2005 at 09:08:17PM +0100, Petr Baudis wrote: It is only 8 files and prefixing them with lx* would make them stand out compared to the rest. It is not like there is any user planned for the lxdialog functionality in the kernel, and kconfig users outside the kernel I beleive copy lxdialog with rest of kconfig files. Ok. I didn't want to pollute scripts/kconfig/ too much, but if it's ok by you, I can do it that way. I will submit another series later in the evening. In the end this is Roman's call, not mine. Keeping the lxdialog functionality close to the users though makes total sense. We do not have to take special care of dependencies etc. Btw. the work you are doing are clashing with a general cleanup effort of lxdialog I have in -mm at the moment. I received only very limited feedback = looks ok. Integrating principles from your old patch was on my TODO list. Do you mean the series you posted at Nov 21? Should I just rebase my patches on top of that? Please do so. I did not post the biggest one where I Lindented all of lxdialog, but they are all in git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild.git FWIW, the changes there look fine to me. I actually wanted to change the indentation of the menus as well; it looks horrible especially in the singlemenu mode. I have something in the works that uses linked list instead of a preallocated array, to keep the dynamic behaviour. I will probarly make a version with the linked list approach but otherwise use your changes to mconf.c. But it will take a few days until I get to it. I can do it and include it in the updated series. Would be perfect! I will then do a proper review of next round of patches. Sam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH 0/3] Link lxdialog with mconf directly
On Mon, Dec 12, 2005 at 09:08:17PM +0100, Petr Baudis wrote: Ok. I didn't want to pollute scripts/kconfig/ too much, but if it's ok by you, I can do it that way. I will submit another series later in the evening. I've just done the renaming and relevant updates. So you will deal with much smaller patches. My kbuild tree is updated with the changes and will soon mirror out. Sam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: Does git belong in root's $PATH?
On Sat, Jan 07, 2006 at 10:31:52AM -0800, Linus Torvalds wrote: On Sat, 7 Jan 2006, walt wrote: When updated my kernel this morning, the same way I've been doing it for many months, I noticed that the -gxxx localversion string was missing from the new kernel's name. I finally figured out that this happened because /usr/local/bin is not in my root's $PATH, and the setlocalversion script depends on git. (The only thing I do as root is 'make install'). Ok, sounds like a build buglet to me. If you've done a make as a regular user, and just do a make install as root, I'd argue that the make install should do as little as humanly possible, and literally just install the kernel. If it starts changing the version, that sounds a bit fishy. Sam, anything we can do? Today kbuild uses same method to build KERNELRELEASE no matter what target is used, and I recently committed a change that used git tools as replacement for direct manipulation with .git/* What I did not realise was that we now require git during make install time - which is obviously plain wrong. I will try to look into a cleaner solution tomorrow where KERNELRELEASE is fetched somewhere else during make install time. That said: I suppose I'm asking a philosophical question here: do you guys install git where root can find it (as a system tool)? I don't, but I don't use make install anyway, I just do make modules_install. I install the kernel by hand, I always have. Of course, that's partly because I've always felt that make install does too much (I think make modules_install is better - it really only installs the already-built modules). The big difference here is that make modules_install is part of kbuild, whereas make install almost just call installkernel which is distribution specific - and the distributions does all sort of stuff in installkernel :-( Maybe it would be best to remove the vmlinux dependency from make install (so that make install will do exactly that: just install). I think all the documentation already tells you to do a make and then a make install. I had a short chat with David Miller about something similar. What I really liked to do was to tell user if vmlinux needed an update. But the implmentation of kbuild does make this almost impossible - I have at least not seen how to do it. When I during early 2.6.12 removed the dependency on vmlinux from the install target people were complaining that there scripts broke and the solution that was implmented was a new target: make kernel_install and make install got back the vmlinux dependency. Only difference between the two are that make kernel_install does NOT have vmlinux as prerequisite. This was btw only done for i386 and the only other architecture that have kernel_install is parisc with a vmlinux dependency. So no, I'm very unlikely to remove the vmlinux dependency from the make install target - it results in too many suprises. The other make targets really _are_ different: make fdimage depends on vmlinux, but that's because it literally just builds the image. make install is special. Sam, what say you? I forget what the kbuild mailing list is, but maybe you can forward this suggestion there.. These days it is named linux-kernel@vger.kernel.org ;-) kbuild-devel@lists.sourceforge.net is seldom used though I still monitor it. Talked with mec about discontinue it but he liked to keep it araound. He is btw still moderator on that list filtering away all spam. Sam --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: kbuild: Problem with latest GNU make rc
[linux-kernel added. Please keep both bug-make and linux-kernel] On Wed, Mar 01, 2006 at 10:46:25AM -0500, [EMAIL PROTECTED] wrote: Content-Description: message body text Hi all. I've set Reply-To: to the bug-make@gnu.org list; I'm hoping we can keep the discussion there since I don't subscribe to kbuild-devel. I'm working on getting the next release of GNU make, 3.81, out the door (amazing!) The weekend before last I released 3.81rc1 for people to test. A day or two ago, Art Haas [EMAIL PROTECTED] emailed me that he was having problems using kbuild with this version. The previous version, 3.81beta4, works fine. The symptoms are that much of the kernel was rebuilding over gain every time he ran make, even after he'd just done a top-down build. I pulled the 2.6.15 kernel and sure enough, I see the same behavior. I delved into the kbuild infrastructure and I found the problem. The kbuild system uses a trick to force rebuilds if the command line changes for a given target (normally make only rebuilds if the target is out of date--some versions of make, like Solaris make, have a .KEEP_STATE feature but GNU make does not support this). Here's a stripped-down example of what kbuild does: .PHONY: FORCE %.o : %.c FORCE $(if_changed_rule ...) if_changed_rule = $(if $(strip $? $(call arg-check, $(cmd_$(1)), $(cmd_$@)) ),\ @set -e; \ $(rule_$(1))) The FORCE prerequisite causes ALL .o targets that match this rule to be considered by make to be out of date (because FORCE is always out-of-date and it's a prerequisite of the .o). The trick is in the if_changed_rule macro: it tests whether any prerequisites have changed ($? is the changed prerequisites; it'll be empty if none have changed) and whether the command lines have changed (the call to arg-check). If those values are true (non-empty) it expands to the rule. Otherwise it expands to nothing. GNU make takes several shortcuts to provide efficiency in places where it doesn't matter, and so if it sees an empty command it doesn't try to run a shell. In this way, kbuild gets the benefit of checking the command line for every target without paying a price for useless shells being invoked during the build. However, this trick as implemented is accidentally relying on what may be a misbehavior on GNU make's part: one that was changed in the latest rc release. This is causing rebuilds to happen. In previous versions of GNU make, prerequisites that didn't exist were not included in the $? variable. In the new version that's been changed (fixed?) so that all out-of-date prerequisites are included in the $? variable, even if they don't exist. The old behavior allowed this rule to work, because even though FORCE was out-of-date and would normally always appear in $?, it didn't exist as a file and this exception caused it to be left out. So, the value of $? was empty in the old version if the only prerequisite that was considered out-of-date was the non-existent file FORCE. In the new version of GNU make, the value of $? is FORCE in that situation, so the test in if_changed_rule is always true and it always evaluates to the compile line, and rebuilds. Neither the GNU make manual nor the POSIX definition of make gives us clear direction as to the correct behavior in this particular situation. SuS says: $? The $? macro shall evaluate to the list of prerequisites that are newer than the current target. It shall be evaluated for both target and inference rules. The GNU make manual says: $? The names of all the prerequisites that are newer than the target, with spaces between them. So... is a non-existent file newer than the target? This specific situation is not addressed. However, other versions of make (SysV make for example) interpret a non-existent file as out-of-date and DO include it in $?. Given the meaning of newer than the current target to make (that it causes the target to be rebuilt) and the implied meaning of $? (a list of the prerequisites that cause the target to be rebuilt), I feel that the new behavior is correct and the old behavior is incorrect. So. If the change is correct, how should we proceed? Obviously it's not hard to change kbuild to fix the majority of the problem; replace the above macro with something like: if_changed_rule = $(if $(strip $(filter-out FORCE,$?) $(call arg-check, $(cmd_$(1)), $(cmd_$@)) ),\ @set -e; \ $(rule_$(1))) and all will be well. There are other, similar macros that need this change as well. And, there are other places where this $(filter-out FORCE,...) is already done, so it's apparently come up before. Current use of $(filter-out FORCE, ...) is always with $^ where FORCE correctly are included. I attach a patch here which makes this fix in kbuild. The above solution is
[kbuild-devel] Re: kbuild: Problem with latest GNU make rc
On Sun, Mar 05, 2006 at 05:21:08PM -0500, Paul D. Smith wrote: %% Sam Ravnborg [EMAIL PROTECTED] writes: sr I foresee a lot of mails to lkml the next year or more with this sr issue if kept. People do build older kernels and continue to do so sr the next long time. Especially the embedded market seem keen to sr stay at 2.4 (wonder why), and as such we will see many systems sr that keep older kernel src but never make behaviour. Well, this behavior doesn't exist in 2.4 kernels, since the kernel build in 2.4 was very different. Nevertheless there are plenty of 2.6 kernels out there :-). OK, I did not actually look at 2.4. But you are right that the build system has seen a few updates since then. sr Suggestion: sr We are now warned about an incompatibility in kbuild and we will sr fix this asap. But that you postpone this particular behaviour sr change until next make release. Maybe you add in this change as sr the first thing after the stable relase so all bleeding edge make sr users see it and can report issues. I am willing to postpone this change. However, I can't say how much of a window this delay will give you: I can say that it's extremely unlikely that it will be another 3 years before GNU make 3.82 comes out. One year would be good. The fixed kernel build will be available in an official kernel in maybe two or three months form now. With current pace we will have maybe 3 more kernel relase until this hits us. And only on bleeding edge machines. sr It is not acceptable that the kernel links each time we do a make. sr We keep track of a version number, we do partly jobs as root etc. sr So any updates on an otherwise build tree is a bug - and will be sr reported and has to get fixed. I've modified the kbuild system to collect .PHONY files into a variable, PHONY, and then used that in the if_changed* macros. Using this method I've determined that the new version of GNU make works exactly like the old version under various tests (build from scratch, rebuild without any changes, rebuild with simple changes, etc.) I've submitted a patch to linux-kernel implementing this change, with an appropriate Signed-off-by line. GNU make is used and abused in several ways in the kbuild files. If you found something prticular fishy then please let me know, there may well be better solutions for part of the build system that I am not aware of. Sam --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RE: Kconfig source syntax - how to add a prefix variable to the Kconfig source path ?
On Mon, Apr 10, 2006 at 03:30:26PM -0500, Karicheri, Muralidharan wrote: Hi, I am working to build a Kconfig based configuration menu and I need to include a prefix variable to source command. How do I do this? Kconfig-language.txt doesn't explain this. Your response will be highly appreciated... Not supported today. I recall I did this some time ago but that patch is long gone. It is trivially to add. Sam --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH] make: add modules_update target
On Fri, Apr 14, 2006 at 07:33:39PM -0500, Dustin Kirkland wrote: It looks like it may not be easy to drop in modules_update as a more efficient alternative to modules_install, but note that is not the patch that Kylie submitted... The problem to be solved is the long time it takes to do make modules_install when working on a single module. Instead of bringing in more or less complex solutions what about extending make dir/module.ko to include the installation of the module. Something like: make MI=1 dir/module.ko where MI=1 tells us to install the said module. I'm not particular found of the syntax - anyone with a better proposal? Untested sample patch below. Sam diff --git a/Makefile b/Makefile index fc8e08c..0c0649c 100644 --- a/Makefile +++ b/Makefile @@ -1312,6 +1312,11 @@ # Modules $(Q)$(MAKE) KBUILD_MODULES=$(if $(CONFIG_MODULES),1) \ $(build)=$(build-dir) $(@:.ko=.o) $(Q)$(MAKE) -rR -f $(srctree)/scripts/Makefile.modpost +ifneq ($(MI),) + cp $@ $(MODLIB)/kernel/$(dir $@) + if [ -r System.map -a -x $(DEPMOD) ]; then \ +$(DEPMOD) -ae -F System.map $(depmod_opts) $(KERNELRELEASE); fi +endif # FIXME Should go into a make.lib or something # === --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: [PATCH] make: add modules_update target
On Sat, Apr 15, 2006 at 11:02:08AM -0400, Theodore Ts'o wrote: On Sat, Apr 15, 2006 at 10:40:58AM +0200, Sam Ravnborg wrote: The problem to be solved is the long time it takes to do make modules_install when working on a single module. Instead of bringing in more or less complex solutions what about extending make dir/module.ko to include the installation of the module. Something like: make MI=1 dir/module.ko where MI=1 tells us to install the said module. Um, wouldn't that imply that either (a) the compile is being done as root, or (b) the /lib/modules/* is writeable by a non-root userid? I suppose the install command could be prefixed by sudo, but that seems awkward (and not everyone uses sudo). kbuild has support for the above scenario already - I just forgot. Say you are hacking ext3. Do a successfull make and install all modules. Manually remove the ext3 module from /lib/modules/... And use the external module support in kbuild like this: # Got to relevant directory $ cd fs/ext3 # To build the module: $ make -C ../.. M=`pwd` # To install the module: $ make -C ../.. M=`pwd` modules_install Sam --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 1/1] Minor changes to allow static analysis checkers besides sparse
On Tue, May 23, 2006 at 12:20:46PM -0500, Dustin Kirkland wrote: Minor changes to allow static analysis checkers besides sparse This patch allows CHECK and CHECKFLAGS to be passed in on the make invocation, such that one could specify a checker other than sparse, and/or different flags. This is alread possible. Try make C=1 CHECK=checker_executable CHECKFLAGS= from your example and see that it works. The assignment: foo := bar will be overrided if you do: make foo=viggo But it will not be overridded if you have foo=sammy in your environment. Sam --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] RFC - kconfig date must die
On Mon, Jun 26, 2006 at 04:04:24PM -0600, Jim Cromie wrote: IOW: can we switch the default of CONFIG_NODATESTAMP ? Clearly, somebody has already thought about stripping the date from .configs, but it seems to me that this has been forgotten, and warrants a fresh look. - I searched http://marc.theaimsgroup.com/?l=kbuild-develr=1b=200604w=2 for CONFIG_NODATESTAMP, got *no* hits. How long ago was this added ? Try searching linux-kernel. And at linux-kernel try to locate: [rfc] Compressing those annoying .configs which is a nice tool for reporting your .config compressed and readable. That said it is hard to realise what real-life problem you try to solve. Sam Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 1/1] Minor changes to allow static analysis checkers besides sparse
On Tue, May 23, 2006 at 03:57:23PM -0500, Dustin Kirkland wrote: On Tue, 2006-05-23 at 22:17 +0200, Sam Ravnborg wrote: On Tue, May 23, 2006 at 12:20:46PM -0500, Dustin Kirkland wrote: Minor changes to allow static analysis checkers besides sparse This patch allows CHECK and CHECKFLAGS to be passed in on the make invocation, such that one could specify a checker other than sparse, and/or different flags. This is alread possible. Try make C=1 CHECK=checker_executable CHECKFLAGS= from your example and see that it works. No kidding, yep...I just tried that and it worked like a charm. Thanks. The inline documentation was misleading. How about this simple patch to more clearly enunciate this in the inline Makefile documentation? Look good, applied. Sam Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Converter from Config.in to Kconfig
On Mon, Apr 10, 2006 at 03:33:16PM -0500, Karicheri, Muralidharan wrote: Is there a generic script to convert from Config.in format to Kconfig format? I have a build system which was based on old Config.in and needs a converter badly. If you search this list or linux-kernel you will find the converter that Roman Zippel created to deal with this. It was not perfect and the resulting Kconfig files needed a few tweaks before they were OK - but it was a great help. Sam - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Kconfig source syntax - how to add a prefix variable to the Kconfig source path ?
I am working to build a Kconfig based configuration menu and I need to
include a prefix variable
to source command. How do I do this? Kconfig-language.txt doesn't
explain this. Your
response will be highly appreciated...
Not supported today.
I recall I did this some time ago but that patch is long gone.
It is trivially to add.
Found my old patch...
It is one year old or more so may not apply cleanly.
Sam
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index ccd4513..4be63d9 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -44,7 +44,7 @@ static void conf_warning(const char *fmt
conf_warnings++;
}
-static char *conf_expand_value(const char *in)
+char *conf_expand_value(const char *in)
{
struct symbol *sym;
const char *src;
diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
index 527f60c..95b7f44 100644
--- a/scripts/kconfig/lkc.h
+++ b/scripts/kconfig/lkc.h
@@ -61,7 +61,7 @@ char *zconf_curname(void);
/* confdata.c */
extern const char conf_def_filename[];
-
+char *conf_expand_value(const char*);
char *conf_get_default_confname(void);
/* kconfig_load.c */
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index cfa4607..ba55e87 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -293,14 +293,14 @@ void zconf_initscan(const char *name)
void zconf_nextfile(const char *name)
{
- struct file *file = file_lookup(name);
+ struct file *file = file_lookup(conf_expand_value(name));
struct buffer *buf = malloc(sizeof(*buf));
memset(buf, 0, sizeof(*buf));
current_buf-state = YY_CURRENT_BUFFER;
- yyin = zconf_fopen(name);
+ yyin = zconf_fopen(file-name);
if (!yyin) {
- printf(%s:%d: can't open file \%s\\n, zconf_curname(),
zconf_lineno(), name);
+ printf(%s:%d: can't open file \%s\\n, zconf_curname(),
zconf_lineno(), file-name);
exit(1);
}
yy_switch_to_buffer(yy_create_buffer(yyin, YY_BUF_SIZE));
@@ -308,11 +308,11 @@ void zconf_nextfile(const char *name)
current_buf = buf;
if (file-flags FILE_BUSY) {
- printf(recursive scan (%s)?\n, name);
+ printf(recursive scan (%s)?\n, file-name);
exit(1);
}
if (file-flags FILE_SCANNED) {
- printf(file %s already scanned?\n, name);
+ printf(file %s already scanned?\n, file-name);
exit(1);
}
file-flags |= FILE_BUSY;
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
kbuild-devel mailing list
kbuild-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Problems with Kconfig
On Wed, Sep 13, 2006 at 03:57:11PM +0100, [EMAIL PROTECTED] wrote: Hello, I'm using gcc-2.95.3, libc2.2. I've using kernel 2.6.10 for quite a long time now, though it may have been after some upgrading that I cannot compile it anylonger. I have my own built linux system, and almost last versions of software (despite of the veryold compiler version), so I don't know where the problem is. Appart from some software packages whose programmers seems to like being out of c standards, I don't use to have a single problem compiling anything. The last I remember to have upgraded is ncurses to it's last version at the time of this writting (5.5), although as you could see bellow, the problem comes from the parser for the menus (scripts/kconfig/conf), yacc or bison files. I just wonder if anybody can tell me something about. What you see is the output after untarring the kernel tree, and copying ../.config to ./.config. Though I cannot make oldconfig, menconfig, or anythingelse. Kind Regards, [EMAIL PROTECTED] make CHK include/linux/version.h UPD include/linux/version.h SYMLINK include/asm - include/asm-i386 HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/split-include HOSTCC scripts/basic/docproc SHIPPED scripts/kconfig/zconf.tab.h HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/mconf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf -s arch/i386/Kconfig arch/i386/kernel/cpu/cpufreq/Kconfig:238: 'endmenu' in different file than 'menu' arch/i386/kernel/cpu/cpufreq/Kconfig:238: location of the 'menu' This looks strange. Primary suspect is a bad Kconfig file. A simple check would be to fire up mconf on a smaller Kconfig file. Try: rm .config touch .config scripts/kconfig/mconf init/Kconfig This should spit out a few warnings about an unknown symbol being selected, but otherwise it should look ok. If this fails then something more subtle is going on.. I assume you have tried to rebuild your kernel from scratch?? Sam - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH 1/4] kconfig: implement setter/getter functions and change callback for sym_change_count
On Fri, Oct 06, 2006 at 08:44:29PM +0200, Karsten Wiese wrote: Just gave it a try and stumbled over already existing sym_set_changed(). find output (see below) shows the most hits for sym_change_count in confdata.c. So how about replacing sym_change_count by bool conf_dirty and adding bool conf_get_dirty(void), void conf_set_dirty(bool) Naming is always of difficult... In kconfig we use changed when somethign is changed - we do not use dirty. And sym refers to a symbol - so that is not adequate. conf refer to a full config (at least in some cases). So I would suggest: bool conf_changed(void) void conf_set_changed() or something like that. Sam - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] [PATCH] kbuild: move tags from ARCH and include/ ahead of drivers
On Thu, Jan 04, 2007 at 10:14:52AM -0800, Don Mullis wrote: Move tags extracted from the ARCH and include/ sub-trees ahead of those from device drivers, so that the former will appear first during searches. Saves user time during interactive searches for certain patterns that happen to find unwanted matches in driver files. Example in emacs: M-x find-tag PAGE_SIZE M-1 M-. (repeated until definition from asm-i386/page.h appears) Signed-off-by: Don Mullis [EMAIL PROTECTED] Applied, thanks. Sam - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] thoughts on an official Kconfig maturity option
On Thu, Apr 12, 2007 at 11:35:21AM -0400, Robert P. J. Day wrote: rather than post to the LKML, is this the right forum to ask about implementing an actual maturity directive in the build infrastructure? thanks. Hi rday. No this is not the right forum for this question - lkml is a much better forum due to the wider audience. Today we have a number of related config's: BROKEN, BROKEN_ON_SMP EXPERIMENTAL Reality tells us that the Code maturity level configs are often mis maintained. As an example many drivers tagged EXPERIMENTAL are used in production environments and distributions often define EXPERIMENTAL. And the actual value of more fine grained maturity level is questionable. It needs to be used consistently or it will not be of any real value. And we cannot make thet work with the single EXPERIMENTAL so making it more fine-tuned will have little possibility for success. Sam - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] make install with nfs root_squash
On Wed, Apr 18, 2007 at 03:27:53PM -0400, Frank Mori Hess wrote: Hi, I'm encountering some annoyances building (out-of-tree) modules on an NFS filesystem. The NFS filesystem is exported with the default root_squash option. When I build as a normal user, then su to root to do the final make modules_install, it fails with permission denied. For example, modules_install tries to delete all the files in the .tmp_versions subdirectory, or tries to write to Module.symvers, but the nfs root_squash prevents root from having any special write permissions. I've verified this problem with 2.6.18 and 2.6.20 kernels. It didn't happen with the old kernel I was using (2.6.8). Is there any reason that a make modules_install has to modify files in the source tree? This should not happen. (I do not know the root_squash option but that should not matter). Can you please try: make V=1 modules_install and post the output. Sam - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] make install with nfs root_squash
On Thu, Apr 19, 2007 at 10:59:23AM -0400, Frank Mori Hess wrote: On Wednesday 18 April 2007 16:39 pm, you wrote: Is there any reason that a make modules_install has to modify files in the source tree? This should not happen. (I do not know the root_squash option but that should not matter). Can you please try: make V=1 modules_install and post the output. Oops, it turns out the problem was actually occurring during make modules not make modules_install. I'm calling kbuild through some autoconf generated Makefiles, and autoconf always wants the install target to depend on the all target. This results in the kernel's make modules getting re-run as root before make modules_install. This fails due to the .tmp_versions and similar getting unconditionally rebuilt during make modules (output attached). I've worked around it by having the autoconf make all target ignore errors from the invocation of the kernel's make modules. OK - thanks for reporting back the real issue. Sam - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Override autoconf.h fixdep intelligence
On Tue, Apr 24, 2007 at 04:15:54PM +1000, John Williams wrote: Hello, Is there a sensible way of forcing a .c file to be explicitly dependent on autoconf.h, thus bypassing the CONFIG_ dependency intelligence built into fixdep? The easy trick is to add an explicit dependency on .config like this: $(obj)/foobar.o: .config We use a similar way of doing things in kernel/Makefile whre we parse up the content of the .config file. That said I would question your use of CONFIG variables but without knowing the actual context it is hard to see why such obsfucating is needed. Sam - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
Re: [kbuild-devel] Building out of a different source branch
On Thu, May 03, 2007 at 10:47:48AM -0700, H. Peter Anvin wrote: Hello, I would like to get rid of arch/x86_64/boot, which *should* be binary identical with arch/i386/boot (it's not right now, but I'm fixing that.) Is there a way to make Kbuild decend so that src=arch/i386/boot but obj=arch/x86_64/boot (which may entail having to create directories even when not compiling with O=?) It seems the infrastructure is already there. There is no way to do that today - despite some part of the infrastructure is prepared as you have noticed. Would it be OK if we have arch/x86_64/boot present and have stub Makefiles in all directories? If thats OK I can try to cook up something. It has been discussed to put all common stuff in arch/x86 which would anyway call for a generic solution. For kbuild it does not matter if src shall be located in i386 or x86 directory structure. Sam - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ kbuild-devel mailing list kbuild-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] [PATCH 1/2] kbuild: prepare for using code from different dir
To introduce support for source in one directory but output files
in another directory during a non O= build prefix all paths
with $(src) repsectively $(obj).
Signed-off-by: Sam Ravnborg [EMAIL PROTECTED]
---
This will likely appear in my kbuild.git tree but only
when next mergewindow opens I think.
My current batch (35 commits) has not yet been pulled
and this would no see exposure in -mm first.
I have compiled i386 + x86_64 in an allmodconfig with
no problems so the common stuff works.
Sam
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index e2ad2dc..a525112 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -131,13 +131,13 @@ $(multi-objs-y:.o=.lst) : modname = $(modname-multi)
quiet_cmd_cc_s_c = CC $(quiet_modtag) $@
cmd_cc_s_c = $(CC) $(c_flags) -fverbose-asm -S -o $@ $
-%.s: %.c FORCE
+$(obj)/%.s: $(src)/%.c FORCE
$(call if_changed_dep,cc_s_c)
quiet_cmd_cc_i_c = CPP $(quiet_modtag) $@
cmd_cc_i_c = $(CPP) $(c_flags) -o $@ $
-%.i: %.c FORCE
+$(obj)/%.i: $(src)/%.c FORCE
$(call if_changed_dep,cc_i_c)
quiet_cmd_cc_symtypes_c = SYM $(quiet_modtag) $@
@@ -146,7 +146,7 @@ cmd_cc_symtypes_c = \
| $(GENKSYMS) -T $@ /dev/null; \
test -s $@ || rm -f $@
-%.symtypes : %.c FORCE
+$(obj)/%.symtypes : $(src)/%.c FORCE
$(call if_changed_dep,cc_symtypes_c)
# C (.c) files
@@ -198,14 +198,13 @@ define rule_cc_o_c
endef
# Built-in and composite module parts
-
-%.o: %.c FORCE
+$(obj)/%.o: $(src)/%.c FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
# Single-part modules are special since we need to mark them in $(MODVERDIR)
-$(single-used-m): %.o: %.c FORCE
+$(single-used-m): $(obj)/%.o: $(src)/%.c FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
@{ echo $(@:.o=.ko); echo $@; } $(MODVERDIR)/$(@F:.o=.mod)
@@ -215,7 +214,7 @@ quiet_cmd_cc_lst_c = MKLST $@
$(CONFIG_SHELL) $(srctree)/scripts/makelst $*.o \
System.map $(OBJDUMP) $@
-%.lst: %.c FORCE
+$(obj)/%.lst: $(src)/%.c FORCE
$(call if_changed_dep,cc_lst_c)
# Compile assembler sources (.S)
@@ -229,13 +228,13 @@ $(real-objs-m:.o=.s): modkern_aflags := $(AFLAGS_MODULE)
quiet_cmd_as_s_S = CPP $(quiet_modtag) $@
cmd_as_s_S = $(CPP) $(a_flags) -o $@ $
-%.s: %.S FORCE
+$(obj)/%.s: $(src)/%.S FORCE
$(call if_changed_dep,as_s_S)
quiet_cmd_as_o_S = AS $(quiet_modtag) $@
cmd_as_o_S = $(CC) $(a_flags) -c -o $@ $
-%.o: %.S FORCE
+$(obj)/%.o: $(src)/%.S FORCE
$(call if_changed_dep,as_o_S)
targets += $(real-objs-y) $(real-objs-m) $(lib-y)
@@ -246,7 +245,7 @@ targets += $(extra-y) $(MAKECMDGOALS) $(always)
quiet_cmd_cpp_lds_S = LDS $@
cmd_cpp_lds_S = $(CPP) $(cpp_flags) -D__ASSEMBLY__ -o $@ $
-%.lds: %.lds.S FORCE
+$(obj)/%.lds: $(src)/%.lds.S FORCE
$(call if_changed_dep,cpp_lds_S)
# Build the compiled-in targets
diff --git a/scripts/Makefile.host b/scripts/Makefile.host
index 575afbe..6943a7a 100644
--- a/scripts/Makefile.host
+++ b/scripts/Makefile.host
@@ -114,7 +114,7 @@ hostcxx_flags = -Wp,-MD,$(depfile) $(__hostcxx_flags)
quiet_cmd_host-csingle = HOSTCC $@
cmd_host-csingle = $(HOSTCC) $(hostc_flags) -o $@ $ \
$(HOST_LOADLIBES) $(HOSTLOADLIBES_$(@F))
-$(host-csingle): %: %.c FORCE
+$(host-csingle): $(obj)/%: $(src)/%.c FORCE
$(call if_changed_dep,host-csingle)
# Link an executable based on list of .o files, all plain c
@@ -123,14 +123,14 @@ quiet_cmd_host-cmulti = HOSTLD $@
cmd_host-cmulti = $(HOSTCC) $(HOSTLDFLAGS) -o $@ \
$(addprefix $(obj)/,$($(@F)-objs)) \
$(HOST_LOADLIBES) $(HOSTLOADLIBES_$(@F))
-$(host-cmulti): %: $(host-cobjs) $(host-cshlib) FORCE
+$(host-cmulti): $(obj)/%: $(host-cobjs) $(host-cshlib) FORCE
$(call if_changed,host-cmulti)
# Create .o file from a single .c file
# host-cobjs - .o
quiet_cmd_host-cobjs = HOSTCC $@
cmd_host-cobjs = $(HOSTCC) $(hostc_flags) -c -o $@ $
-$(host-cobjs): %.o: %.c FORCE
+$(host-cobjs): $(obj)/%.o: $(src)/%.c FORCE
$(call if_changed_dep,host-cobjs)
# Link an executable based on list of .o files, a mixture of .c and .cc
@@ -140,20 +140,20 @@ quiet_cmd_host-cxxmulti = HOSTLD $@
$(foreach o,objs cxxobjs,\
$(addprefix $(obj)/,$($(@F)-$(o \
$(HOST_LOADLIBES) $(HOSTLOADLIBES_$(@F))
-$(host-cxxmulti): %: $(host-cobjs) $(host-cxxobjs) $(host-cshlib) FORCE
+$(host-cxxmulti): $(obj)/%: $(host-cobjs) $(host-cxxobjs) $(host-cshlib) FORCE
$(call if_changed,host-cxxmulti)
# Create .o file from a single .cc (C++) file
quiet_cmd_host-cxxobjs = HOSTCXX $@
cmd_host-cxxobjs = $(HOSTCXX) $(hostcxx_flags) -c -o $@ $
-$(host-cxxobjs
[kbuild-devel] [PATCH 2/2] newsetup: let x86_64 and i386 share same Makefile
Using the possibility to assing src to another dir we can now share the same code for i386 and x86_64 with output files located in the dir of the architecture. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] --- We could have avoided the arch/x86_64/boot/Makefile by changes all $(MAKE) invocations from arch/x86_64/Makefile but addind an almost empty Makefile seemed to be less 'magic'. Sam i386/boot/Makefile | 23 +++ x86_64/boot/Makefile | 163 +-- 3 files changed, 18 insertions(+), 172 deletions(-) diff --git a/arch/i386/boot/Makefile b/arch/i386/boot/Makefile index 4ebdc68..0a812ef 100644 --- a/arch/i386/boot/Makefile +++ b/arch/i386/boot/Makefile @@ -1,9 +1,5 @@ # -# arch/i386/boot/Makefile -# -# This file is subject to the terms and conditions of the GNU General Public -# License. See the file COPYING in the main directory of this archive -# for more details. +# Makefile for boot part of x86 # # Copyright (C) 1994 by Linus Torvalds # @@ -37,7 +33,10 @@ setup-y += printf.o string.o tty.o video.o version.o voyager.o setup-y+= video-vga.o setup-y+= video-vesa.o -hostprogs-y:= tools/build +targets += $(setup-y) + +buildtool := tools/build +hostprogs-y:= $(buildtool) HOSTCFLAGS_build.o := $(LINUXINCLUDE) @@ -46,8 +45,9 @@ HOSTCFLAGS_build.o := $(LINUXINCLUDE) # How to compile the 16-bit code. Note we always compile for -march=i386, # that way we can complain to the user if the CPU is insufficient. CFLAGS := $(LINUXINCLUDE) -g -Os -D_SETUP \ - -march=i386 -mregparm=3 -fno-strict-aliasing \ - $(call cc-option, -ffreestanding) + -m32 -march=i386 -mregparm=3 -fno-strict-aliasing \ + $(call cc-option, -ffreestanding) \ + $(call cc-option, -fno-stack-protector) AFLAGS := $(CFLAGS) -D__ASSEMBLY__ $(obj)/zImage: IMAGE_OFFSET := 0x1000 @@ -57,11 +57,11 @@ $(obj)/bzImage: EXTRA_AFLAGS := $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__ $(obj)/bzImage: BUILDFLAGS := -b quiet_cmd_image = BUILD $@ -cmd_image = $(obj)/tools/build $(BUILDFLAGS) $(obj)/setup.bin \ +cmd_image = $(obj)/$(buildtool) $(BUILDFLAGS) $(obj)/setup.bin \ $(obj)/vmlinux.bin $(ROOT_DEV) $@ $(obj)/zImage $(obj)/bzImage: $(obj)/setup.bin \ - $(obj)/vmlinux.bin $(obj)/tools/build FORCE + $(obj)/vmlinux.bin $(obj)/$(buildtool) FORCE $(call if_changed,image) @echo 'Kernel: $@ is ready' ' (#'`cat .version`')' @@ -154,4 +154,5 @@ zlilo: $(BOOTIMAGE) if [ -x /sbin/lilo ]; then /sbin/lilo; else /etc/lilo/install; fi install: - sh $(srctree)/$(src)/install.sh $(KERNELRELEASE) $(BOOTIMAGE) System.map $(INSTALL_PATH) + sh $(srctree)/$(src)/install.sh \ + $(KERNELRELEASE) $(BOOTIMAGE) System.map $(INSTALL_PATH) diff --git a/arch/x86_64/boot/Makefile b/arch/x86_64/boot/Makefile index f5c500d..6d8afcb 100644 --- a/arch/x86_64/boot/Makefile +++ b/arch/x86_64/boot/Makefile @@ -1,161 +1,6 @@ # -# arch/x86_64/boot/Makefile +# boot infrastructure shared with i386 +# Use src from i386 but locate all object files here # -# This file is subject to the terms and conditions of the GNU General Public -# License. See the file COPYING in the main directory of this archive -# for more details. -# -# Copyright (C) 1994 by Linus Torvalds -# - -# ROOT_DEV specifies the default root-device when making the image. -# This can be either FLOPPY, CURRENT, /dev/ or empty, in which case -# the default of FLOPPY is used by 'build'. - -ROOT_DEV := CURRENT - -# If you want to preset the SVGA mode, uncomment the next line and -# set SVGA_MODE to whatever number you want. -# Set it to -DSVGA_MODE=NORMAL_VGA if you just want the EGA/VGA mode. -# The number is the same as you would ordinarily press at bootup. - -SVGA_MODE := -DSVGA_MODE=NORMAL_VGA - -# If you want the RAM disk device, define this to be the size in blocks. - -#RAMDISK := -DRAMDISK=512 - -targets:= vmlinux.bin setup.bin setup.elf zImage bzImage -subdir-:= compressed - -Setup-y+= a20.o apm.o cmdline.o copy.o cpu.o edd.o -Setup-y+= header.o main.o mca.o memory.o pm.o pmjump.o -Setup-y+= printf.o string.o tty.o video.o version.o voyager.o - -# The link order of the video-*.o modules can matter. In particular, -# video-vga.o *must* be listed first. -Setup-y+= video-vga.o -Setup-y+= video-vesa.o - -setup-y= $(addprefix ../../i386/boot/, $(Setup-y)) - -buildtool := ../../i386/boot/tools/build -hostprogs-y:= $(buildtool) - -HOSTCFLAGS_build.o := $(LINUXINCLUDE) - -# --- - -# How to compile the 16-bit code. Note we always compile for -march=i386
