Date:	Fri, 24 Apr 2009 19:55:24 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Fr?d?ric Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Alessio Igor Bogani <abogani@...ware.it>,
	Jonathan Corbet <corbet@....net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML <linux-kernel@...r.kernel.org>,
	LFSDEV <linux-fsdevel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Matthew Wilcox <matthew@....cx>
Subject: Re: [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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists