[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: JFFS2 endianness.

The way it works in X is that there is a dispatch table, and each protocol 
request/response gets swapped on each request/response type basis, so 
we've swizzled function pointers, rather than having conditional branches 
in the mainline code.  But this was a design done in advance, rather than 
ex-post-facto modifications to a code base.

But who am I to argue, on a little endian implementation :-).  In any 
case, I think the conversion option being discussed, whether gradual by 
the file system code itself, or via a tool, is the right idea.

Again, no matter how implemented, if the byteswapping itself is done
efficiently, I don't think you'll see even a measurable difference.

Machines have gotten so fast relative to cache misses that generally it 
all gets hidden in cache misses (unless, as I've seen happen once, one's 
byte swapping macros are so dumb as to require writing a temporary to 
memory that then becomes an issue; in that case, reworking the macros 
made the measurable overhead go away (I was tinkering with Xerox ILU at 
the time)).

> > The other attitude is what we did in X, where the core protocol does
> > "server makes it right", and byte swaps appropriately if needed.
> That would be feasible, but I don't want to - I suspect that the difference
> in code size and efficiency would be at least measurable if you have
> conditional branches around the byteswapping. That's fine in the X server
> but in the embedded context every little helps. Or hinders, as the case may
> be. There are relatively few BE JFFS2 filesystems out there, and I'd prefer
> to just put them behind us.

			- Jim

Jim Gettys
Cambridge Research Laboratory
Compaq Computer Corporation

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com