On Thu, 6 Dec 2007, Andi Drebes wrote:
>
> This requires changing the on-disk-structure (even the current "little endian
> only" one).
That makes no sense.
Your whole patch is about making it little-endian only.
If you do that, then big-endian is screwed. I'm ok with that, and support
it.
But then you just make sure that the little-endian bits are the same, and
now you're *done*.
> For little endian machines, the data arranged in the following way:
>
> |o02.o01.n06.n05.n04.n03.n02.n01|o10.o09.o08.o07.o06.o05.o04.o03|
> |o18.o17.o16.o15.o14.o13.o12.o11|o26.o25.o24.o23.o22.o21.o20.o19|
That's a singularly confused way or looking at it. The point is, the
first byte in a little-endian machine is the lowest bits, so the *correct*
way of looking at it is to see the above as one 32-bit word, and then it
looks like this:
bit-in-word: 31 .. 6 5 .. 0
bit-in-bitfield o25 .. o0 n5 .. n0
and my code works *perfectly*. When you do
static inline u32 cramfs_offset(struct cramfs_inode *inode)
{
return le32_to_cpu(node->namelen_offset) >>
CRAMFS_NAMELEN_WIDTH;
}
you are getting *exactly* the bits "o25..o0" that you want (ie the
offset).
> So masking and then shifting *the whole* masked data doesn't solve the
> problem.
Yes it does. Try it.
Linus
-
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
