From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Drebes Subject: Re: [PATCH 1/2] Make cramfs little endian only Date: Tue, 4 Dec 2007 22:31:54 +0100 Message-ID: <200712042231.54640.lists-receive@programmierforen.de> References: <200712041259.52118.lists-receive@programmierforen.de> <200712042137.54508.lists-receive@programmierforen.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: =?iso-8859-1?q?J=F6rn_Engel?= , linux-fsdevel@vger.kernel.org, Karel Zak , Andrew Morton , Christoph Hellwig , Phillip Lougher To: Linus Torvalds Return-path: Received: from server001.webpack.hosteurope.de ([80.237.130.9]:36065 "EHLO server001.webpack.hosteurope.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750831AbXLDVcM (ORCPT ); Tue, 4 Dec 2007 16:32:12 -0500 In-Reply-To: Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > > Sure. This saves some definitions (and lines of code)... > > Here's the new patch (tested on the same machines mentioned in the first message). > > I tried to move as many lines as possible out of the endian dependent section. > > This really is the totally wrong way to do this. > > You should *not* convert inodes to CPU-endian mode at all. You should > *keep* them in the native mode, and then just use "le32_to_cpu()" when > actually using them. OK. I'll prepare a new patch and send it to the list (not today, it's already too late in the evening here). > Basically, if you ever have a > > #ifdef __BIG_ENDIAN > > or similar in the source code, you're simply doing something wrong. Perhaps I'm missing somehting, but I think for cramfs, unfortunately, there has to be this statement. The bitfields in the cramfs_inode structure cause some problems. You can't simply call le32_to_cpu() on them. Especially the namelength and offset fields are weird. There has to be at least one routine for each kind of machine that converts those values (or not -- depending ont the machine's endianness). > Btw, sparse can be a big help for things like this, by just marking the > actual disk data structures as being the right type (ie "__le32" and > friends), and then you can verify that any users will use "le32_to_cpu()" > as required, because sparse will warn about bad endianness. Ok, thanks for your advice. But what about the problems mentioned above? Andi