Re: [PATCH 1/2] Make cramfs little endian only

[Andi Drebes <lists-receive@programmierforen.de>]

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