Garrett D'Amore wrote:
> 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?
But |isaexec()| won't help you since it cuts stuff like |ARG_MAX| to the
32bit limit. And the original idea was to do the change _only_ for
machines which are native 64bit platforms (e.g. SPARC and two Solaris
ports which shall-not-be-named here) and not to try to boil the ocean by
enforcing the change for all platforms.
> >> 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.)
Please remove the shells from the list. As I explained earlier (and in
the original ksh93-integration ARC case, and via IRC, and via email
etc.) the extra |exec()| is usually (except for cases like $
/usr/bin/ksh93 -c 'true' #) canceled-out when the shell uses builtin
commands or avoids calling |fork()| for subshells (that was at least the
case of ksh93). "bash" may slightly different but it's still something
which will IMO not hurt compared to _other_ stuff in "bash" which
currently goes badly wrong (e.g. default build options). Just by fixing
that we win more than you loose via "isaexec".
> 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.)
Groan... and noone will find these binaries. And /usr/bin/${MACH64}/ is
not an ARC'ed interface either...
... what about a compromise: Use 64bit versions of these utilities on
64bit-only kernels by default and use /usr/bin/64/ on platoforms like
Solaris/x86. Would that be acceptable for you?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
