lkml.org 
[lkml]   [2005]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 8/10] squashfs: add swabbing infrastructure
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-22 09:55    [W:0.057 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site