On Thu, 10 Aug 2006 09:41:59 -0700 Mingming Cao <cmm@xxxxxxxxxx> wrote: > Andrew Morton wrote: > > > On Wed, 09 Aug 2006 18:17:02 -0700 > > Mingming Cao <cmm@xxxxxxxxxx> wrote: > > > > > >>Fork(copy) ext4 filesystem from ext3 filesystem. Rename all functions in ext4 from ext3_xxx() to ext4_xxx(). > > > > > > It would have been nice to spend a few hours cleaning up ext3 and JBD > > before doing this. The code isn't toooo bad, but there are number of > > coding style problems, whitespace screwups, incorrect comments, missing > > comments, poorly-chosen variable names and all of that sort of thing. > > > > One the fs has been copied-and-pasted, it's much harder to address these > > things: either need to do it twice, or allow the filesystems to diverge, or > > not do it. > > > Andrew, thanks for taking a close look this series of changes. > > I agree with you that the timing is right, to do the clean up now rather > than later. I would give it a try. If I could get more help from more > code reviewer, it probably makes the effort a lot easier. For those > issues you pointed out : coding style problem___incorrect comments, > poorly-named variables -- do you have any specific examples in your mind? Not really, apart from the few things I identified elsewhere (such as the brelse thing). It's just that now is the right time for a general spring-cleaning, if we ever want to do that. > > Also, -mm presently has two patches pending against fs/jbd/ and nine pending > > against fs/ext3/. We should get all those things merged before taking the > > copy. > > > So probably the right thing to do is keep the ext4 patches against mm > tree instead of rc three? That would drive everyone nuts, I think. What I would suggest is: - get ext3 into a ready-to-copy state (merge bugfixes, spring-clean, etc) - do the big copy-n-rename operation in Linus's tree. - run a quilt or git tree against the resulting Linus tree. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
