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.
next prev parent 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