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.
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
