On Thu, 31 Mar 2005 20:05:44 -0600 Jason Huebel <[EMAIL PROTECTED]> wrote: | On Thursday 31 March 2005 7:55 pm, Jason Huebel wrote: | > Now, If ciaranm is offering to make the massive changes required for | > this then maybe. Otherwise, it isn't happening anytime soon. | | I recend the offer for ciaranm to do the changes if he feels like it. | That was, if you didn't catch it, sarcasm. But I'm not very good at | sarcasm. :-) | | We've added the aforementioned note to our documentation explaining | why amd64 is the chosen keyword for the x86-64 arch.
Hrm, I think the wording maybe isn't clear enough. What is proposed is that amd64 uses the x86 keyword. I've attached a revised version with that clarified -- I guess not everyone's aware of the specifics of the sparc merge so I made the purpose more explicit. -- Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm
GLEP: ??
Title: x86/amd64 KEYWORDS Merge
Version: $Revision: $
Author: Ciaran McCreesh <[EMAIL PROTECTED]>
Last-Modified: $Date: $
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 01-April-2005
Post-Date: 01-April-2005
Abstract
========
The x86 and x86-64 architectures currently use different ``KEYWORDS`` values.
This GLEP proposes to fix this issue by mmerging these keywords.
Motivation
==========
Currently, Gentoo uses the ``x86`` keyword to indicate the architecture
used by IBM PCs with Intel 80x86 CPUs (and, of course, the clones). The
``x86-64`` architecture, which is ``x86`` with a small number of
extensions for 64-bit numeric and 40 bit address support, is denoted by
the confusing ``amd64`` keyword.
This situation is less than ideal for several reasons.
Confusing and Inaccurate Name
-----------------------------
* Intel also produce x86-64 capable ('enabled' in PC marketing speak)
CPUs. It is likely that other vendors will follow suit at some point in
the future.
* AMD also produce non-x86 (full) 64bit CPUs, which are covered by the
mips keyword rather than the amd64 keyword.
Against Existing Behaviour
--------------------------
The split keyword for x86 and x86-64 is against the way other Gentoo
architectures operate. The mips keyword covers 32bit, 64bit and mixed, and
big endian and little endian CPUs. Similarly, the sparc keyword covers
both 32bit (v7 and v8) and 64bit (v9) CPUs following a merge several years
back.
The sparc merge has been a demonstrated success, and mips is easily
handling a far larger hardware difference with a single keyword (there is
more difference between, say, ip22 and ip27 than between x86 and x86-64,
even when the 32/64bit issue is ignored).
The existing ``PROFILE_ARCH`` setup is more than adequate to handle any
small differences, although adding this to ``USE_EXPAND`` may simplify
rare dependency issues.
Detrimental for the Users
-------------------------
Currently, less than half the packages that are available to x86 users are
also available to x86-64 users. This leads to countless pointless bugs and
confused users.
The x86-64 stable tree is also badly lagging, with 7% (at the time of
writing) of its packages being behind the x86 tree. For reference, sparc
(which has a higher number of packages keyworded) has only 2% behind --
this clearly demonstrates the superiority of the merged keyword system.
Implementation Issues
=====================
There is already a script available for merging keywords. Although Rodney
Rees (manson) is no longer with the project, he is still in contact with
several existing developers and so obtaining this script should not be
difficult. As was seen from the sparc32/sparc64 merge, this is easy to do
and the existing script is more than sufficient to handle the whole
implementation without breaking anything.
Backwards Compatibility
=======================
This is handled by the script. Some small changes to bugzilla and the
mailing lists will be necessary.
Copyright
=========
This document has been placed in the public domain.
vim: set tw=74 fileencoding=utf-8 :
pgpukfRqyKyRB.pgp
Description: PGP signature
