> > 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
