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]
Date:	Sat, 10 Nov 2007 10:39:48 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Paul Mundt <lethal@...ux-sh.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>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/11 v3] enable "make ARCH=x86"

On Sat, Nov 10, 2007 at 03:24:53AM -0500, Jeff Garzik wrote:
> Paul Mundt wrote:
> >This is one of the things I've been wondering about with an sh/sh64
> >unification, as we have no option but having completely different
> >toolchains, and CONFIG_64BIT=y won't work there when they are both
> >using a 32-bit ABI.
> 
> 
> IMO it seems like you ought to be able to do
> 
> 	make ARCH=sh
> 		or
> 	make ARCH=sh64
> 
> and have it do the right thing.  Ditto for ppc/ppc64, etc.
> 
> Sane, straightforward, simple, consistent with existing practice...

Excpet that setting ARCH=... imply more than the 32/64 bit choice.
One other thing is that using ARCH=xxx64 tells people
that the kernel is located in arch/xxx64/boot/

So what is it we want ARCH=xxx to say?
a) the exact architecture to use? (seems not)
b) a good hint about the architecture and a 32/64 bit selector (seems so)
c) part of the location of the build kernel (not discussed)
d) output of `uname -m` (?)

ARCH=xxx
is used for more than the 32/64 bit selection mechanish.
It is in fact an overloaded interface selecting several
things in one go.


And it is not even used consistent across the linux kernel.
Some use it for their generic architecture and later
decide on the bit size. Other let it imply the bit size.

In general a confusing thing that we are now getting used to.

In an not opposed to keep ARCH={i386,x86_64} but then we should
establish clear semantics.
What does it imply when I build a kernel with ARCH=i386?
- 32 bit, build kernel, uname -m

and what about the intuitive version: make ARCH=x86
Is this a 32 or 64 bit kernel?

How do we in a generic way say "this is a 64 bt kernel"?
Something that works equally well for s390, ppc, sh, sparc etc?

make ARCH=s39064 looks bad...
make ARCH=sh64 looks OK...

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