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