On Tue, 4 Dec 2007, Andi Drebes wrote: > > 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. Basically, if you ever have a #ifdef __BIG_ENDIAN or similar in the source code, you're simply doing something wrong. 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. So don't copy things around and change them from one mode to the other. Keep all the data structures in native LE ordering, and only when you really need to use them for some real data do you need to do the conversion. Now, for example, your code has two different "struct cramfs_inode" that you use: the unconverted and the converted one. That's confusing, but it's also error-prone. If you just have one type - the unconverted little-endian one - you have none of those issues. Linus - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
