All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: greg@kroah.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][2/2] SquashFS
Date: Mon, 14 Mar 2005 17:06:53 -0800	[thread overview]
Message-ID: <20050314170653.1ed105eb.akpm@osdl.org> (raw)
In-Reply-To: <4235BC29.2060009@lougher.demon.co.uk>

Phillip Lougher <phillip@lougher.demon.co.uk> wrote:
>
> 

Please don't send multiple patches with the same Subject:.  Choose nice,
meaningful Subject:s for each patch.  And include the relevant changelog
details within the email for each patch rather than in patch 1/N.  See
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt and
http://linux.yyz.us/patch-format.html.


> @@ -0,0 +1,439 @@

[lots of comments from patch 1/2 are applicable here]

> +#define SQUASHFS_MAX_FILE_SIZE		((long long) 1 << \
> +					(SQUASHFS_MAX_FILE_SIZE_LOG - 1))

1LL would suit here.  Of a cast to loff_t.

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

squashfs_block_t and squashfs_inode_t, please.  If one must use typedefs...

> +typedef struct squashfs_super_block {
> +	unsigned int		s_magic;
> +	unsigned int		inodes;
> +	unsigned int		bytes_used;
> +	unsigned int		uid_start;
> +	unsigned int		guid_start;
> +	unsigned int		inode_table_start;
> +	unsigned int		directory_table_start;
> +	unsigned int		s_major:16;
> +	unsigned int		s_minor:16;
> +	unsigned int		block_size_1:16;
> +	unsigned int		block_log:16;
> +	unsigned int		flags:8;
> +	unsigned int		no_uids:8;
> +	unsigned int		no_guids:8;
> +	unsigned int		mkfs_time /* time of filesystem creation */;
> +	squashfs_inode		root_inode;
> +	unsigned int		block_size;
> +	unsigned int		fragments;
> +	unsigned int		fragment_table_start;
> +} __attribute__ ((packed)) squashfs_super_block;

Whoa.  Tons of bitfields in this file.  Are these on-disk data structures? 
If so, that's a problem for portability between architectures and possibly
compiler versions.  It also introduces locking complexity.

if they're in-core data structures then the bitfields are probably slower than using `int', as well.

> +typedef struct {
> +	unsigned int		inode_type:4;
> +	unsigned int		mode:12; /* protection */
> +	unsigned int		uid:8; /* index into uid table */
> +	unsigned int		guid:8; /* index into guid table */
> +} __attribute__ ((packed)) squashfs_base_inode_header;

See, if one CUP is modifying `inode_type' while another CPU is modifying
`mode', this struct can get trashed.

> +/*
> + * 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.
> + *
> + */

hmm, OK..  Tell us more?

> + * bitfields and different bitfield placing conventions on differing
> + * architectures
> + */
> +
> +#include <asm/byteorder.h>
> +
> +#ifdef __BIG_ENDIAN
> +	/* convert from little endian to big endian */
> +#define SQUASHFS_SWAP(value, p, pos, tbits) _SQUASHFS_SWAP(value, p, pos, \
> +		tbits, b_pos)
> +#else
> +	/* convert from big endian to little endian */ 
> +#define SQUASHFS_SWAP(value, p, pos, tbits) _SQUASHFS_SWAP(value, p, pos, \
> +		tbits, 64 - tbits - b_pos)
> +#endif
> +
> +#define _SQUASHFS_SWAP(value, p, pos, tbits, SHIFT) {\
> +	int bits;\
> +	int b_pos = pos % 8;\
> +	unsigned long long val = 0;\
> +	unsigned char *s = (unsigned char *)p + (pos / 8);\
> +	unsigned char *d = ((unsigned char *) &val) + 7;\
> +	for(bits = 0; bits < (tbits + b_pos); bits += 8) \
> +		*d-- = *s++;\
> +	value = (val >> (SHIFT))/* & ((1 << tbits) - 1)*/;\
> +}

Can the standard leXX_to_cpu() helpers not be used here?

> +#include <linux/squashfs_fs.h>
> +
> +typedef struct {
> +	unsigned int	block;
> +	int		length;
> +	unsigned int	next_index;
> +	char		*data;
> +	} squashfs_cache;

Whitespace inconsistency (column 1 for the closing brace is standard)

--- linux-2.6.11.3/init/do_mounts_rd.c	2005-03-13 06:44:30.000000000 +0000
+++ linux-2.6.11.3-squashfs/init/do_mounts_rd.c	2005-03-14 00:53:28.092559728 +0000

Your changelog didn't mention that squashfs interacts with the boot
process.  That's the sort of thing which is nice to tell people about.

> +SQUASHFS FILESYSTEM
> +P: Phillip Lougher
> +M: phillip@lougher.demon.co.uk
> +W: http://squashfs.sourceforge.net
> +L: squashfs-devel@lists.sourceforge.net
> +S: Maintained
> +

Lots of little comments, but I have no fundamental problems with the
patches as long as the bitfield issue is shown to be a non-issue.

Please respin the patches and unless someone else sees a showstopper I'll
merge them into -mm for further testing and review, thanks.


  reply	other threads:[~2005-03-15  1:07 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 [this message]
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
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=20050314170653.1ed105eb.akpm@osdl.org \
    --to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.