kbuild-devel Mailing List for kbuild - Linux Kernel Build (Archive)

Hello everybody!

As you know there is a great script "merge_config.sh". It allows to
override a predefined set of .config keys with the values stored in a
file.

For example:

scripts/kconfig/merge_config.sh -m -r .config
~/kernel/conf_mixins/.config_deb

Now, I want to turn on all of the options in the "Kernel Hacking"
submenu and save only that options to a separate file ".config_deb". But
how can I do this? I see three options:

1) Do it manually checking the match between every option title in
"Kernel Hacking" submenu and a key in .config. It is a hard way.

2) Turn off all debug options. Save them in one file. Turn on all debug
options and save them to other file. Then make diff on these two files,
format it and save to .config_deb. It is a better way, but not ideal.

Is there any other ways to handle this task?

Thanks in advance,
Roman Storozhenko

 HOSTCC  scripts/sign-file In file included from
 scripts/sign-file.c:46:0: /usr/include/openssl/cms.h:62:2: error: #error CMS
 is disabled.  #error CMS is disabled.   ^ scripts/Makefile.host:91: recipe
 for target 'scripts/sign-file' failed make[1]: *** [scripts/sign-file] Error
 1 Makefile:567: recipe for target 'scripts' failed make: *** [scripts] Error
 2

Fix SSL headers so that the kernel can build with LibreSSL
---
 scripts/sign-file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/sign-file.c b/scripts/sign-file.c
index 250a7a6..a0b806d 100755
--- a/scripts/sign-file.c
+++ b/scripts/sign-file.c
@@ -39,7 +39,7 @@
  * signing with anything other than SHA1 - so we're stuck with that if
such is
  * the case.
  */
-#if OPENSSL_VERSION_NUMBER < 0x10000000L
+#if (OPENSSL_VERSION_NUMBER < 0x10000000L || LIBRESSL_VERSION_NUMBER)
 #define USE_PKCS7
 #endif
 #ifndef USE_PKCS7
--
2.7.0

Hi guys
         Thank you in advance for reading my email.
I'm working on a project that will use kbuild system, I know that kbuild system is open source, so my questions are below:

1.       Can I only open the kbuild system source,  not open our own source code?

2.       Kbuild system always generate one header file "autoconf.h",  can we use the autoconf.h but not open our source code?

I would appreciate if you have any reply.


Thanks & Best Regards
Chen Junjie

On Thu, Dec 16, 2010 at 05:36:32PM +0200, Debarshi Ray wrote:
> I am trying to build a set of drivers present in the s2-liplianin [1]
> tree against Ubuntu's 2.6.35 so that I can use the drivers separately.
> So I put the s2-liplianin tree in the ~/s2-liplianin directory and
> did:
> make -C /lib/modules/$(uname -r)/build M=$(pwd)/linux/drivers/media
> CONFIG_DVB_MANTIS=m modules
> 
> The build fails for those Makefiles which use EXTRA_CFLAGS to add some
> include paths. eg., linux/drivers/media/video/Makefile has:
> EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
> EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
> EXTRA_CFLAGS += -Idrivers/media/common/tuners
> 
> Here is what I get when the build fails:
> /home/fs/dray/s2-liplianin/linux/drivers/media/video/tuner-core.c:25:20:
> error: mt20xx.h: No such file or directory
> /home/fs/dray/s2-liplianin/linux/drivers/media/video/tuner-core.c:26:21:
> error: tda8290.h: No such file or directory
> /home/fs/dray/s2-liplianin/linux/drivers/media/video/tuner-core.c:27:21:
> error: tea5761.h: No such file or directory
> 
> All those files are present in those include paths added to EXTRA_CFLAGS above.
> 
> I can see the s2-liplianin tree, like the other Mercurial trees of the
> LinuxTV folks, do not look the usual Git trees from kernel.org. Is
> that the reason for this problem?
> 
> Any suggestions on how to debug this?
> 
> Thanks,
> Debarshi
> 
> [1] http://mercurial.intuxication.org/hg/s2-liplianin

Please repost your question at lin...@vg....
The old list at sourceforge is dead.

	Sam

I am trying to build a set of drivers present in the s2-liplianin [1]
tree against Ubuntu's 2.6.35 so that I can use the drivers separately.
So I put the s2-liplianin tree in the ~/s2-liplianin directory and
did:
make -C /lib/modules/$(uname -r)/build M=$(pwd)/linux/drivers/media
CONFIG_DVB_MANTIS=m modules

The build fails for those Makefiles which use EXTRA_CFLAGS to add some
include paths. eg., linux/drivers/media/video/Makefile has:
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
EXTRA_CFLAGS += -Idrivers/media/common/tuners

Here is what I get when the build fails:
/home/fs/dray/s2-liplianin/linux/drivers/media/video/tuner-core.c:25:20:
error: mt20xx.h: No such file or directory
/home/fs/dray/s2-liplianin/linux/drivers/media/video/tuner-core.c:26:21:
error: tda8290.h: No such file or directory
/home/fs/dray/s2-liplianin/linux/drivers/media/video/tuner-core.c:27:21:
error: tea5761.h: No such file or directory

All those files are present in those include paths added to EXTRA_CFLAGS above.

I can see the s2-liplianin tree, like the other Mercurial trees of the
LinuxTV folks, do not look the usual Git trees from kernel.org. Is
that the reason for this problem?

Any suggestions on how to debug this?

Thanks,
Debarshi

[1] http://mercurial.intuxication.org/hg/s2-liplianin

-- 
The camera is to the brush what Java is to assembly.
   -- Sougata Santra

On Sunday 05 December 2010, Greg Heinrich wrote:
> I would like to know if there is an easy way to create a
> linux-headers-xxx package out of my own kernel tree? What I'm looking
> for is something similar to e.g. the Debian package
> linux-headers-2.6.32-5-r4k-ip22. This does not have to be a Debian
> package by the way, a simple tgz would do.
> 
> The reason I want to create that kind of package is I need to be able
> to share my kernel configuration and headers so that a colleague would
> then be able to build external kernel modules for my kernel image.

