Bart Smaalders wrote:
> Darren J Moffat wrote:
>
>> I'm derailing this automatic approval. I want at least a fast-track
>> that explains why the asymetry between SPARC and x86 is actually
>> useful in addition to what Joe asked for.
>
> Because we support x86 machines that don't implement 64 bit support?
> The same reason we ship a 32 bit and a 64 bit x86 kernel?
>
>> I think this should actually be a full case rather than a fast-track
>> given this would be a significant architectural change. As Joe said
>> the GNU part is irrelevant here what is relevant is the change in
>> direction.
>>
>
> Whether a particular executable is delivered as a 32 bit binary, 64
> bit binary
> or shell script/java/python.... seems more of an implementation detail
> rather
> than an architecture change.
>
> I assume that the proposal here is to deliver 64 bit versions of these
> commands
> on sparc, and both 32 and 64 bit versions on x86.
>
> My question here is whether there is a plan about what to do w/ 32bit
> only (x86) systems in regards to whatever limit this change avoids....
I think the above question (the behavioral difference) is one that
really needs to be addressed. It may be that the answer is that we
don't care about the limit on 32-bit only systems, but what are we going
to do for 64-bit-capable x86 boxes? I am pretty unhappy with the
current isaexec() solution - the extra fork/exec combo seems
"unfortunate", particularly for utilities that might be executed heavily
in embedded scripts. (The shell, and coreutils, seems to fall into this
category.)
My personal preference, for now, would be to deliver *both* 32- and
64-bit versions of the applications for both SPARC and x86, but deliver
the 64-bit versions in a separate path (/usr/bin/sparcv9 and
/usr/bin/amd64 or somesuch), so that end users can just adjust their
$PATH appropriately if they know they need or want 64-bit capable
programs (I think for the vast majority of users, this will not be
necessary.)
This has the added advantage of minimizing the ARC "impact" of this, by
not changing the "default" version of the tools right now. (And doesn't
preclude making such a change later, particularly if at some point we
decide we can stop supporting 32-bit-only processors, which I imagine we
might do some number of years in the future.)
-- Garrett
