From: Valerie Aurora <vaurora@redhat.com>
To: Theodore Tso <tytso@mit.edu>, Julia Lawall <julia@diku.dk>
Cc: linux-ext4@vger.kernel.org, Eric Sandeen <sandeen@redhat.com>,
Ric Wheeler <rwheeler@redhat.com>
Subject: Re: spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?)
Date: Mon, 3 Aug 2009 18:56:24 -0400 [thread overview]
Message-ID: <20090803225624.GC9324@shell> (raw)
In-Reply-To: <20090803202740.GE10853@shell>
On Mon, Aug 03, 2009 at 04:27:40PM -0400, Valerie Aurora wrote:
> On Sat, Aug 01, 2009 at 10:22:09PM -0400, Theodore Tso wrote:
> >
> > I also would greatly prefer it if people who submit patches to me obey
> > basic patch and code formatting guidelines. Things like this are
> > really uncool:
> >
> > - fs->group_desc[i].bg_free_blocks_count =
> > - free_array[i];
> > + ext2fs_bg_free_blocks_count_set(fs, i, free_array[i])
> > + ;
>
> Ah, that's left over from an spatch bug that Julia Lawall (cc'd)
> kindly fixed immediately after I reported it. It won't happen if you
> use the current spatch. My apologies for missing this one during
> review!
>
> I think spatch could probably also wrap lines automatically when
> making semantic patches - Julia?
>
> I'm curious what you think of this proposal: Redo all the foo() ->
> foo2() patches in the entire 64-bit series as a semantic patches.
> This would also fix this kind of cut and paste bug:
>
> + ext2fs_bg_flag_clear (fs, i, EXT2_BG_BLOCK_UNINIT);
> + ext2fs_bg_flag_clear (fs, i, EXT2_BG_INODE_UNINIT);
>
> I fixed several of these in the existing 64-bit code when I took it
> over, so I assume more lurk undiscovered and would be revealed if we
> redid them with spatch.
>
> Julia, would you and/or your students be interested in helping? I
> think you're running out of bugs in the kernel and e2fsprogs would be
> another excellent showcase for spatch/Coccinelle. :)
I just remembered another reason to convert to spatch: For various
reasons, I ignored several parts of e2fsprogs while doing the 64-bit
conversion. Some of those should remain unconverted (dead code or
32-bit only code) but others should be converted. For example, I
found some unconverted block group descriptor references in resize2fs
last week - I remember having some reason for doing it at the time but
I don't recall what it was now since it's been a few months. Sorry!
-VAL
next prev parent reply other threads:[~2009-08-03 22:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-30 21:53 Fix device too big bug in mainline? Valerie Aurora
2009-08-02 0:28 ` Theodore Tso
2009-08-02 2:22 ` Theodore Tso
2009-08-02 3:49 ` Theodore Tso
2009-08-03 20:11 ` Valerie Aurora
2009-08-03 20:27 ` spatch for 64-bit e2fsprogs (was Re: Fix device too big bug in mainline?) Valerie Aurora
2009-08-03 22:56 ` Valerie Aurora [this message]
2009-08-04 6:40 ` Julia Lawall
2009-08-04 14:48 ` Theodore Tso
2009-08-04 18:18 ` Valerie Aurora
2009-08-04 19:24 ` Andreas Dilger
2009-08-04 19:58 ` Valerie Aurora
2009-08-04 20:32 ` Theodore Tso
2009-08-04 18:28 ` Fix device too big bug in mainline? Valerie Aurora
2009-08-04 20:41 ` Theodore Tso
2009-08-04 21:29 ` Valerie Aurora
2009-08-04 22:12 ` Theodore Tso
2009-08-04 23:56 ` Theodore Tso
2009-08-03 18:04 ` Valerie Aurora
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=20090803225624.GC9324@shell \
--to=vaurora@redhat.com \
--cc=julia@diku.dk \
--cc=linux-ext4@vger.kernel.org \
--cc=rwheeler@redhat.com \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
/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.