[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200911031546.40603.arnd@arndb.de>
Date: Tue, 3 Nov 2009 15:46:40 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Christoph Hellwig <hch@...radead.org>
Cc: Jan Blunck <jblunck@...e.de>, linux-fsdevel@...r.kernel.org,
Matthew Wilcox <matthew@....cx>,
"Linux-Kernel Mailinglist" <linux-kernel@...r.kernel.org>,
Christian Borntraeger <borntraeger@...ibm.com>
Subject: Re: [PATCH 01/27] BKL: Push down BKL from do_new_mount() to the filesystems get_sb/fill_super operation
On Tuesday 03 November 2009, Christoph Hellwig wrote:
> On Tue, Nov 03, 2009 at 11:25:09AM +0100, Jan Blunck wrote:
> >
> > My plan was to remove the BKL in the obvious cases in the followup patches
> > that are also included in the series. So should I just merge the obvious stuff
> > into one patch? Christian Borntraeger was actually requesting the opposite. He
> > wants to be able to bisect it to the patch that is removing the BKL. That
> > would be much simple with many small patches I think.
>
> Yes, but for most filesystems the BKL never made sense. Anywhere where
> it's non-obvious (or the maintainer wants it) make it a separate patch,
> but don't bother for things like xfs or btrfs.
>
In order to maintain bisectability, you could first add the explicit BKL
in the file systems where it may be needed and then remove it from the
common code in the final patch, listing all file systems by category
(doesn't need BKL, holds BKL itself) that you looked at.
Shorter series, but same results because of the recursive nature of
the BKL.
Arnd <><
--
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