On Fri, 22 April 2005 09:23:56 +0200, Jörn Engel wrote:
> +
> +#define SQUASHFS_SWAB(XX) \
> +u##XX squashfs_swab##XX(u##XX x) { return swab##XX(x); } \
> +u##XX squashfs_ident##XX(u##XX x) { return x; }
> +
> +SQUASHFS_SWAB(16)
> +SQUASHFS_SWAB(32)
> +SQUASHFS_SWAB(64)
> +
> +
While it made one function somewhat nicer, I'm not entirely sure this
approach is a good idea in general. With all the bitfields used,
simple byte-swabbing just doesn't cut it. Really, the best strategy I
can think of would still be considered A Mess(tm).
It may be time to create a new version of the on-medium layout of the
filesystem. The new layout is explicitly made big-endian (or
little-endian, whatever) and all structs consist exclusively of u8,
u16, u32 and u64, or their leXX or beXX counterparts.
Advantages:
Swapping is trivially done by beXX_to_cpu and friends.
Code size should decrease significantly.
Disadvantages:
New, incompatible layout. FS compatibility and code shrinkage are
mutually exclusive. The thing should be called squashfs2 and have a
completely different code base.
'Bitfield'-access is done by explicit masking and shifting.
Again, this option looks just as rotten as all the previous
alternatives. The decision is up to you, Phillip.
Jörn
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
-- unknown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
