Jason Thorpe (thorpej@nas.nasa.gov) wrote:
: To throw some fuel on this fire, let me suggest an approach...
: 
: At USENIX, Christos, Charles, and myself discussed a way of doing 
: this...  Namely, find and isolate _all_ the places in FFS where data is 
: actually written to or read from disk.  Set up an ops vector - one for 
: "native" and one for "swapped".  The "native" ordering is tried first, 
: and, if the magic number is wrong, the "swapped" ops are tried.  If that 
: fails, return an error like we currently do on bad magic number.
: 
: When the attempt to read the magic number is made, the ops vector pointer 
: is already set up, so if it succeeds, you don't need to do any additional 
: processing.  In the event you end up using the "swapped" ops, set a mount 
: flag so that situation is visible to userland.
: 
: One problem with this is that it stand the chance of slowing down the 
: filesystem; on some architectures, jumping through a function pointer can 
: be relatively expensive (longer instruction timings, instruction cache 
: misses, etc.)  However, it's worth noting that we already jump through a 
: function pointer or three during any file system operation (the vnode and 
: vfs ops vectors that each file system provides to the upper layers), so 
: the effect of one more might not be noticeable at all.

Would we need any more function pointers than are use anyway, in our
current approach?

We can duplicate the filesystem, factor out endianness-independent code
into common functions, and the filesystem mount() vector will autodetect
the endiannes, and plug the right version of the other functions in.

This way, there is NO additional indirection, and maybe a direct subroutine
call or two more.

And for people with tight memory, we would create

options ALIEN_BYTE_ORDER_FFS	# use VAX/i386/DECstation written ffs
				# (you guess I own a BE machine)

	Ignatios Souvatzis