linux-kernel - Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071111115453.GA8112@uranus.ravnborg.org>
Date:	Sun, 11 Nov 2007 12:54:53 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	Jeff Garzik <jeff@...zik.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/