lkml.org 
[lkml]   [2009]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] vfs: umount_begin BKL pushdown v2
On Fri, Apr 24, 2009 at 01:50:25PM -0400, Christoph Hellwig wrote:

> Having a working tree for debugging stuff is fine, but the point is
> that it should never be pulled into mainline and probably frequently
> reabsed to avoid cruft. In that case there's really no point in
> creating branches to share pieces of tree history, just apply the patch
> locally if you think you want it and merge or rebase once mainline gets
> the patch.
>
> Al frequently rebases the vfs tree, btw - so even if it was a separate
> branch now there's a fair chance it would end up in mainline with a
> different commit id.

Nah, it's not that. I can hold that in a separate branch and keep it
anchored. The question is, what else will end up there?
* the work inside the methods on BKL _removal_
* things like merging that ->write_super() call into ->put_super(),
etc.
* probably parts of work on s_flags mess and ro (tied to remout)

I agree that getting rid of BKL in that area is a good thing; no arguments
about that. If it had been entirely self-contained, I'd gladly drop that
stuff into a separate branch, let mingo pull it and forgot about the entire
thing.

The things get tricky, though, since we have two more things in the same
area: remount (once Nick comes back with the latest on mnt_write_count,
I'm going to merge that and start on per-sb side, BTW) and stuff around
Jan's sync series.

So let's figure out how do we do that. I have no problem with a single
branch for *all* of that, separate from the rest of VFS stuff. However,
I very much suspect that it's not what mingo et.al. have in mind - too
much stuff alien for them. I can keep a cherry-picked branch with minimal
BKL-affecting backports from that one. It might or might not be OK,
depending on what the hell their workflow is in -tip. I honestly have
no idea how the devil the things are done there, except that it apparently
involves much more merges than I'd be comfortable with, but then I never
had a taste for literal clusterf*cks either.

Could the folks from the other side tell
* what kind of patches do they want in that branch
* what kind of patches can they accept in that branch
* when do they intend to see it merged into mainline
* how much is going to be merged on top of that and how often
(if ever) is it going to be thrown out and re-pulled. I.e. is that for
a devel/debugging tree pulled together from many topic branches on
regular basis, with branches dropped/re-added/etc. (i.e. something a-la
linux-next) or is that something more cast in stone?

Seriously, let's sort that out; flamefests being what they are, there's
a real problem with keeping two streams of development tolerable for
participants. I *do* have very unkind words to say to Ingo, but that's
a matter for private mail and I'm not going to let that anywhere near
development question.


\
 
 \ /
  Last update: 2009-04-24 20:59    [from the cache]
©2003-2011 Jasper Spaans