Re: [RFC] annotating the remaining BKL users

[Arnd Bergmann <arnd@arndb.de>]

On Thursday 09 September 2010, Linus Torvalds wrote:
> On Wed, Sep 8, 2010 at 1:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > I'd like to hear preferences for one approach or the other,
> > especially from Linus, so we can give this some better testing
> > in -next before the merge window.
> 
> Hmm. I like your patch. It seems to have a good balance of "select
> BKL" (for architectures that require it for some reason) and "depends
> on BKL" (for individual modules).

Actually, I was using "select" only for the cases where there is no
other option, like architectures that unconditionally reuire it.

> That said, I'd also like to see a comment _why_ the architectures in
> question depends on the BKL. Some of those look pretty historical (the
> sparc32 register window spill code? Does it _really_ need the BKL at
> all, or is that just a remnant of "let's get the BKL at each kernel
> entry").

Right. I'm pretty sure we can trivially fix all the arch code, I just
had no incentive to start that yet and instead did the annotations.
 
> So with the added rule that "each select BKL needs a quick comment
> why", I'd be happy with it. And maybe it would make people take a
> second look.

Ok. Making people take a look was also a reason why I posted this patch
separately. I might actually add comments to all of the "depends on BKL"
as well to make it clear which category they all fall into and motivate
janitors to take care of the easy ones.

As mentioned in another thread, the only nontrivial ones besides
fs/{locks.c,lockd} (which we need to fix before the BKL can become
optional) are probably:

drivers/{media,staging,usb/gadget,char/raw}
fs/{autofs,coda,hpfs,isofs,ncpfs,nfs,smbfs,udf,ufs}
net/{appletalk,ipx,irda,ax25}

	Arnd