From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 8/10] squashfs: add swabbing infrastructure
Date: Fri, 22 Apr 2005 09:52:09 +0200 [thread overview]
Message-ID: <20050422075209.GI10459@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <20050422072355.GE10459@wohnheim.fh-wedel.de>
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
next prev parent reply other threads:[~2005-04-22 7:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-20 6:55 [PATCH] remove some usesless casts Jörn Engel
2005-04-20 15:20 ` Phillip Lougher
2005-04-20 21:33 ` Jörn Engel
2005-04-20 20:51 ` Phillip Lougher
2005-04-21 1:06 ` Jörn Engel
2005-04-21 6:36 ` Pekka Enberg
2005-04-21 6:48 ` Jörn Engel
2005-04-21 1:08 ` [PATCH 2/4] squashfs: kmalloc (less stack, less casts) Jörn Engel
2005-04-21 1:10 ` [PATCH 3/4] squashfs: (void*)ify squashfs_get_cached_block Jörn Engel
2005-04-21 1:11 ` [PATCH 4/4] squashfs: (void*)ify squashfs_read_data Jörn Engel
2005-04-22 7:20 ` [PATCH 5/10] squashfs: (void*)ify read_blocklist Jörn Engel
2005-04-22 7:22 ` [PATCH 6/10] squashfs: conserve stack, remove casts Jörn Engel
2005-04-22 7:22 ` [PATCH 6/10] squashfs: remove one cast Jörn Engel
2005-04-22 7:23 ` [PATCH 8/10] squashfs: add swabbing infrastructure Jörn Engel
2005-04-22 7:24 ` [PATCH 9/10] squashfs: remove some more casts Jörn Engel
2005-04-22 7:25 ` [PATCH 9/10] squashfs: first use of swabbing Jörn Engel
2005-04-22 7:52 ` Jörn Engel [this message]
2005-04-22 7:26 ` [PATCH 6/10] squashfs: remove one cast Jörn Engel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050422075209.GI10459@wohnheim.fh-wedel.de \
--to=joern@wohnheim.fh-wedel.de \
--cc=linux-kernel@vger.kernel.org \
--cc=phillip@lougher.demon.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®