I don't think there is any easy way for this. The best way to do what
you want is to get the drivers upstream and build everything as part
of the regular kernel build process. If the code quality is not up
to the mainline standards, please have a look at the procedure for
getting it into drivers/staging.

	Arnd

Hello,
apologies if this has been asked before but I couldn't find the answer
in the archives.

I would like to know if there is an easy way to create a
linux-headers-xxx package out of my own kernel tree? What I'm looking
for is something similar to e.g. the Debian package
linux-headers-2.6.32-5-r4k-ip22. This does not have to be a Debian
package by the way, a simple tgz would do.

The reason I want to create that kind of package is I need to be able
to share my kernel configuration and headers so that a colleague would
then be able to build external kernel modules for my kernel image.

I tried "make headers_install_all" but it does not export the Kernel
config and Module.symvers, ...

Note that in case it makes any difference, I am working on the ARM
architecture, and I want to support CONFIG_MODVERSIONS=y.

I thank you in advance,

Regards,
Greg.

Dear Paul,

the mailing list kbu...@li... is inactive.

Please head to VGER.kernel.org for the currently-active list.

http://vger.kernel.org/vger-lists.html#linux-kbuild

thanks,
Bernhard

Hi all.  I'm trying to build an out-of-tree module, which actually has
configuration associated with it (it has a Kconfig file and
everything--although that doesn't help me for out-of-tree builds of
course).

I have my own makefile which invokes the appropriate kbuild-based make
(setting O= etc. on the command line).  I know what configure options I
want to set as well.

So, I wanted to figure out how just pass a couple of -DCONFIG_...=... on
the kbuild make command line such that they would be added to the
compile line of my out-of-tree modules.  Unfortunately I can't use
EXTRA_CFLAGS (easily) because the out-of-tree module Makefile sets some
flags in EXTRA_CFLAGS itself.  All things being equal I'd prefer not to
change the module code, or have to duplicate those flags on my
invocation line.


In normal make, the CPPFLAGS variable contains C preprocessor options
and is included in each compile line automatically.  I can see that
kbuild supports EXTRA_CPPFLAGS and cppflags-y etc. but these seem to
have a different purpose; anyway they don't appear on any normal compile
line.  Is this an oversight?  What are these cppflags variables intended
for?  I'm having a hard time finding where they are used.


I also see that I can set KCPPFLAGS on the command line and that works,
although I get a warning.


Is this (KCPPFLAGS) the intended solution for this type of thing,
warning notwithstanding?

Or is there another, better way to manage this?



BTW, I'm using a relatively old kernel (2.6.31) but I'm interested in
comments even if they apply only to newer kernels.

Cheers!

Its a weird build system. The whole idea here is that .c files can be simply
dropped into the build directory and be auto built. I think your notdir
thing worked. I tried something similar with pattern substitution using the
PWD dir but of course the context switching thing killed me. Ill ping back
later to the list with a full solution. Thanks Sam.

On Thu, Apr 29, 2010 at 1:06 PM, Sam Ravnborg <sa...@ra...> wrote:

