Michael Shapiro wrote:
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
Different reasons involved:
- sparcv9/ls is an old Roger joke / test program for lack of a better term.
The reason for its existence is due to the semantic that stat() returns
EOVERFLOW if the file attributes can't fit into the 32-bit structures.
Certainly it can be deleted from the mini-root, but it has its uses :)
Why bother with a 32-bit ls at all then?
- adb and mdb are hard-links to one another of course. MDB will re-exec
the 32-bit version of itself when asked to debug a 32-bit program.
So on a 64-bit kernel isaexec runs 64-bit mdb, which may run 32-bit mdb.
For mini-root I think it's just a question of whether you want debug tools.
Okay, understood. (I sort of doubt the value of mdb in the miniroot,
but I'll leave _that_ question for someone else to ponder.)
- savecore does similar and runs the version of itself which matches the
dump word size of the dump it finds. If you only have a 64-bit kernel
in the mini-root you don't need 32-bit savecore, and vice-versa.
So, on sparc, why bother with a 32-bit savecore at all? And on the x86
miniroot, which I believe is 32-bit only, why bother with a 64-bit
savecore? We can save some disk here.
- truss doesn't re-exec itself: the 64-bit truss runs on 32-bit processes.
So it just has both versions for virtue of isaexec.
So on SPARC, this is pointless. Just ship a 64-bit version.
- sort has a 64-bit binary because sort performance can be greatly improved
for large data sets based on amount of available memory. So 64-bit sort
is quite useful, but likely entirely unnecessary in the mini-root.
Ditto for this. Why bother with a 32-bit version on SPARC? And, why
bother with a 64-bit version in the x86 miniroot (assuming that x86
miniroot is 32-bit only)?
AFAICT, isaexec adds little value, on SPARC systems, when the only thing
it distinguishes is 32- vs. 64- bit, and there is no 32-bit kernel on
such systems.
-- Garrett
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
