HAMMER1 multi endianness support

[Tomohiro Kusumi]

This is actually a question to Matt who designed HAMMER1, but what was
the original design for HAMMER1's multi endianness support ? I've read
a design doc written in 2008, but it didn't have much details to it
other than saying we or someone could support both (i.e. support big
endian).

To be more specific, what's the intention of
sys/vfs/hammer/hammer_disk.h having ondisk volume signature macros in
both bytes-order ? We currently only use one of them on x86_64, and
the other one seems to be there to support both endianness, but how
would those two macros be used ?

#define HAMMER_FSBUF_VOLUME 0xC8414D4DC5523031ULL /* HAMMER01 */
#define HAMMER_FSBUF_VOLUME_REV 0x313052C54D4D41C8ULL /* (reverse endian) */

A general and easiest way for a filesystem to support both endianess
is to have a fixed ondisk endianness (e.g. little endian for ext2,
etc), and make the filesystem code use cpu_to/from_endianness
variants, so the code gets compiled with the right conversion to/from
the fixed ondisk endianness depending on which ever arch being used.
In this case a filesystem doesn't need to have an ondisk field to
detect endianness on runtime.

DragonFly currently runs only on x86_64, and the filesystem code
reads/writes ondisk stuff using host endian, thus ondisk stuff are in
little. If someone is to port HAMMER1 to any other OS with support for
big endian arch (or ARM port for DragonFly?) can we say HAMMER1 ondisk
is in little by design (because the OS that HAMMER1 was originally
written for only supported x86, and HAMMER1 simply used host endian) ?

or was it intended to do it in an adaptive way like (I think) ZFS ?