[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JFFS2 endianness.
> The byte swapping gets lost on modern processors in the initial cache
> miss to load the data (if the code is good).
Absolutely. The CPU overhead of byteswapping is lost way down in the noise.
The _difference_ between the efficiency of byteswapping on BE and LE boxen,
based on the fact that LE boxen have to do it more often, even more so.
All things being equal, I'd probably have been inclined to pick BE, just
because most of the development is done on LE boxen, and it'd make sure I
noticed if I missed a byteswap somewhere. However,...
> Worry about installed base (of removable media), and use that as your
... all things aren't equal. We have a reasonably large installed userbase,
the vast majority of which is LE. Switching the format to BE would just be
too painful, just to make the debugging easier.
> 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.
What I _will_ do, to accommodate those running BE JFFS2 right now, is avoid
the standard cpu_to_le16() macros, and instead provide and use some new
jffs2-specific ones. Then it's trivial to just change the definition of
those in just one place to make it BE or native-endian again. People
upgrading existing BE boxen can do just that - and I'll do it for testing
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org