Messages in this thread | | | Date | Tue, 4 Dec 2001 17:38:19 -0800 | From | Matthew Dharm <> | Subject | Re: [PATCH] Endianness-aware mkcramfs |
| |
On Tue, Dec 04, 2001 at 05:02:35PM -0800, Jeremy Puhlman wrote: > On Tue, Dec 04, 2001 at 04:49:41PM -0800, Matthew Dharm wrote: > > There is another argument for supporting both endiannesses.... > > > > Consider an embedded system which can be run in either endianness. Sounds > > silly? MIPS processors can run big or little endian, and many people > > routinely switch between them. > Yes but typically this also includes a step of reflashing firmware or > swaping of firmware...So it would not be unrealistic to swap out the > filesystem as well...
Not necessarily. Consider a configuration where the kernel comes in over a network, but each board contains board-specific configuration data in flash. Reflashing isn't likely.
And yes, people do that. I have a day job in the single-board-computer industry.
> Since in a deployment situation you will always be sticking with one endianness > it makes sense that you would want the most speed for your buck...Since flash > filesystems are slow to begin with also adding in the decompression > hit you get from cramfs...it would seem to me that adding in le<->be > would just add to its speed reduction....That would seem to be a good > place to trim the fat so to speak...
The speed reduction is going to be minimal. Implement it via macros, like it's done everywhere else. If the endianness is one way, the macros get optimized away. If it's the other way, then they convert into an inlined byte swap.
Yes, there can be a small performance hit, but it's absolutely tiny.
Matt
-- Matthew Dharm Home: mdharm-usb@one-eyed-alien.net Maintainer, Linux USB Mass Storage Driver
It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 [unhandled content-type:application/pgp-signature] | |