public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: Andrew Morton <akpm@osdl.org>, Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH][2/2] SquashFS
Date: Mon, 14 Mar 2005 19:12:51 -0800	[thread overview]
Message-ID: <20050315031251.GI3163@waste.org> (raw)
In-Reply-To: <4235BC29.2060009@lougher.demon.co.uk>

On Mon, Mar 14, 2005 at 04:30:33PM +0000, Phillip Lougher wrote:

> +config SQUASHFS_1_0_COMPATIBILITY
> +	bool "Include support for mounting SquashFS 1.x filesystems"

How common are these? It would be nice not to bring in legacy code.

> +#define SERROR(s, args...)	do { \
> +				if (!silent) \
> +				printk(KERN_ERR "SQUASHFS error: "s, ## args);\
> +				} while(0)

Why would we ever want to be silent about something of KERN_ERR
severity? Isn't that a better job for klogd?

> +#define SQUASHFS_MAGIC			0x73717368
> +#define SQUASHFS_MAGIC_SWAP		0x68737173

Again, what's the story here? Is this purely endian conversion or do
filesystems of both endian persuasions exist? If the latter, let's not
keep that legacy. Pick an order, and use endian conversion functions
unconditionally everywhere.

> +#define SQUASHFS_COMPRESSED_SIZE_BLOCK(B)	(((B) & \
> +	~SQUASHFS_COMPRESSED_BIT_BLOCK) ? (B) & \
> +	~SQUASHFS_COMPRESSED_BIT_BLOCK : SQUASHFS_COMPRESSED_BIT_BLOCK)

Shortening all these macro names would be nice..

> +typedef unsigned int		squashfs_block;
> +typedef long long		squashfs_inode;

Eh? Seems we can have many more inodes than blocks? What sorts of
volume limits do we have here?

> +	unsigned int		s_major:16;
> +	unsigned int		s_minor:16;

What's going on here? s_minor's not big enough for modern minor
numbers.

> +typedef struct {
> +	unsigned int		index:27;
> +	unsigned int		start_block:29;
> +	unsigned char		size;

Eep. Not sure how bit-fields handle crossing word boundaries, would be
surprised if this were very portable.

> + * macros to convert each packed bitfield structure from little endian to big
> + * endian and vice versa.  These are needed when creating or using a filesystem
> + * on a machine with different byte ordering to the target architecture.
> + *
> + */
> +
> +#define SQUASHFS_SWAP_SUPER_BLOCK(s, d) {\
> +	SQUASHFS_MEMSET(s, d, sizeof(squashfs_super_block));\
> +	SQUASHFS_SWAP((s)->s_magic, d, 0, 32);\
> +	SQUASHFS_SWAP((s)->inodes, d, 32, 32);\
> +	SQUASHFS_SWAP((s)->bytes_used, d, 64, 32);\
> +	SQUASHFS_SWAP((s)->uid_start, d, 96, 32);\
> +	SQUASHFS_SWAP((s)->guid_start, d, 128, 32);\
> +	SQUASHFS_SWAP((s)->inode_table_start, d, 160, 32);\
> +	SQUASHFS_SWAP((s)->directory_table_start, d, 192, 32);\
> +	SQUASHFS_SWAP((s)->s_major, d, 224, 16);\
> +	SQUASHFS_SWAP((s)->s_minor, d, 240, 16);\
> +	SQUASHFS_SWAP((s)->block_size_1, d, 256, 16);\
> +	SQUASHFS_SWAP((s)->block_log, d, 272, 16);\
> +	SQUASHFS_SWAP((s)->flags, d, 288, 8);\
> +	SQUASHFS_SWAP((s)->no_uids, d, 296, 8);\
> +	SQUASHFS_SWAP((s)->no_guids, d, 304, 8);\
> +	SQUASHFS_SWAP((s)->mkfs_time, d, 312, 32);\
> +	SQUASHFS_SWAP((s)->root_inode, d, 344, 64);\
> +	SQUASHFS_SWAP((s)->block_size, d, 408, 32);\
> +	SQUASHFS_SWAP((s)->fragments, d, 440, 32);\
> +	SQUASHFS_SWAP((s)->fragment_table_start, d, 472, 32);\
> +}

Are those positions in bits? If you're going to go to the trouble of
swapping the whole thing, I think it'd be easier to just unpack the
and endian-convert the thing so that we didn't have the overhead of
bitfields and unpacking except at read/write time. Something like:

void pack(void *src, void *dest, pack_table_t *e);
void unpack(void *src, void *dest, pack_table_t *e);
size_t pack_size(pack_table_t);

where e is an array containing basically the info you have in the
above macros for each element: offset into unpacked structure,
starting bit in packed structure, and packed bits.

-- 
Mathematics is the supreme nostalgia of our time.

  parent reply	other threads:[~2005-03-15  3:14 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-14 16:30 [PATCH][2/2] SquashFS Phillip Lougher
2005-03-15  1:06 ` Andrew Morton
2005-03-15  1:14   ` Phillip Lougher
2005-03-15  3:01     ` Andrew Morton
2005-03-15 17:16       ` Phillip Lougher
2005-03-15 18:21       ` Paulo Marques
2005-03-21 10:14         ` Pavel Machek
2005-03-21 15:56           ` Phillip Lougher
2005-03-21 19:00             ` Pavel Machek
2005-03-21 18:03               ` Phillip Lougher
2005-03-21 22:49                 ` Pavel Machek
2005-03-22  2:41                   ` Josh Boyer
2005-03-22  2:58                     ` David Lang
2005-03-22  3:04                     ` Andrew Morton
2005-03-22  2:59                       ` Phillip Lougher
2005-03-22  5:32                         ` Paul Jackson
2005-03-22  3:34                   ` Phillip Lougher
2005-03-22  5:37                     ` Stefan Smietanowski
2005-03-21 22:32               ` Mws
2005-03-21 22:44                 ` Pavel Machek
2005-03-21 22:54                   ` Mws
2005-03-22  3:36                   ` Phillip Lougher
2005-03-22  7:19                 ` Stefan Smietanowski
2005-03-22  5:20               ` Willy Tarreau
2005-03-21 18:08           ` Mws
2005-03-21 18:54             ` Pavel Machek
2005-03-21 22:23               ` Mws
2005-03-21 22:31                 ` Pavel Machek
2005-03-21 22:47                   ` Mws
2005-03-21 22:56                     ` Pavel Machek
2005-03-15  3:12 ` Matt Mackall [this message]
2005-03-15 23:25   ` Phillip Lougher
2005-03-16  0:57     ` Andrew Morton
2005-03-16  1:04     ` Matt Mackall
2005-03-16  4:19       ` Matt Mackall
2005-03-15  5:38 ` Greg KH

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=20050315031251.GI3163@waste.org \
    --to=mpm@selenic.com \
    --cc=akpm@osdl.org \
    --cc=greg@kroah.com \
    --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