> 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 :) - 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. - 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. - 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. - 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. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
