I noticed recently a few things, which seemed to me to be strange, on
the SPARC miniroot (and on the installed systems as well.)
First off, note that we do not have any support for a 32-bit SPARC
kernel anymore. And, I'm not sure there is any value in going back to
add support for one. (Is a 50MHz system running Solaris Nevada going to
be interesting? I strongly doubt it.)
So, one of the things I noticed is that there are some rather pointless
binaries floating around in /usr/bin (and probably elsewhere as well.)
For example, /usr/bin/sparcv7/ contains 32-bit versions of gcore, adb,
mdb, savecore, and truss. These add about 1.2MB to the miniroot.
/usr/bin/sparcv9/ contains a bunch more stuff, which is duplicated in
/usr/bin. For example, do we really need to ship both a 32-bit and
64-bit of /bin/ls? /bin/sort? etc. Do we think the 32-bit versions
run any faster? (Somehow, due to the extra overhead associated with
ioctl conversion, the fewer registers, and generally lower level of
optimization available, I strongly suspect that the 64-bit versions run
_faster_.)
Note that I find a similar case in /usr/sbin/sparcv9 as well. Although,
in that case, it appears that there is less duplication, and most of the
contents of /usr/sbin with equivalents in /usr/bin/sparcv9 are just
links to isaexec. But why even waste the extra cycles to do the
isaexec, when we could just have the binaries physically in /usr/sbin?
(Likewise for isaexec binaries in /usr/bin.)
I realize that for amd64/i86pc we still have to switch on the isa, since
we have both 32- and 64-bit kernels, but I think for SPARC that is
wasteful. The differences between the two platforms here could easily
be handled by the packaging system, which already understands the
difference between sparc and x86.
While here, I wonder if it makes sense to produce 64-bit versions of
some other famous binaries, at least on sparc. I'm thinking that
anything that is executed very frequently might see a performance
improvement from a 64-bit binary, thanks to higher levels of
optimization, additional registers, and the fact that ioctl conversion
does not have to be done by the kernel.
Thoughts? Is it worthwhile?
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
