Roman Zippel | 1 Sep 01:53 2007

Re: tristate choice with bool value

Hi,

On Fri, 31 Aug 2007, Jan Beulich wrote:

> Doing a few more experiments with choices, I find that int, hex, and string
> don't seem to work at all here. It would seem to me that these all could be
> useful, but clearly would require some changes even in the grammar in order
> to get there.

Well, in the long term I wouldn't mind making choices more flexible, 
basically as a general way to describe more complex interdependencies 
between symbols, although I'm not sure how string symbols are useful here. 
The basic problem is to keep the syntax and user interface sane and there 
has to be a mechanism to resolve conflicts between these dependencies.

> Also I think that deriving the choice type from the type of the first choice
> value isn't always correct - at least not in the case of a mixed set of bool/
> tristate values, in which case the choice should become tristate itself.

I'm not entirely convinced, mixing types is a good idea, but anyway... :)

> --- a/scripts/kconfig/menu.c
> +++ b/scripts/kconfig/menu.c
>  <at>  <at>  -238,6 +238,9  <at>  <at>  void menu_finalize(struct menu *parent)
>  			/* find the first choice value and find out choice type */
>  			for (menu = parent->list; menu; menu = menu->next) {
>  				if (menu->sym) {
> +					if (sym->type == S_TRISTATE &&
> +					    menu->sym->type == S_BOOLEAN)
> +						break;
(Continue reading)

Sam Ravnborg | 8 Sep 15:01 2007

Re: [4/4] 2.6.23-rc5: known regressions v2

Hi Michal.

> Kconfig/Kbuild
> 
> Subject         : building a specific in-tree module is currently a bit broken
> References      : http://lkml.org/lkml/2007/9/5/40
> Last known good : ?
> Submitter       : Robert P. J. Day <rpjday <at> mindspring.com>
> Caused-By       : ?
> Handled-By      : Sam Ravnborg <sam <at> ravnborg.org>
> Status          : problem is being debugged

Known bug there has been there for ages so this is not a regression.
I suggest removing it from this list - and I will see to have
it fixed for 2.6.24.
I will not push any fix for -rc for this.

	Sam
Sam Ravnborg | 9 Sep 20:02 2007

kbuild: enable possibility to specify xFLAGS on commandline

Following patchset enable the possibility to specify 
CFLAGS, AFLAGS or CPPFLAGS on the commandline to add
additional options while building the kernel.

The patch prefix all uses of CFLAGS, AFLAGS and CPPFLAGS
with KBUILD_ which touches all arch Makefiles.

Regression testing was very simple. Since this patch did not
change behaviour adding the patch should not cause any recompile
and this was tested with defconfig on several architectures.
To be more specific on:
alpha arm i386 mips sparc sparc64 x86_64 ia64 m68k s390

powerpc I dave a toolchain but defconfig seems not to be present.
blackfin and um did not build.

A small cleanup patch for ia64 sneaked in too - to allow the
above mentioned regression test.

The patchset will conflict with a patch from Andi Kleen.
If the patch for x86_64 will be pushed for -rc - no troubles.
If the patch await next mergewindow I could take it in my tree
to avoid the conflict.

The patch in question is:
ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/cflags-probe

The purpose of this patch is to make it much simpler to try out
different gcc options.
The receipe is the following:
(Continue reading)

Sam Ravnborg | 9 Sep 20:06 2007

[PATCH 3/4] ia64: fix sn to add include files using EXTRA_CFLAGS

Changing the global CPPFLAGS is not the recommended way
to add additional include dirs.
Changed to use EXTRA_CFLAGS.

Signed-off-by: Sam Ravnborg <sam <at> ravnborg.org>
---
 arch/ia64/sn/kernel/Makefile     |    2 +-
 arch/ia64/sn/kernel/sn2/Makefile |    2 +-
 arch/ia64/sn/pci/Makefile        |    2 +-
 arch/ia64/sn/pci/pcibr/Makefile  |    2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/ia64/sn/kernel/Makefile b/arch/ia64/sn/kernel/Makefile
index 0a59371..688a3c2 100644
--- a/arch/ia64/sn/kernel/Makefile
+++ b/arch/ia64/sn/kernel/Makefile
 <at>  <at>  -7,7 +7,7  <at>  <at> 
 # Copyright (C) 1999,2001-2006 Silicon Graphics, Inc.  All Rights Reserved.
 #

-CPPFLAGS += -I$(srctree)/arch/ia64/sn/include
+EXTRA_CFLAGS += -Iarch/ia64/sn/include

 obj-y				+= setup.o bte.o bte_error.o irq.o mca.o idle.o \
 				   huberror.o io_acpi_init.o io_common.o \
diff --git a/arch/ia64/sn/kernel/sn2/Makefile b/arch/ia64/sn/kernel/sn2/Makefile
index 99e1776..08e6565 100644
--- a/arch/ia64/sn/kernel/sn2/Makefile
+++ b/arch/ia64/sn/kernel/sn2/Makefile
 <at>  <at>  -9,7 +9,7  <at>  <at> 
(Continue reading)

Sam Ravnborg | 9 Sep 20:07 2007

[PATCH 4/4] kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP

The variable CPPFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.

This patch replace use of CPPFLAGS with KBUILD_AFLAGS all over the
tree and enabling one to use:
make CPPFLAGS=...
to specify additional CPP commandline options.

Signed-off-by: Sam Ravnborg <sam <at> ravnborg.org>
---
 Documentation/kbuild/makefiles.txt |    2 +-
 Makefile                           |   13 +++++++------
 arch/arm/Makefile                  |    4 ++--
 arch/ia64/Makefile                 |    2 +-
 arch/powerpc/Makefile              |    2 +-
 arch/ppc/Makefile                  |    2 +-
 arch/um/Makefile-x86_64            |    2 +-
 drivers/atm/Makefile               |    2 +-
 scripts/Makefile.lib               |    6 +++---
 9 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 15b3c11..29d070f 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
 <at>  <at>  -1100,7 +1100,7  <at>  <at>  When kbuild executes, the following steps are followed (roughly):
 	specified options when building the target vmlinux.lds.

 	When building the *.lds target, kbuild uses the variables:
-	CPPFLAGS	: Set in top-level Makefile
(Continue reading)

Sam Ravnborg | 9 Sep 20:05 2007

[PATCH 2/4] kbuild: enable 'make AFLAGS=...' to add additional options to AS

The variable AFLAGS is a wellknown variable and the usage by
kbuild may result in unexpected behaviour.
On top of that several people over time has asked for a way to
pass in additional flags to gcc.

This patch replace use of AFLAGS with KBUILD_AFLAGS all over the
tree and enabling one to use:
make AFLAGS=...
to specify additional gcc (as) commandline options.

Signed-off-by: Sam Ravnborg <sam <at> ravnborg.org>
---
 Documentation/kbuild/makefiles.txt     |    5 +++--
 Makefile                               |    9 +++++----
 arch/arm/Makefile                      |    2 +-
 arch/arm/vfp/Makefile                  |    2 +-
 arch/avr32/Makefile                    |    4 ++--
 arch/blackfin/Makefile                 |    2 +-
 arch/cris/Makefile                     |    2 +-
 arch/frv/Makefile                      |   10 +++++-----
 arch/h8300/Makefile                    |    2 +-
 arch/h8300/lib/Makefile                |    2 +-
 arch/i386/Makefile                     |    6 +++---
 arch/i386/boot/Makefile                |    2 +-
 arch/m32r/Makefile                     |    2 +-
 arch/m68knommu/Makefile                |    2 +-
 arch/m68knommu/platform/5206/Makefile  |    2 +-
 arch/m68knommu/platform/5206e/Makefile |    2 +-
 arch/m68knommu/platform/520x/Makefile  |    2 +-
 arch/m68knommu/platform/523x/Makefile  |    2 +-
(Continue reading)

Oleg Verych | 10 Sep 00:45 2007
Picon
Picon

CPP includes ([PATCH 3/4] ia64: fix sn to add include files using EXTRA_CFLAGS)

On Sun, Sep 09, 2007 at 08:06:23PM +0200, Sam Ravnborg wrote:
> Changing the global CPPFLAGS is not the recommended way
> to add additional include dirs.
> Changed to use EXTRA_CFLAGS.

Maybe same magic can be applied to Rusty's "../../../" in i386
asm-offsets? Noone seems to use cpp's features much.

BTW, asm-values[0] are just don't needed any more?

[0] http://marc.info/?l=linux-kernel&s=asm-values
____

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Oleg Verych | 10 Sep 00:52 2007
Picon
Picon

moving to vger (Re: CPP includes ([PATCH 3/4] ia64: fix sn to add include files using EXTRA_CFLAGS))

On Mon, Sep 10, 2007 at 12:45:52AM +0200, Oleg Verych wrote:
[] 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> kbuild-devel mailing list
> kbuild-devel <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kbuild-devel

How about that? Kernel Janitors moved recently thankfully to David
Miller.

Footer, that i don't think is usefull anyway, will be 2 times shorter,
non changed subject will be shorter too :) This list is very low
traffic, so may be it'll be OK...

Thanks.
____

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Ingo Molnar | 10 Sep 21:29 2007
Picon
Picon

Re: [RFC] kbuild - introduce vdir to make life easier for x86_64


* Thomas Gleixner <tglx <at> linutronix.de> wrote:

> On Mon, 2007-09-10 at 21:11 +0200, Sam Ravnborg wrote:
> > One of the complaints raised about the current x86_64 Makfiles are 
> > the ugliness needed to reuse code from i386. Andi asked me if we 
> > could do something in kbuild to make this less ugly and below are 
> > the hack I could come up with.
> 
> while in general this is definitely a nice change, it does not really 
> solve the real problem of code scattered across two architectures. The 
> Makefile polishing is the least thing we care about.
> 
> Thanks,

i'd like to add it here that Makefile polishing is important - it's just 
that in the context of arch/*x86* the Makefile impact of the current 
cross-arch code sharing practice is one of the smaller problems and the 
Makefiles get cleaned up via the arch/x86 merge anyway.

	Ingo
Thomas Gleixner | 10 Sep 21:22 2007
Picon

Re: [RFC] kbuild - introduce vdir to make life easier for x86_64

Sam,

On Mon, 2007-09-10 at 21:11 +0200, Sam Ravnborg wrote:
> One of the complaints raised about the current x86_64
> Makfiles are the ugliness needed to reuse code from i386.
> Andi asked me if we could do something in kbuild to make
> this less ugly and below are the hack I could come up with.

while in general this is definitely a nice change, it does not really
solve the real problem of code scattered across two architectures. The
Makefile polishing is the least thing we care about.

Thanks,

	tglx


Gmane