From: Andrew Morton <akpm@linux-foundation.org>
To: Daniel Phillips <phillips@phunq.net>
Cc: linux-kernel@vger.kernel.org, tux3@tux3.org
Subject: Re: Tux3 report: Tux3 Git tree available
Date: Wed, 11 Mar 2009 11:42:11 -0700 [thread overview]
Message-ID: <20090311114211.89eed5b8.akpm@linux-foundation.org> (raw)
In-Reply-To: <200903110925.37614.phillips@phunq.net>
On Wed, 11 Mar 2009 09:25:37 -0700
Daniel Phillips <phillips@phunq.net> wrote:
> The full patch is 191KB. We could try patchbombing lkml with that, one
> patch per file, say.
One patch per file is OK.
Two considerations:
- It should be reviewable! People don't want to spend all their
review time scratching their heads wondering "wtf is this piece of
code supposed to do".
Thoughtfully commented data structures and functions are valuable
during the code-review stage. If you try to retrofit them later then
reviewers get justifiably grumpy about all the time they wasted
ineffectually trying to review the uncommented stuff.
- Send the code for review when it's ready for linux-next
integration. I don't think it's a good idea to have it reviewed,
then you all disappear and spend three months changing it and then
put it up for linux-next integration.
OTOH, there may well be large changes as a result of review, so
don't leave it too late and avoid the temptation to think of it as
"finished", because it won't be!
Drive-by review:
- please prefer to leave a blank line between end-of-locals and
start-of-code in each fucntion.
- C++ comments make checkpatch (and kernel developers) whine.
- The non-tux3-specific bitmap-handling functions in balloc.c
shouldn't exist, I suspect. Use core kernel helpers. If they don't
exist, add them.
- bytebits() should use hweight8()
- No new typedefs, please. That means block_t. If there is some
real need to make block_t a typedef (such as: its size varies
according to Kconfig options) then grumble, OK. But it should then
be called tux3_block_t.
- count_range() is an unsuitable identifier for a kernel-wide symbol.
Please review all global symbols in the fs, ensure that they are
prefixed with "tux3_". Or make them static, of course.
- It uses printf() and assert()? Kernel code uses printk() and
BUG_ON(). Confused.
- There's a lot of this:
int ended = 0, any = 0;
struct buffer_head *buffer = blockread(mapping(inode), block);
if (!buffer)
return -1;
unsigned bytes = blocksize - offset;
if (bytes > tail)
bytes = tail;
unsigned char *p = bufdata(buffer) + offset, *top = p + bytes;
Which will spew compilation warnings due to local variable
definitions coming after code.
Maybe this code is never to be compiled into the kernel image, but
we might as well be consistent.
- What's "L"?
printf("%Lx-", (L)begin);
- When 'bh' is known to be non-NULL, use put_bh() rather than brelse().
- Use __packed, not PACKED.
- Run `checkpatch --file', enjoy the result.
- get_buffer() looks like it's racy against truncate. Needs to lock
the page.
- eh?
typedef u64 fixed32; /* Tux3 time values */
- link_entry() looks dangerous.
- Move SB_MAGIC to magic.h, change name.
- remove private hexdump(), use lib/hexdump.c
Generally: the code is _very_ namespace-piggy. Lots and lots of very
generic-sounding identifiers.
next prev parent reply other threads:[~2009-03-11 18:44 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-11 16:25 Tux3 report: Tux3 Git tree available Daniel Phillips
2009-03-11 18:42 ` Andrew Morton [this message]
2009-03-12 5:38 ` [Tux3] " Daniel Phillips
2009-03-12 6:07 ` Andrew Morton
2009-03-12 8:33 ` Daniel Phillips
2009-03-12 8:47 ` Nick Piggin
2009-03-12 9:00 ` Daniel Phillips
2009-03-12 9:10 ` Nick Piggin
2009-03-12 10:15 ` Daniel Phillips
2009-03-12 11:03 ` Nick Piggin
2009-03-12 12:24 ` Daniel Phillips
2009-03-12 12:32 ` Matthew Wilcox
2009-03-12 12:45 ` Nick Piggin
2009-03-12 13:12 ` Daniel Phillips
2009-03-12 13:06 ` Daniel Phillips
2009-03-12 13:04 ` Nick Piggin
2009-03-12 13:59 ` Matthew Wilcox
2009-03-12 14:19 ` Nick Piggin
2009-03-15 3:24 ` Daniel Phillips
2009-03-15 3:50 ` Nick Piggin
2009-03-15 4:08 ` Daniel Phillips
2009-03-15 4:14 ` Nick Piggin
2009-03-15 2:41 ` Daniel Phillips
2009-03-15 3:45 ` Nick Piggin
2009-03-15 21:44 ` Theodore Tso
2009-03-15 22:41 ` Daniel Phillips
2009-03-16 10:32 ` Nick Piggin
2009-03-16 5:12 ` Dave Chinner
2009-03-16 6:38 ` Theodore Tso
2009-03-16 10:14 ` Nick Piggin
2009-03-12 17:06 ` Theodore Tso
2009-03-13 9:32 ` Nick Piggin
2009-03-12 17:00 ` OGAWA Hirofumi
2009-03-15 3:54 ` Daniel Phillips
2009-03-12 9:47 ` Sam Ravnborg
2009-03-12 10:25 ` Daniel Phillips
2009-03-12 15:30 ` Diego Calleja
2009-03-12 16:54 ` OGAWA Hirofumi
2009-03-15 3:36 ` Daniel Phillips
2009-03-15 4:26 ` OGAWA Hirofumi
2009-03-12 13:24 ` Andi Kleen
2009-03-12 21:24 ` [Tux3] " Daniel Phillips
2009-03-12 23:38 ` Andi Kleen
2009-03-15 3:03 ` Daniel Phillips
2009-03-12 21:02 ` Roland Dreier
2009-03-15 4:02 ` Daniel Phillips
2009-03-12 16:18 ` OGAWA Hirofumi
2009-03-12 20:02 ` Andrew Morton
2009-03-12 20:46 ` OGAWA Hirofumi
2009-03-15 3:58 ` Daniel Phillips
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=20090311114211.89eed5b8.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=phillips@phunq.net \
--cc=tux3@tux3.org \
/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