Re: [PATCH 1/1] vfs: umount_begin BKL pushdown v2

[Ingo Molnar]

* Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:

> On Fri, Apr 24, 2009 at 11:16:18AM +0200, Fr?d?ric Weisbecker wrote:
> > I disagree with you. The kill-the-BKL tree does not only aggregate patches
> > to turn the BKL into more traditional locks. The Bkl has been
> > converted to a common mutex in
> > this tree, making it losing its common horrid properties:
> > 
> > - release/reacquire on schedule
> > - not preemptable
> > - can be reacquired recursively by a same task
> > 
> > Such a basis is very useful because we can easily find these places
> > which won't support a usual lock conversion without reworking the
> > locking scheme.
> > This is a necessary preliminary for the Bkl removal.
> > All the places which have been designed very tightly with Bkl
> > properties are rapidly detected
> > with lockdep in this tree and reworked, still using lockdep, code
> > reviewing and the help of
> > this Bkl-to-mutex conversion.
> > 
> > The work done with this tree can be merged inside and also on the
> > matching subsytem tree for
> > each patchset. That's a very sane workflow IMHO.
> 
> 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 [...]

Btw., doing that can (and will) destroy Git history and is pretty 
explicitly discouraged.

> [...] - 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.

So did i get you right, you are advocating people to rebase their 
trees because the VFS tree is rebased often? That's pretty 
backwards.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/