> 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
Observations are all correct: I'm definitely not defending the way it is :) Short answer: when we EOL'd 32-bit SPARC kernels a bunch of 32-bit SPARC isaexec'd things should have been blown away but someone forgot, and There is a bunch of work to slowly shrink the mini-root size. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
