Bart Smaalders wrote:
> Garrett D'Amore wrote:
>
>> 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.)
>
> Why should we continue to deliver a 32 bit version of a command, if today
> we always exec the 64 bit varient? Anything that goes through isaexec
> today should be 64 bit only on SPARC. The fact that we still use
> isaexec on
> SPARC at all is a bug.
Agreed, if it is true that we always use isaexec. But, are there cases
where a separate 32-bit version is useful on SPARC for reasons other
than described here (or where we don't "always use isaexec")? (For
example, is it true that a 64-bit version never incurs any performance
regression? Or is there ever a reason to use a 32-bit program to
validate that a program -- script or otherwise -- will function properly
on 32-bit-only architectures?)
>
> x86 will for now need to deliver both 32 and 64 bit binaries. If
> you're worried
> about the performance issues involved w/ isaexec, then let's design
> something
> better.... but have the user adjust their path is a complete
> non-starter and
> we still need isaexec for the correctness cases (proc tools, etc).
Yes, isaexec is needed for correctness, but its not used on any
performance critical paths, and remains, IMO, an ugly hack rather than
an elegant solution.
I'm not adverse to designing something better (I like the idea), but my
first gut instinct is "not this case".
Modifying $PATH is a crummy solution, I agree, but as an interim hack to
enable delivery for the few users that need the 64-bit semantics (and I
think the number that actually do need them for these apps is almost
vanishingly small) they have a workaround until we can come up with
something better.
(I'm also looking for a way to allow this case to proceed forward,
without requiring it to block on a larger set of architectural problems
that the project team is probably ill-equipped to solve.)
(As far as "something better", I think I prefer something along the
lines of how AFS handles it, where $VARIABLE could be used within a
symbolic link -- the kernel expands the variable when following the
symlink. But we shouldn't try to design the solution here, I think.)
-- Garrett
