Darren J Moffat wrote: > Joseph Kowalski wrote: [snip] > > #### Part 5: Enhancement of /usr/bin/sum > > The 5th part of this project specifies an enhancement to > > /usr/bin/sum and a new ksh93 built-in with the same name based on > > the AT&T AST "sum" command. The AT&T version of the "sum" utility > > provides extensions not present in the current Solaris "sum" > > utility, which are useful for small applications to generate hash > > sums (for example using the MD5 hash for MIME "Content-MD5:"-headers). > > > > Like other built-in commands named in PSARC/2006/550, the "sum" > > built-in in ksh93 will be bound to the /usr/bin/ pathname. The built-in > > "sum" in ksh93 will only be invoked if called with no pathname > > prefix, and if a /bin/sum or /usr/bin/sum executable is found > > first on the user's path. > > > > The stability of the "/usr/bin/sum" command and built-in command-line > > interface and the system variables documented in sum(1) is "Committed". > > > > An addition to the ksh93 test suite will gurantee compatibilty between > > previous versions of the /usr/bin/sum utillity and the new version. > > For the cryptographic hash functionality does this use libmd(3lib) or > does it introduce its own copy of the MD5/SHA* algorithm source ?
The AST/ksh93 code is designed to be portable and runs zillions of various platforms (I forgot how many are currently supported, Glenn may know the exact number better than I do) which means it uses it's own copy of MD5/SHA*/etc. > Note that a very significant amount of work has been done (and is still > being done) to make that libmd implementations of hash algorithms as > fast as possible on as many of the platforms Solaris supports. This > includes hand coded assembler variants suitable for AMD64 and EM64T and > optimising loads on UltraSPARC etc. I had access to a T2000 machine and several Ultra40+45 machines (thanks to Jesse Silver) at the OpenSolaris Summit 2007 and did some benchmarking. It seems that the code for the "sum" builtin (e.g. calling "sum" has builtin command and not as /usr/bin/sum) on an OpenSolaris/B72 installation is a lot faster for small files (likely as a result of the saved |fork()|+|exec()| per file) than /usr/bin/digest and only for very large files (e.g. $ mkfile 64MB foo001 #) /usr/bin/digest can outperform the "sum" builtin (BTW: It seems "digest" nor the related libraries make any use of "-xstrconst" or 64k largepages like the AST codebase does. IMO it may be nice to do some "footprint reduction" work in this case (e.g. map stack with 64k pages and allocate all buffers used for hashing from this stack (and forget MPSS - it won't help)) ... (and libmd(3LIB) has a small typo: It lists "/lib/64/libdnd.so.1" as 64bit shared object instead of "/lib/64/libmd.so.1")). > Please use libmd(3lib) unless there is a very compelling reason not to > do so - if there I would like to see that documented here. There is no compelling reason, however I would prefer to defer this to the putback following the one we've prepared for this ARC case. We already have all the code tested&&running, the upstream ksh93s+ development series is more or less "closed" (unless serve crashers&co. are found) and IMO it would be better to put a new feature like "Solaris libmd accerlation support" in the ksh93t- development cycle which would give us enougth time to test this feature... .. or short: Yes, we will do it but we would prefer not to rush this code into the codebase using a crowbar. Is that "Ok" 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;)
