From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Drebes Subject: Re: [PATCH 0/2] cramfs: Add mount option "swapendian" Date: Thu, 15 Nov 2007 22:15:08 +0100 Message-ID: <200711152215.08695.lists-receive@programmierforen.de> References: <200711152129.25686.lists-receive@programmierforen.de> <200711152135.16932.lists-receive@programmierforen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, Christoph Hellwig , Andrew Morton To: Linus Torvalds Return-path: Received: from server001.webpack.hosteurope.de ([80.237.130.9]:41782 "EHLO server001.webpack.hosteurope.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757694AbXKOVPk (ORCPT ); Thu, 15 Nov 2007 16:15:40 -0500 In-Reply-To: Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.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