Re: [PATCH] Endianness-aware mkcramfs

[Matthew Dharm]

--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.

Matt

On Tue, Dec 04, 2001 at 04:39:18PM -0800, H. Peter Anvin wrote:
> Ingo Oeser wrote:
>=20
> >=20
> > Yes, from a CS point of view.=20
> >=20
> > But practically cramfs is created once to contain some kind of
> > ROM for embedded devices. So if we never modify these data again,
> > why not creating it in the required byte order?=20
> >=20
> > Why wasting kernel cycles for le<->be conversion? Just because
> > it's more general? For writable general purpose file systems it
> > makes sense, but to none of romfs, cramfs etc.
> >=20
>=20
>=20
> Because otherwise you far too easily end up in a situation where every
> system suddenly need to be able to support *BOTH* endianisms, at which
> point you're really screwed; supporting dual endianism is significantly
> more expensive than supporting the "wrong" endianism, and it affects all
> systems.
>=20
> Nip this one in the bud.
>=20
> 	-hpa
>=20
>=20
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--=20
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.=
net=20
Maintainer, Linux USB Mass Storage Driver

M:  No, Windows doesn't have any nag screens.
C:  Then what are those blue and white screens I get every day?
					-- Mike and Cobb
User Friendly, 1/4/1999

--vkogqOf2sHV7VnPd
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8DW8lz64nssGU+ykRAuFAAKDYjdcFn0R/2fSyZfT36yIfN3dhzACeMPRZ
pNWppLlrw8i2BtiO8O2QoPA=
=oqd1
-----END PGP SIGNATURE-----

--vkogqOf2sHV7VnPd--