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.
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).
As an example, to replace most instances of isaexec, we could create
/usr/bin/isaexec
as a mount point, and then during boot mount /usr/bin/i86 or
/usr/bin/amd64 on
/usr/bin/isaexec as a loopback mount. We also change the isaexec
hardlinks in /usr/bin to
be symbolic links pointing to /usr/bin/isaexec/{cmdname}.... no more
runtime isaexec
overhead and no fiddling w/ user paths.
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber.eng.sun.com http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
