public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Puhlman <jpuhlman@mvista.com>
To: "H. Peter Anvin" <hpa@zytor.com>,
	Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Endianness-aware mkcramfs
Date: Tue, 4 Dec 2001 17:02:35 -0800	[thread overview]
Message-ID: <20011204170235.M25671@mvista.com> (raw)
In-Reply-To: <3C0BD8FD.F9F94BE0@mvista.com> <3C0CB59B.EEA251AB@lightning.ch> <9uj5fb$1fm$1@cesium.transmeta.com> <20011205013630.C717@nightmaster.csn.tu-chemnitz.de> <3C0D6CB6.7000905@zytor.com> <20011204164941.A29968@one-eyed-alien.net>
In-Reply-To: <20011204164941.A29968@one-eyed-alien.net>; from mdharm-kernel@one-eyed-alien.net on Tue, Dec 04, 2001 at 04:49:41PM -0800

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...

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...

Just My humble oppinion
Jeremy

> 
> Matt
> 
> On Tue, Dec 04, 2001 at 04:39:18PM -0800, H. Peter Anvin wrote:
> > Ingo Oeser wrote:
> > 
> > > 
> > > Yes, from a CS point of view. 
> > > 
> > > 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? 
> > > 
> > > 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.
> > > 
> > 
> > 
> > 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.
> > 
> > Nip this one in the bud.
> > 
> > 	-hpa
> > 
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> -- 
> Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
> 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



  reply	other threads:[~2001-12-05  1:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3C0BD8FD.F9F94BE0@mvista.com>
2001-12-04 11:38 ` [PATCH] Endianness-aware mkcramfs Daniel Marmier
2001-12-04 18:42   ` H. Peter Anvin
2001-12-05  0:36     ` Ingo Oeser
2001-12-05  0:39       ` H. Peter Anvin
2001-12-05  0:49         ` Matthew Dharm
2001-12-05  1:02           ` Jeremy Puhlman [this message]
2001-12-05  1:12             ` H. Peter Anvin
2001-12-05  1:38             ` Matthew Dharm
2001-12-05 12:23               ` Daniel Marmier
2001-12-06  6:04                 ` H. Peter Anvin
2001-12-06 14:12       ` Pavel Machek
2001-12-18  2:52   ` Daniel Quinlan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011204170235.M25671@mvista.com \
    --to=jpuhlman@mvista.com \
    --cc=hpa@zytor.com \
    --cc=ingo.oeser@informatik.tu-chemnitz.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox