Re: [PATCH] Endianness-aware mkcramfs

[Matthew Dharm <mdharm-kernel@one-eyed-alien.net>]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]