<snip>
> No, no, what I meant about not having any #ifdef __LITTLE_ENDIAN was to do
> the code do the same thing *regardless* of endianness. In other words, a
> simple:
>
> struct cramfs_inode {
> __le32 mode_uid; /* CRAMFS_MODE_WIDTH:CRAMFS_UID_WIDTH */
> __le32 size_gid; /* CRAMFS_SIZE_WIDTH:CRAMFS_GID_WIDTH */
> __le32 namelen_offset; /* CRAMFS_NAMELEN_WIDTH:CRAMFS_OFFSET_WIDTH */
> };
>
> #define CRAMFS_UID_MASK ((1ul << CRAMFS_UID_WIDTH)-1)
> #define CRAMFS_GID_MASK ((1ul << CRAMFS_GID_WIDTH)-1)
> #define CRAMFS_NAMELEN_MASK ((1ul << CRAMFS_NAMELEN_WIDTH)-1)
>
[...]
> static inline u32 cramfs_offset(struct cramfs_inode *inode)
> {
> return le32_to_cpu(node->namelen_offset) >> CRAMFS_NAMELEN_WIDTH;
> }
This requires changing the on-disk-structure (even the current "little endian only" one).
The problem is caused by the way GCC (and perhaps other compilers aswell) arranges
the 6 bits bits for the namelength and the 26 bits for the offset within the 32 bits.
I spent quite some time on figuring out how this is actually 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|
(where oXX means offset bit XX, nXX means namelength bit XX, | marks the beginning
/ end of a byte and . is a bit separator)
On big endian machines, the data is arranged differently:
|n06.n05.n04.n03.n02.n01.o26.o25|o24.o23.o22.o21.o20.o19.o18.o17|
|o16.o15.o14.o13.o12.o11.o10.o09|o08.o07.o06.o05.o04.o03.o02.o01|
So masking and then shifting *the whole* masked data doesn't solve the problem.
> static inline u32 cramfs_namelen(struct cramfs_inode *inode)
> {
> return le32_to_cpu(node->namelen_offset) & CRAMFS_NAMELEN_MASK;
> }
>
> See? No #ifdef's required, no different code-paths, and the code generated
> will be pretty much optimal too.
See above.
> ([...]but you get the idea).
Yes. And I agree with you. But making this consistent for all fields of cramfs structures
requires changing the on-disk-structure. This would mean that we don't only break support
for big endian images, but also for current little endian images.
However, I'm not totally against this solution. But one should keep in mind what I pointed
out 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
