From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: cramfs in big endian Date: Fri, 09 Nov 2007 17:03:01 -0800 Message-ID: <47350345.4010108@zytor.com> References: <200711062216.27156.lists-receive@programmierforen.de> <4731C308.8090008@slax.org> <200711072151.49032.lists-receive@programmierforen.de> <20071107224936.GA8517@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andi Drebes , Tomas M , linux-fsdevel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from terminus.zytor.com ([198.137.202.10]:35175 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762521AbXKJBHJ (ORCPT ); Fri, 9 Nov 2007 20:07:09 -0500 In-Reply-To: <20071107224936.GA8517@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Christoph Hellwig wrote: > On Wed, Nov 07, 2007 at 09:51:48PM +0100, Andi Drebes wrote: >> Hi! >> >>> I would suggest you to use squashfs instead of cramfs. >>> First, it's newer, it's better, it's actively developed, it doesn't have any >>> limits like the bad cramfs. >> I'm developing a new linux based firmware for my router which uses cramfs. >> Switching to squashfs still needs some time. Meanwhile, I have to work with >> cramfs. As the router uses the big endian format and as my machine works with >> the little endian format, I'm unable to mount the router's filesystem images. > > Making cramfs endianess-independent shouldn't be much work. Take a look > at the helpers in fs/ufs/swab.h and use them for every ondisk access in > cramfs. Drop me a not if you need some help. And it would suck. Hard. Endian-independent code is slower than wrong-endian code, because of the necessary conditionals. Thus, you DO NOT WANT this(*). The only way to not make it totally suck is to compile the code twice and do switching at a VERY high level -- in effect, creating two separate filesystem drivers. -hpa (*) Readonly filesystems like iso9660 have attempted to be *both*-endian, by having its datastructures in both forms at all times. That is inefficient with space, but would be CPU-efficient in theory. Unfortunately it causes output validation problems; apparently many iso9660 mastering programs output invalid bigendian information as it is never tested; consequently, many bigendian platforms read the littleendian information anyway.