> First - posting to linux-kbuild will liekly get you more attention.
> The old list at sourceforge is no longer active.
>
> [From the bottom of your mail]
> > If anyone can point me to the "kbuild" way of doing things, it would be
> > greatly appreciated. Thanks!
> The kbuild philosofy is that you specify all .o files.
> Considering the many many hours invested writing a single .c file,
> then the effort it is to add it to the kbuild file is minimal.
>
> On Thu, Apr 29, 2010 at 11:38:30AM -0500, Chris Horlick wrote:
> > Im having an issue getting my build system set up the way id like and im
> > hoping someone here can point me in a new direction or perhaps offer some
> > advice.
> > If i manually add each .o file i want built to the makefile the lkm will
> > build with no issues, essentially this works:
> >
> > OBJS = main.o
> > #OBJS += wm_algo_common.o
> > #OBJS += wm_algomgr_ops.o
> > #OBJS += wm_algomgr_static.o
> > #OBJS += wm_algo_tcp1.o
> > #OBJS += wm_algo_tcp2.o
> > #OBJS += wm_algo_udp.o
> > #OBJS += wm_arp_reg_method.o
> > #OBJS += wmc_algomgr.o
> > #OBJS += wmc_core.o
> > #OBJS += wmc_core_function.o
> > #OBJS += wmc_debug.o
> > #OBJS += wmc_linked_list.o
> > #OBJS += wm_core_info.o
> > #OBJS += wm_core_ops.o
> > #OBJS += wmc_packet_common.o
> > #OBJS += wmc_regmgr.o wm_driver.o
> > #OBJS += wm_hashtable.o
> > #OBJS += wm_network_common.o
> > #OBJS += wm_regmgr_ops.o
> > #OBJS += wm_regmgr_static.o
> >
> > Granted these are commented out but they will build a loadable lkm if i
> > un-comment the obj lines. What i would really like is just to be able to
> > drop new sources into my build directory and have the makefile pick them
> up
> > and build them auto-magically, something like this:
> >
> > OBJS = $(patsubst %.c,%.o,$(wildcard $(PWD)/*.c))
>
> What you fail to realise is that current directory is the root
> of the kernel source when you build your module.
>
> Try something like this:
>
> OBJS := $(patsubst %.c, %.o,$(notdir $(wildcard $(src)/*.c)))
>
> $(wildcard $(src)/*.c) will find all .c files in the directory where you
> module reside
> $(notdir ...) remove the path component.
>
> Try to look at the resulting OBJS like this:
>
> $(warning OBJS=$(OBJS))
>
> Note - I used ":=" above. I always avoid using "=" unless strictly
> required.
>
>        Sam
>



-- 
Thanks,
Chris Horlick
Web Engineer
cho...@gm...
256.479.9562

First - posting to linux-kbuild will liekly get you more attention.
The old list at sourceforge is no longer active.

[From the bottom of your mail]
> If anyone can point me to the "kbuild" way of doing things, it would be
> greatly appreciated. Thanks!
The kbuild philosofy is that you specify all .o files.
Considering the many many hours invested writing a single .c file,
then the effort it is to add it to the kbuild file is minimal.

On Thu, Apr 29, 2010 at 11:38:30AM -0500, Chris Horlick wrote:
> Im having an issue getting my build system set up the way id like and im
> hoping someone here can point me in a new direction or perhaps offer some
> advice.
> If i manually add each .o file i want built to the makefile the lkm will
> build with no issues, essentially this works:
> 
> OBJS = main.o
> #OBJS += wm_algo_common.o
> #OBJS += wm_algomgr_ops.o
> #OBJS += wm_algomgr_static.o
> #OBJS += wm_algo_tcp1.o
> #OBJS += wm_algo_tcp2.o
> #OBJS += wm_algo_udp.o
> #OBJS += wm_arp_reg_method.o
> #OBJS += wmc_algomgr.o
> #OBJS += wmc_core.o
> #OBJS += wmc_core_function.o
> #OBJS += wmc_debug.o
> #OBJS += wmc_linked_list.o
> #OBJS += wm_core_info.o
> #OBJS += wm_core_ops.o
> #OBJS += wmc_packet_common.o
> #OBJS += wmc_regmgr.o wm_driver.o
> #OBJS += wm_hashtable.o
> #OBJS += wm_network_common.o
> #OBJS += wm_regmgr_ops.o
> #OBJS += wm_regmgr_static.o
> 
> Granted these are commented out but they will build a loadable lkm if i
> un-comment the obj lines. What i would really like is just to be able to
> drop new sources into my build directory and have the makefile pick them up
> and build them auto-magically, something like this:
> 
> OBJS = $(patsubst %.c,%.o,$(wildcard $(PWD)/*.c))

What you fail to realise is that current directory is the root
of the kernel source when you build your module.

Try something like this:

OBJS := $(patsubst %.c, %.o,$(notdir $(wildcard $(src)/*.c)))

$(wildcard $(src)/*.c) will find all .c files in the directory where you module reside
$(notdir ...) remove the path component.

Try to look at the resulting OBJS like this:

$(warning OBJS=$(OBJS))

Note - I used ":=" above. I always avoid using "=" unless strictly required.

	Sam

Im having an issue getting my build system set up the way id like and im
hoping someone here can point me in a new direction or perhaps offer some
advice.
If i manually add each .o file i want built to the makefile the lkm will
build with no issues, essentially this works:

OBJS = main.o
#OBJS += wm_algo_common.o
#OBJS += wm_algomgr_ops.o
#OBJS += wm_algomgr_static.o
#OBJS += wm_algo_tcp1.o
#OBJS += wm_algo_tcp2.o
#OBJS += wm_algo_udp.o
#OBJS += wm_arp_reg_method.o
#OBJS += wmc_algomgr.o
#OBJS += wmc_core.o
#OBJS += wmc_core_function.o
#OBJS += wmc_debug.o
#OBJS += wmc_linked_list.o
#OBJS += wm_core_info.o
#OBJS += wm_core_ops.o
#OBJS += wmc_packet_common.o
#OBJS += wmc_regmgr.o wm_driver.o
#OBJS += wm_hashtable.o
#OBJS += wm_network_common.o
#OBJS += wm_regmgr_ops.o
#OBJS += wm_regmgr_static.o

Granted these are commented out but they will build a loadable lkm if i
un-comment the obj lines. What i would really like is just to be able to
drop new sources into my build directory and have the makefile pick them up
and build them auto-magically, something like this:

OBJS = $(patsubst %.c,%.o,$(wildcard $(PWD)/*.c))

Now, this should work because the makefile is in the same directory as the
sources/headers so it should pick up the .c files and substitute to the .o
files then i can build with my default target:

default:
        @echo $(OBJS)
        $(MAKE) -C $(KDIR) M=$(PWD) PWD=$(PWD) V=1 modules

The issue is the echo statement looks fine but when the makefile switches
into the source one of two things happens depending on how i have the OBJS
line setup. If the objs line is setup like it is in second snipped; because
kbuild prefixes the PWD path to the directory where the makefile is stored
twice the build breaks, like this:

make[2]: *** No rule to make target
`/home/chorlick/Code/watermarking/trunk/code/framework/build/linux/lkm//home/chorlick/Code/watermarking/trunk/code/framework/build/linux/lkm/main.o'

You can see the first
/home/chorlick/Code/watermarking/trunk/code/framework/build/linux/lkdm comes
from kbuild's prefix the second is the PWD path picked up from the wildcard
function in the makefile. This being the case i have tried using this line:

OBJS = $(patsubst %.c,%.o,$(wildcard *.c))

The problem here is that make cant find the sources because when that
variable get evaluated its off in the kernel sources build directory and of
course my code isnt located there. So in a nutshell does anyone know a way
to disable kbuild's path prefixing or a way to force kbuild to evaulate PWD
as something slightly different so i can just use the :

OBJS = $(patsubst %.c,%.o,$(wildcard *.c))

line.

If anyone can point me to the "kbuild" way of doing things, it would be
greatly appreciated. Thanks!

-chorlick

Hello,

[RFC]

When dealing with creating or maintaining a kernel configuration, one
may have to describe why a certain option was set and it may be helpful
to review the personal remark when revisiting the kernel configuration.

To ease the paperwork for that, I've been working on enhancing the config
tools keep and edit remarks entered by the user.

The following minimalistic patch is intended to show the concept with a
minimum amount of code.

It:
- adds a file ".config-remarks" in which the config infrastructure keeps
   user remarks and
- extends "make config" and "make oldconfig" to show and edit these user
   remarks.

make menuconfig, xconfig and gconfig are also extensible in the same way.
I already enabled make xconfig (in a separate patch).

Thanks,
Bernhard Kaindl

Applies against 2.6.32-rc5-git1:

diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index 9960d1c..85b0333 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -160,6 +160,8 @@ static int conf_sym(struct menu *menu)
  	tristate oldval, newval;

  	while (1) {
+		if (sym->remark)
+			printf("Remark: %s\n", sym->remark);
  		printf("%*s%s ", indent - 1, "", _(menu->prompt->text));
  		if (sym->name)
  			printf("(%s) ", sym->name);
@@ -221,6 +223,22 @@ static int conf_sym(struct menu *menu)
  			return 0;
  help:
  		print_help(menu);
+		if (line[1] == '?') {
+			char *p;
+
+			if (sym->remark)
+				printf("Current Remark: %s\n", sym->remark);
+			printf("    New remark: ");
+			fgets(line, sizeof(line), stdin);
+
+			if ((p = strchr(line, '\n')))	// search for newline
+				*p = '\0';		// zero it
+			if (line[0]) {
+				if (sym->remark)
+					free(sym->remark);
+				sym->remark = strdup(line);
+			}
+		}
  	}
  }

diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index b55e72f..db30561 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -152,6 +152,43 @@ static int conf_set_sym_val(struct symbol *sym, int def, int def_flags, char *p)
  	return 0;
  }

+int conf_read_remarks(const char *name)
+{
+	FILE *in;
+	char line[1024], *p, *p2;
+	struct symbol *sym;
+
+	if (!name)
+		return 1;
+	in = zconf_fopen(name);			// open the right file
+	if (!in)
+		return 1;
+
+	conf_filename = name;			// for conf_warning()
+	conf_lineno = 0;			// for conf_warning()
+
+	while (fgets(line, sizeof(line), in)) {
+		conf_lineno++;			// for conf_warning()
+		if (!(p = strchr(line, ' ')))	// search for space
+			continue;		// ignore other lines
+		*p++ = 0;			// zero it out
+		if ((p2 = strchr(p, '\n')))	// search for newline
+			*p2 = '\0';		// zero it out
+		sym = sym_find(line);		// find the matching sym
+		if (!sym) {
+			conf_warning("unknown: %s %s", line, p);
+			continue;
+		}
+		printf("got: %s remark: %s\n", line, p);
+		sym->remark = strdup(p);
+
+	}
+	fclose(in);
+
+	return 0;
+}
+
+
  int conf_read_simple(const char *name, int def)
  {
  	FILE *in = NULL;
@@ -393,12 +430,13 @@ int conf_read(const char *name)

  	sym_add_change_count(conf_warnings || conf_unsaved);

+	conf_read_remarks(".config-remarks");
  	return 0;
  }

  int conf_write(const char *name)
  {
-	FILE *out;
+	FILE *out, *out_remarks;
  	struct symbol *sym;
  	struct menu *menu;
  	const char *basename;
@@ -443,6 +481,10 @@ int conf_write(const char *name)
  	if (!out)
  		return 1;

+	out_remarks = fopen(".config-remarks.tmp", "w"); // to be done like above
+	if (!out_remarks)
+		return 1;
+
  	sym = sym_lookup("KERNELVERSION", 0);
  	sym_calc_value(sym);
  	time(&now);
@@ -526,6 +568,8 @@ int conf_write(const char *name)
  				break;
  			}
  		}
+		if (sym && sym->remark)
+			fprintf(out_remarks, "%s %s\n", sym->name, sym->remark);

  	next:
  		if (menu->list) {
@@ -550,6 +594,7 @@ int conf_write(const char *name)
  		if (rename(tmpname, newname))
  			return 1;
  	}
+	rename(".config-remarks.tmp", ".config-remarks");

  	printf(_("#\n"
  		 "# configuration written to %s\n"
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index 6408fef..217e8cb 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -77,6 +77,7 @@ enum {
  struct symbol {
  	struct symbol *next;
  	char *name;
+	char *remark;
  	enum symbol_type type;
  	struct symbol_value curr;
  	struct symbol_value def[S_DEF_COUNT];

Hello,

I am seeking for comments for this topic:

When dealing with creating or maintaining a kernel configuration, one
may have to remember
or even describe why a certain decision for or against a specific
kernel option was taken or
one may just want so save a note about it.

Of course one could write his notes into any note-taking software and
look up the correct, latest, matching notes every time when one is
looking at a kernel configuration for a given kernel, but it's a lot
of paperwork to do this for lots of different configurations and a lot
of documented configuration option decisions or configuration option
notes.

To keep all the notes for all the configuration options of all the
kernel configurations together and allow for easy review of notes
taken, I extended the kernel configuration tools to keep and edit a
one-line comment for each configuration option directly in the .config
file and extended "make xconfig" to allow to embed a QLineEdit line
editor (same as used for editing strings like CONFIG_CMDLINE) for
editing comments.

Example lines of a resulting .config:

CONFIG_EXPERIMENTAL=y
# CONFIG_EXPERIMENTAL comment:Never turn that OFF! Required for kgdb
and NF transparent proxy!
...
CONFIG_MTD_PCMCIA=m
# CONFIG_MTD_PCMCIA comment:Needed for project xyz to access PCMCIA
flash cards as MTD
CONFIG_MTD_BLOCK=m
# CONFIG_MTD_BLOCK comment:Needed to mount filesystems on MTD,
requirement number SS-4711
...
CONFIG_SENSORS_LM87=m
# CONFIG_SENSORS_LM87 comment:TODO: May be useable for reading
temperature on board foo

I guess that gives you the idea. Linux Distributors may find that useful too.

For example, Ubuntu is documenting its kernel configuration decisions here

https://wiki.ubuntu.com/specs/KernelKarmicKernelConfig
https://wiki.ubuntu.com/KernelTeam/2.6.28-2-generic-config
 -> (some configuration setting remarks are included - of course it's
a tedious job to enter comments into a wiki, this page could be
generated from a .config with comments)
https://wiki.ubuntu.com/KernelTeam/2.6.30-5-generic-config (Remarks
column is emtpy though)

As this is not a official submission on lkml (which would forbid HTML
mail anyways), please find the patch attached.

This is for review only to get comments on whether people like to have
such feature in the upstream kernel configuration tools, and is of
course not meant to be complete.

However, it's already stable and used in production to save and review
config option remarks using make xconfig. I edited configuration
remarks heavily over the course of many many hours, resulting in 273
commented kernel configuration remarks for a project I am
collaborating on.

Please send your thoughts!

Thanks,
Bernhard Kaindl

PS: On the question of hidden config options:

The infrastructure keeps all comments it finds, targeted for hidden or
visible options. Of course, you can of course only edit comments for
shown config options.

To edit comments for hidden config options, you unhide the option by
either selecting "Show all" in make xconfig or by making the option
shown by changing the respective other config option which make the
commented config option visible.

Bernhard Kaindl

Hi Sam,

On Fri, Aug 21, 2009 at 11:51 PM, Sam Ravnborg<sa...@ra...> wrote:
> kbuild list on sourceforge is long defunct.
> Please use lin...@vg....
>
>
> On Fri, Aug 21, 2009 at 10:45:14PM +0200, Nipun sehrawat wrote:
>> Hi List,
>>
>> I am porting KTCPVS (last released for 2.6.18) to the latest kernel. I
>> was able to compile most of the files on 2.6.30, until I got struck at
>> a strange "KBUILD_MODNAME undefined warning" The Makefile of KTCPVS is
>> :
>>
>> ---------------------------------Makefile
>> Starts-------------------------------------
>> # ktcpvs migrate to 2.6
>>
>> ifneq ($(KERNELRELEASE),)
>>     ifdef CONFIG_MODVERSIONS
>>     EXTRA_CFLAGS := -DCONFIG_TCP_VS_DEBUG
>>     endif
>>     obj-m := ktcpvs.o tvs_hhttp.o tvs_phttp.o tvs_chttp.o tvs_http.o tvs_wlc.o
>>     LIBS := tcp_vs_sched.o tcp_vs_ctl.o misc.o redirect.o
>> tcp_vs_srvconn.o tcp_vs_timer.o tcp_vs.o fault.o regex/regcomp.o
>>     LIBS += regex/kernel.o regex/regfree.o
>>     ktcpvs-y := $(LIBS)
>
> If you are building a module use "-m" not "-y".
> Try that and see if it hepls you.

According to Kbuild Documentation in Linux Kernel source :

"Kbuild needs to know which the parts that you want to build your
module from, so you have to tell it by setting an
$(<module_name>-objs) variable."

I tried changing ktcpvs-y to ktcpvs-objs, but it didn't help.

>
>        Sam
>

Thanks for your quick response!

Cheers,
Nipun

kbuild list on sourceforge is long defunct.
Please use lin...@vg....


On Fri, Aug 21, 2009 at 10:45:14PM +0200, Nipun sehrawat wrote:
> Hi List,
> 
> I am porting KTCPVS (last released for 2.6.18) to the latest kernel. I
> was able to compile most of the files on 2.6.30, until I got struck at
> a strange "KBUILD_MODNAME undefined warning" The Makefile of KTCPVS is
> :
> 
> ---------------------------------Makefile
> Starts-------------------------------------
> # ktcpvs migrate to 2.6
> 
> ifneq ($(KERNELRELEASE),)
>     ifdef CONFIG_MODVERSIONS
>     EXTRA_CFLAGS := -DCONFIG_TCP_VS_DEBUG
>     endif
>     obj-m := ktcpvs.o tvs_hhttp.o tvs_phttp.o tvs_chttp.o tvs_http.o tvs_wlc.o
>     LIBS := tcp_vs_sched.o tcp_vs_ctl.o misc.o redirect.o
> tcp_vs_srvconn.o tcp_vs_timer.o tcp_vs.o fault.o regex/regcomp.o
>     LIBS += regex/kernel.o regex/regfree.o
>     ktcpvs-y := $(LIBS)

If you are building a module use "-m" not "-y".
Try that and see if it hepls you.

	Sam

Hi List,

I am porting KTCPVS (last released for 2.6.18) to the latest kernel. I
was able to compile most of the files on 2.6.30, until I got struck at
a strange "KBUILD_MODNAME undefined warning" The Makefile of KTCPVS is
:

---------------------------------Makefile
Starts-------------------------------------
# ktcpvs migrate to 2.6

ifneq ($(KERNELRELEASE),)
    ifdef CONFIG_MODVERSIONS
    EXTRA_CFLAGS := -DCONFIG_TCP_VS_DEBUG
    endif
    obj-m := ktcpvs.o tvs_hhttp.o tvs_phttp.o tvs_chttp.o tvs_http.o tvs_wlc.o
    LIBS := tcp_vs_sched.o tcp_vs_ctl.o misc.o redirect.o
tcp_vs_srvconn.o tcp_vs_timer.o tcp_vs.o fault.o regex/regcomp.o
    LIBS += regex/kernel.o regex/regfree.o
    ktcpvs-y := $(LIBS)

    RELIBS := regex/kernel.o regex/regexec.o regex/regfree.o
    tvs_hhttp-y := tcp_vs_hhttp.o  $(RELIBS)
    tvs_phttp-y := tcp_vs_phttp.o tcp_vs_http_parser.o
tcp_vs_http_trans.o $(RELIBS)
    tvs_chttp-y := tcp_vs_chttp.o tcp_vs_http_parser.o
tcp_vs_http_trans.o avl.o $(RELIBS)
    tvs_http-y := tcp_vs_http.o tcp_vs_http_parser.o
tcp_vs_http_trans.o $(RELIBS)
    tvs_wlc-y := tcp_vs_wlc.o $(RELIBS)
else
# Set kerneldir
KERNELDIR := /lib/modules/$(shell uname -r)/build
TARGET := tcp_vs.ko

$(TARGET):
    $(MAKE) -C $(KERNELDIR) M=`pwd` modules
install: $(TARGET)
    @sh install.sh
clean:
    @rm -fv *o *mod* .*.cmd
    @rm -rfv .tmp*
    @rm -fv regex/*o regex/.*.cmd
load:
    @insmod ktcpvs.ko
    @insmod tvs_hhttp.ko
    @/root/bin/tcpvsadm -f config/conftest
test:
    @insmod ktcpvs.ko
    @echo 12 >/proc/sys/net/ktcpvs/debug_level
    @insmod tvs_phttp.ko
    @/root/bin/tcpvsadm -f config/conftest
unload:
    @echo 1 >/proc/sys/net/ktcpvs/unload
    @sleep 2
    @rmmod tvs_hhttp
    @rmmod ktcpvs
endif

--------------------------------Makefile
ends---------------------------------------


The error goes like this :

--------------------------------Compile
Error-----------------------------------------
In file included from include/linux/tcp.h:178,
                 from /home/nipun/ktcpvs/new/ktcpvs/tcp_vs_http_trans.c:29:
include/net/inet_connection_sock.h: In function ‘inet_csk_clear_xmit_timer’:
include/net/inet_connection_sock.h:203: error: unknown field ‘Usage’
specified in initializer
include/net/inet_connection_sock.h:203: error: expected expression
before ‘.’ token
include/net/inet_connection_sock.h:203: error: ‘Usage’ undeclared
(first use in this function)
include/net/inet_connection_sock.h:203: error: (Each undeclared
identifier is reported only once
include/net/inet_connection_sock.h:203: error: for each function it appears in.)
include/net/inet_connection_sock.h:203: error: expected ‘)’ before ‘:’ token
include/net/inet_connection_sock.h:203: error: expected ‘)’ before ‘:’ token
include/net/inet_connection_sock.h: In function ‘inet_csk_reset_xmit_timer’:
include/net/inet_connection_sock.h:219: error: unknown field ‘Usage’
specified in initializer
include/net/inet_connection_sock.h:219: error: expected expression
before ‘.’ token
include/net/inet_connection_sock.h:219: error: ‘Usage’ undeclared
(first use in this function)
include/net/inet_connection_sock.h:219: error: expected ‘)’ before ‘:’ token
include/net/inet_connection_sock.h:219: error: expected ‘)’ before ‘:’ token
include/net/inet_connection_sock.h:236: error: unknown field ‘Usage’
specified in initializer
include/net/inet_connection_sock.h:236: error: expected expression
before ‘.’ token
include/net/inet_connection_sock.h:236: error: expected ‘)’ before ‘:’ token
include/net/inet_connection_sock.h:236: error: expected ‘)’ before ‘:’ token
make[2]: *** [/home/nipun/ktcpvs/new/ktcpvs/tcp_vs_http_trans.o] Error 1
make[1]: *** [_module_/home/nipun/ktcpvs/new/ktcpvs] Error 2
make[1]: Leaving directory `/home/nipun/linux-2.6.30'
make: *** [tcp_vs.ko] Error 2
------------------------Compile Error
Ends-----------------------------------------------

Following is the last line in output, before above error comes, of "make V=1" :

------------------------make
output--------------------------------------------------------------------
gcc -Wp,-MD,/home/nipun/ktcpvs/new/ktcpvs/.tcp_vs_http_trans.o.d
-nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.3.3/include -Iinclude
 -I/home/nipun/linux-2.6.30/arch/x86/include -include
include/linux/autoconf.h -D__KERNEL__ -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -O2 -m32 -msoft-float
-mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2
-march=i586 -mtune=generic -Wa,-mtune=generic32 -ffreestanding -pipe
-Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx
-mno-sse2 -mno-3dnow -fno-stack-protector -fno-omit-frame-pointer
-fno-optimize-sibling-calls -g -Wdeclaration-after-statement
-Wno-pointer-sign -fwrapv -DCONFIG_TCP_VS_DEBUG
-D"KBUILD_MODNAME=KBUILD_STR(tvsphttp_tvschttp_tvshttp)"  -DMODULE
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(tcp_vs_http_trans)"
 -D"DEBUG_HASH=Usage: ./scripts/basic/hash <djb2|r5> <modname>"
-D"DEBUG_HASH2=Usage: ./scripts/basic/hash <djb2|r5> <modname>" -c -o
/home/nipun/ktcpvs/new/ktcpvs/.tmp_tcp_vs_http_trans.o
/home/nipun/ktcpvs/new/ktcpvs/tcp_vs_http_trans.c
-----------------------make output
ends--------------------------------------------------------------

As you can see, there is no KBUILD_MODNAME defined. Another strange
this in above line is :
-D"DEBUG_HASH2=Usage: ./scripts/basic/hash <djb2|r5> <modname>"

In case of other files, it gave an integer value to this field.

It seems to me that the problem arises as there are multiple targets
in obj-m and they share "tcp_vs_http_trans.o" (but so is
"tcp_vs_http_parser.o", which is not causing any problems) . I tried
keeping objects, not involving this target at the same time, and the
build goes fine.

Please help me out. Thanks for reading such long post.

Cheers,
Nipun

On Mon, Jun 15, 2009 at 00:37, Sam Ravnborg wrote:
> On Sun, Jun 14, 2009 at 10:05:26PM -0400, Mike Frysinger wrote:
>> On Sun, Jun 14, 2009 at 21:59, Robin Getz wrote:
>> > On Sun 14 Jun 2009 16:44, Sam Ravnborg pondered:
>> >> On Mon, Jun 08, 2009 at 07:23:16PM -0400, Mike Frysinger wrote:
>> >> > intro: the current Blackfin memory architecture is (1) no virtualized
>> >> > memory and (2) distinctly harvard.  that means we cannot create a
>> >> > linear map of start/end text sections.  we end up with distinct
>> >> > regions like so:
>> >> > 00001000 T __stext
>> >> > 000dc4c0 T __etext
>> >> > feb00000 A __etext_l2
>> >> > feb00010 A __stext_l2
>> >> > ffa00000 T __stext_l1
>> >> > ffa0160c T __etext_l1
>> >> > this is because external memory starts at address 0 while on-chip
>> >> > regions have different discontiguous hardcoded addresses (L1
>> >> > instruction in this case starts at 0xffa00000 while L2 starts at
>> >> > 0xfeb00000).
>> >> >
>> >> > the current kallsyms is written to search for the special stext/etext
>> >> > symbols only which means the resulting kallsyms output knows nothing
>> >> > of the Blackfin symbols living in these on-chip regions.  we've
>> >> > written two patches to fix this: the first one is straight forward and
>> >> > simply copies & pastes the existing hardcoded regions.  the second
>> >> > creates an array of text regions which makes it much easier to extend
>> >> > in the future for other people (and can be squashed into the first
>> >> > one).
>> >> >
>> >> > doesnt matter to me which method is picked :)
>> >>
>> >> I added both as I liked the generalization.
>> >> I had to rearrange the "Signed-off-by" in the first patch
>> >> as this patch came in vai you and not Robin.
>> >
>> > I think Mike pulled this from some work I did awhile ago, (and sent to you)
>> > that obviously never got added (since I didn't send it in the proper patch
>> > format).
>> >
>> > http://lkml.indiana.edu/hypermail/linux/kernel/0607.1/0558.html
>>
>> yeah, the first patch was by Robin ... the "From:" line in the patch
>> should have shown that (and git-am would have respected) ...
>
> So does the patch.
> What I had to change was that the Signed-off-by: lines indicated
> that this patch came in like this:
>
> Robin -> Mike -> Bryan Wu -> Sam
> So I rearranged the signed-off-by: lines so it indicated
> the following order:
>
> Robin -> Bryan Wu -> Mike -> Sam
>
>
> I trust that Bryan really did add his sob, and it
> was only a mistake that Mike added his sob before
> that of Bryans.

yes, i took a bunch of patches from Bryan like this one
-mike

On Sun, Jun 14, 2009 at 10:05:26PM -0400, Mike Frysinger wrote:
> On Sun, Jun 14, 2009 at 21:59, Robin Getz wrote:
> > On Sun 14 Jun 2009 16:44, Sam Ravnborg pondered:
> >> On Mon, Jun 08, 2009 at 07:23:16PM -0400, Mike Frysinger wrote:
> >> > intro: the current Blackfin memory architecture is (1) no virtualized
> >> > memory and (2) distinctly harvard.  that means we cannot create a
> >> > linear map of start/end text sections.  we end up with distinct
> >> > regions like so:
> >> > 00001000 T __stext
> >> > 000dc4c0 T __etext
> >> > feb00000 A __etext_l2
> >> > feb00010 A __stext_l2
> >> > ffa00000 T __stext_l1
> >> > ffa0160c T __etext_l1
> >> > this is because external memory starts at address 0 while on-chip
> >> > regions have different discontiguous hardcoded addresses (L1
> >> > instruction in this case starts at 0xffa00000 while L2 starts at
> >> > 0xfeb00000).
> >> >
> >> > the current kallsyms is written to search for the special stext/etext
> >> > symbols only which means the resulting kallsyms output knows nothing
> >> > of the Blackfin symbols living in these on-chip regions.  we've
> >> > written two patches to fix this: the first one is straight forward and
> >> > simply copies & pastes the existing hardcoded regions.  the second
> >> > creates an array of text regions which makes it much easier to extend
> >> > in the future for other people (and can be squashed into the first
> >> > one).
> >> >
> >> > doesnt matter to me which method is picked :)
> >>
> >> I added both as I liked the generalization.
> >> I had to rearrange the "Signed-off-by" in the first patch
> >> as this patch came in vai you and not Robin.
> >
> > I think Mike pulled this from some work I did awhile ago, (and sent to you)
> > that obviously never got added (since I didn't send it in the proper patch
> > format).
> >
> > http://lkml.indiana.edu/hypermail/linux/kernel/0607.1/0558.html
> 
> yeah, the first patch was by Robin ... the "From:" line in the patch
> should have shown that (and git-am would have respected) ...

So does the patch.
What I had to change was that the Signed-off-by: lines indicated
that this patch came in like this:

Robin -> Mike -> Bryan Wu -> Sam
So I rearranged the signed-off-by: lines so it indicated
the following order:

Robin -> Bryan Wu -> Mike -> Sam


I trust that Bryan really did add his sob, and it
was only a mistake that Mike added his sob before
that of Bryans.

	Sam

On Sun, Jun 14, 2009 at 21:59, Robin Getz wrote:
> On Sun 14 Jun 2009 16:44, Sam Ravnborg pondered:
>> On Mon, Jun 08, 2009 at 07:23:16PM -0400, Mike Frysinger wrote:
>> > intro: the current Blackfin memory architecture is (1) no virtualized
>> > memory and (2) distinctly harvard.  that means we cannot create a
>> > linear map of start/end text sections.  we end up with distinct
>> > regions like so:
>> > 00001000 T __stext
>> > 000dc4c0 T __etext
>> > feb00000 A __etext_l2
>> > feb00010 A __stext_l2
>> > ffa00000 T __stext_l1
>> > ffa0160c T __etext_l1
>> > this is because external memory starts at address 0 while on-chip
>> > regions have different discontiguous hardcoded addresses (L1
>> > instruction in this case starts at 0xffa00000 while L2 starts at
>> > 0xfeb00000).
>> >
>> > the current kallsyms is written to search for the special stext/etext
>> > symbols only which means the resulting kallsyms output knows nothing
>> > of the Blackfin symbols living in these on-chip regions.  we've
>> > written two patches to fix this: the first one is straight forward and
>> > simply copies & pastes the existing hardcoded regions.  the second
>> > creates an array of text regions which makes it much easier to extend
>> > in the future for other people (and can be squashed into the first
>> > one).
>> >
>> > doesnt matter to me which method is picked :)
>>
>> I added both as I liked the generalization.
>> I had to rearrange the "Signed-off-by" in the first patch
>> as this patch came in vai you and not Robin.
>
> I think Mike pulled this from some work I did awhile ago, (and sent to you)
> that obviously never got added (since I didn't send it in the proper patch
> format).
>
> http://lkml.indiana.edu/hypermail/linux/kernel/0607.1/0558.html

yeah, the first patch was by Robin ... the "From:" line in the patch
should have shown that (and git-am would have respected) ...
-mike

On Mon, Jun 08, 2009 at 07:23:16PM -0400, Mike Frysinger wrote:
> intro: the current Blackfin memory architecture is (1) no virtualized
> memory and (2) distinctly harvard.  that means we cannot create a
> linear map of start/end text sections.  we end up with distinct
> regions like so:
> 00001000 T __stext
> 000dc4c0 T __etext
> feb00000 A __etext_l2
> feb00010 A __stext_l2
> ffa00000 T __stext_l1
> ffa0160c T __etext_l1
> this is because external memory starts at address 0 while on-chip
> regions have different discontiguous hardcoded addresses (L1
> instruction in this case starts at 0xffa00000 while L2 starts at
> 0xfeb00000).
> 
> the current kallsyms is written to search for the special stext/etext
> symbols only which means the resulting kallsyms output knows nothing
> of the Blackfin symbols living in these on-chip regions.  we've
> written two patches to fix this: the first one is straight forward and
> simply copies & pastes the existing hardcoded regions.  the second
> creates an array of text regions which makes it much easier to extend
> in the future for other people (and can be squashed into the first
> one).
> 
> doesnt matter to me which method is picked :)

I added both as I liked the generalization.
I had to rearrange the "Signed-off-by" in the first patch
as this patch came in vai you and not Robin.

	Sam

intro: the current Blackfin memory architecture is (1) no virtualized
memory and (2) distinctly harvard.  that means we cannot create a
linear map of start/end text sections.  we end up with distinct
regions like so:
00001000 T __stext
000dc4c0 T __etext
feb00000 A __etext_l2
feb00010 A __stext_l2
ffa00000 T __stext_l1
ffa0160c T __etext_l1
this is because external memory starts at address 0 while on-chip
regions have different discontiguous hardcoded addresses (L1
instruction in this case starts at 0xffa00000 while L2 starts at
0xfeb00000).

the current kallsyms is written to search for the special stext/etext
symbols only which means the resulting kallsyms output knows nothing
of the Blackfin symbols living in these on-chip regions.  we've
written two patches to fix this: the first one is straight forward and
simply copies & pastes the existing hardcoded regions.  the second
creates an array of text regions which makes it much easier to extend
in the future for other people (and can be squashed into the first
one).

doesnt matter to me which method is picked :)

(yes, another change is needed to kernel/kallsysms.c, but one thing at a time)
-mike

Hi all
I took Kbuild environment from linux-2.6.20 (from kernel.org) for my build
system.
I have lot of configurable options for my modules in the build system.

I see that there are 2 ways of accesing the configurable options in my C
code:
1. generate autoconf.h and include it in the code
2. include .config (generated by menuconfig) and pass appropraites CFLAGS in
my makefiles?

What is the recommended way?

As i understand, for option 1, every time i do menuconfig, autconf.h is
updated thus causing all source code to recompile which is annoying.

Any hints are appreciated.

Regards
kalyan

Hi Sam,
Thanks!! That worked..:)

Regards
Kalyan


On Sat, Dec 6, 2008 at 12:11 AM, Sam Ravnborg <sa...@ra...> wrote:

> On Thu, Dec 04, 2008 at 12:01:25PM +0530, kalyan wrote:
> > Hi list,
> > I am trying to have GUI based build system and i took menuconfig system
> from
> > the kernel-2.6.20.
> > When i do "make menuconfig" the system happily reads from .config and
> > Kconfig. All is well.
> > But my intention is if i do, say, "make new-config" it should pop up a
> > different GUI by:
> > 1. Read Kconfig-new
> > 2. Read/Save to .config-new automatically.
> >
> > I managed step 1 but failed in step 2. Is there a way to do this?
>
> Try to set KCONFIG_CONFIG to ".config-new".
> KCONFG_CONFIG is used to set a different name than .config
> for the filebased frontend to kconfig.
> .config is today only used as an alternative frontend and
> is not read during the build step.
>
>        Sam
>

On Thu, Dec 04, 2008 at 12:01:25PM +0530, kalyan wrote:
> Hi list,
> I am trying to have GUI based build system and i took menuconfig system from
> the kernel-2.6.20.
> When i do "make menuconfig" the system happily reads from .config and
> Kconfig. All is well.
> But my intention is if i do, say, "make new-config" it should pop up a
> different GUI by:
> 1. Read Kconfig-new
> 2. Read/Save to .config-new automatically.
> 
> I managed step 1 but failed in step 2. Is there a way to do this?

Try to set KCONFIG_CONFIG to ".config-new".
KCONFG_CONFIG is used to set a different name than .config
for the filebased frontend to kconfig.
.config is today only used as an alternative frontend and
is not read during the build step.

	Sam