All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Drebes <lists-receive@programmierforen.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-fsdevel@vger.kernel.org,
	Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/2] cramfs: Add mount option "swapendian"
Date: Thu, 15 Nov 2007 22:15:08 +0100	[thread overview]
Message-ID: <200711152215.08695.lists-receive@programmierforen.de> (raw)
In-Reply-To: <alpine.LFD.0.9999.0711151243200.4260@woody.linux-foundation.org>

> > This patch introduces the mount option "swapendian" for cramfs.
> > When this option is set, cramfs is able to mount an image that
> > was created on a machine whose endianness differs from the mounting
> > machine's one.
> 
> Please don't do it this way.
> 
> It would be *much* better to just standardize on one endianness, and be 
> done with it. That way there are no config options, no confusion, and the 
> code is smaller, simpler, and faster. Because nn unconditional byte swap 
> is generally faster than a conditional non-byte-swap!
This is a valid objection. The problem is that the endianness for cramfs
has never been standardized. Now there are filesystem images in both little
and big endian out there. I encountered this problem first when I tried to
mount my router's initrd. Yes, I know, I could have converted the image into
little endian. I just find that it is more consistent to support both kinds
of endianness.

> So can you please just make it little-endian? 
Actually, in my eyes, it would be better to create a new version of cramfs
that standardizes the endianness and the block size. But that doesn't solve
the problems one might have with old images.

> There can't be that many big-endian machines that really care about old 
> cramfs images..
s.a. (There's at least one...)

	Andi

  parent reply	other threads:[~2007-11-15 21:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-15 20:29 [PATCH 0/2] cramfs: support for other endianness Andi Drebes
2007-11-15 20:35 ` [PATCH 0/2] cramfs: Add mount option "swapendian" Andi Drebes
2007-11-15 20:45   ` Linus Torvalds
2007-11-15 20:46     ` Linus Torvalds
2007-11-15 20:51       ` Christoph Hellwig
2007-11-15 20:49     ` Christoph Hellwig
2007-11-15 20:57       ` Linus Torvalds
2007-11-15 21:15     ` Andi Drebes [this message]
2007-11-15 21:37       ` Linus Torvalds
2007-11-15 22:48         ` Phillip Lougher
2007-11-16 10:28           ` Andi Drebes
2007-11-16 15:44             ` Linus Torvalds
2007-11-15 21:03   ` Jörn Engel
2007-11-15 20:37 ` [PATCH 0/2] cramfs: update README file Andi Drebes
2007-11-15 20:43 ` [PATCH 0/2] cramfs: support for other endianness Andi Drebes

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=200711152215.08695.lists-receive@programmierforen.de \
    --to=lists-receive@programmierforen.de \
    --cc=akpm@linux-foundation.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.