[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 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.
Cambridge Research Laboratory
Compaq Computer Corporation
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org