mirror of https://lore.kernel.org/lkml/
 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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome