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: <Pine.LNX.4.64.0711100220370.4780@asgard.lang.hm>
Date:	Sat, 10 Nov 2007 02:32:43 -0800 (PST)
From:	david@...g.hm
To:	Sam Ravnborg <sam@...nborg.org>
cc:	Jeff Garzik <jeff@...zik.org>, 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, 10 Nov 2007, Sam Ravnborg wrote:

> Subject: Re: [PATCH 0/11 v3] enable "make ARCH=x86"
> 
> 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

as a user I think it would be a good idea to keep the i386/x86_64 options 
around for a few kernel revisions to maintain compatibilty with people's 
build scripts (not everyone upgrades every kernel release. I've been 
running kernel.org kernels in production for over 10 years and between the 
scheduler changes in .23 and the arch merge in .24 even I'm going to be 
very cautious until .25 or .26 fleshes out all the gotchas, although the 
per-device buffer work is valuble enough that a couple systems will get 
it soon)

you also need a transition for make oldconfig for several versions

i386 should imply 32 bit and the old CPU i386 options
x86_64 should imply 64 bit and the old amd_64 cpu options

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

unknown, which cpu did you select to compile it for? and in the case of 
cpus that support both modes, which one did you select? I don't know if 
it makes sense to just list K8-32 and K8-64 as seperate cpu options in one 
menu or to have a 32/64 bit switch and then two seperate cpu menus (I 
suspect the first is better in the long run) but either way can work.

> 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...

why do you need to have it as a specific command-line option instead of 
being part of your cpu selection?

and isn't there something like march=686 that could be extended to 
march=k8-32 vs march=k8-64?

march=s390-64 or s390-32 doesn't look nearly as bad as s39064 that you 
listed above.

David Lang

-
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