On Tue, Mar 30, 2010 at 10:20 AM, Garrett D'Amore <garr...@damore.org> wrote: > On 03/30/10 01:17 AM, Darren J Moffat wrote: >> >> On 30/03/2010 04:21, Jason King wrote: >>>>> >>>>> I don't know of any... they're awkward to use in most cases; coding >>>>> some higher level routines may help. >>>> >>>> IIRC, this is *precisely* how ddi_get16 and friends work when they are >>>> used >>>> with a handle that indicates little-endian device order. Of course, >>>> this is >>>> only useful in the kernel... >>> >>> Even in the kernel, zfs at the very least could benefit (since it does >>> endian conversion as needed), though there might be other areas as >>> well. >> >> For ZFS see $SRC/common/fs/zfs/dmu.c the following routines in >> particular: >> >> byteswap_uint64_array() >> byteswap_uint32_array() >> byteswap_uint16_array() >> byteswap_uint8_array(). >> >> Note that in the implementation of those to swap the elements the >> corresponding BSWAP_XX() macro is used. >> >> Those macros are defined in <sys/byteswap.h> >> >> For x86 they use hton[s,l,ll]() which are implemented in asm. >> For everything else (ie SPARC) they use & < | to do with swapping. >> >> If there is a way to use VIS (or any other SPARC instructions for that >> mater) to make byteswapping faster then please implement them as sparc >> versions of hton[s,l,ll]() and fixup <sys/byteswap.h>. Doing it that way >> means that ZFS, Crypto, Networking and a whole lot of other code gets to >> take advantage of it. > > We should make sure that these are done for SPARC with little endian > swapping. The only concern I can see would be if the use of the ASI might > have bad side effects with respect to the cache. Perhaps someone familiar > with SPARC architecture can comment on that. > > For hto*, on SPARC its a no-op. Does ZFS use big endian, little endian, or > native endian for is on-disk structures? I'd guess native, but, I'm not > sure.
Last time I checked, it was native, with 'reader makes right', and I believe a bit in one of the data structures indicates the order (so it's possible that a zpool that gets imported and exported on sparc and x86 could be mixed). > > I'd guess that outside of certain code dealing with MS filesystems, and > device drivers dealing with little-endian registers, there is probably > little other use of little-endian data on SPARC systems. I'm pretty sure > that TCP/IP, XDR/NFS, and even crypto bignum keys are all formatted using > big-endian. (I'd need to double check on the bignum stuff... its my > recollection though.) > > - Garrett > > > _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
