Mailing List Archive

On Sat, 10 Nov 2007 21:40:38 +0100 Sam Ravnborg wrote:

> As discussed in another thread the right thing is to add a generic solution
> to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
>
> First step was to teach kconfig how to force 64BIT to a specific value.
> The x86 Kconfig file needed a small twist to use 64BIT as the symbol
> to seelct 32 or 64 bit.
> Then it was simple to add backward compatibility ARCH= settings.
>
> The patchset is not yet pushed out - I will await a bit feedback first.
>
> Shortlog and diffstat.
> kconfig: factor out code in confdata.c
> kconfig: use $K64BIT to set 64BIT with all*config targets
> x86: Use CONFIG_64BIT to select between 32 and 64 bit in Kconfig
> kconfig: document make K64BIT=y in README
> x86: introduce ARCH=i386,ARCH=x86_64 to select 32/64 bit

Hi Sam,
Looks good to me and should satisfy our habits^w usages models.

The one minor question is the environment variable name (K64BIT or
something else, like Guillaume brought up). Personally I don't
care how it's spelled. IOW, K64BIT is sufficient, but if there is a
goal to be able to place any CONFIG_symbol on the command line or
as an env. variable, they might as well all be named with CONFIG_*.

Thanks,
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Nov 10, 2007 at 02:33:02PM -0800, Randy Dunlap wrote:
> On Sat, 10 Nov 2007 21:40:38 +0100 Sam Ravnborg wrote:
>
> > As discussed in another thread the right thing is to add a generic solution
> > to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
> >
> > First step was to teach kconfig how to force 64BIT to a specific value.
> > The x86 Kconfig file needed a small twist to use 64BIT as the symbol
> > to seelct 32 or 64 bit.
> > Then it was simple to add backward compatibility ARCH= settings.
> >
> > The patchset is not yet pushed out - I will await a bit feedback first.
> >
> > Shortlog and diffstat.
> > kconfig: factor out code in confdata.c
> > kconfig: use $K64BIT to set 64BIT with all*config targets
> > x86: Use CONFIG_64BIT to select between 32 and 64 bit in Kconfig
> > kconfig: document make K64BIT=y in README
> > x86: introduce ARCH=i386,ARCH=x86_64 to select 32/64 bit
>
> Hi Sam,
> Looks good to me and should satisfy our habits^w usages models.
>
> The one minor question is the environment variable name (K64BIT or
> something else, like Guillaume brought up). Personally I don't
> care how it's spelled. IOW, K64BIT is sufficient, but if there is a
> goal to be able to place any CONFIG_symbol on the command line or
> as an env. variable, they might as well all be named with CONFIG_*.

The K64BIT varibale came up because it is more unique than CONFIG_64BIT.
Google turned up less than 20 hits[1] on K64BIT but 14900 on CONFIG_64BIT.
And I dunno if some people source their .config or other crazy stuff.

And then K64BIT was easier to type...
But if we assume this is internal stuff only then we could go
for the longer version and I will then suggest to prefix
the CONFIG_ symbol with K like in KCONFIG_64BIT which
has no hits with google right now!

I do not see this extended to 'any' CONFIG_ symbol
but maybe the 4 most important ones.
[64BIT, SMP, PREEMPT, ?]

[1] before my posting - now we are up to ~80.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sat, Nov 10, 2007 at 09:40:38PM +0100, Sam Ravnborg wrote:

> As discussed in another thread the right thing is to add a generic solution
> to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
>...

I seriously question this would be "the right thing".

32/64bit isn't that special that this and only this option would require
special casing, and the KISS principle of having only one way to specify
something like this has it's advantages.

> Sam

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Sun, Nov 11, 2007 at 06:09:45AM +0100, Adrian Bunk wrote:
> On Sat, Nov 10, 2007 at 09:40:38PM +0100, Sam Ravnborg wrote:
>
> > As discussed in another thread the right thing is to add a generic solution
> > to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
> >...
>
> I seriously question this would be "the right thing".
>
> 32/64bit isn't that special that this and only this option would require
> special casing, and the KISS principle of having only one way to specify
> something like this has it's advantages.

"The right thing" in the correct context.
It was discussed to keep ARCH={i386,x86_64} and the point I have
is that if we are going to extend ARCH=... to be useable to
specify kernel bit size then it should be done in a generic way
and not like it was done before on x86.

I do not consider the discussion about keeping/dropping
ARCH={i386,x86_64} as concluded.

And if we decide on keeping ARCH={i386,x86_64} then I have
questioned the semantics. Clear opinions are missing..

ARCH= semantic

Impact before now
================================================
32/64 bit yes yes
bzImage location yes no
different Kconfig files yes no
decide defconfig yes yes
asm symlink no no
build option yes no [1]

[did I miss anything? I think I did]

[1] ARCH=... select 32/64-bit during configuration.
There is no difference between ARCH={x86,i386,x86_64}
when building the kernel because the 32/64 bit
choice is done at configuration time.

The table above reflect the [now] semantics with the
patches that is present at lkml.

And the patch needed to implment the above
semantic (after the preparational stuff which
is generic) are:

$ git diff --stat HEAD~1..HEAD
Makefile | 18 ++++++++++++++----
arch/x86/Makefile | 8 ++++++--
scripts/kconfig/Makefile | 2 +-
3 files changed, 21 insertions(+), 7 deletions(-)


The scripts/kconfig/Makefile change is a bugfix that maybe
should be included in another patch. It is not x86 specific.

So 19 additional lines and 5 deleted lines to introduce the
ARCH= semantics above.

Sam

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,

On Sat, 10 Nov 2007, Sam Ravnborg wrote:

> As discussed in another thread the right thing is to add a generic solution
> to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.

Could you please point me to this discussion?
Thanks.

bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Mon, Nov 12, 2007 at 03:47:02AM +0100, Roman Zippel wrote:
> Hi,
>
> On Sat, 10 Nov 2007, Sam Ravnborg wrote:
>
> > As discussed in another thread the right thing is to add a generic solution
> > to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
>
> Could you please point me to this discussion?

It starts with this post from Jeff Garzik:
http://lkml.org/lkml/2007/11/9/274

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/