Re: BKL removal

[Dave Hansen]

Drew P. Vogel wrote:
>>   If nothing else, I hope you will think twice before sending off
>>   your next BKL removel patch in a subsystem that you haven't fully
>>   tested or understood.  That's the point I keep trying to get across
>>   here.
>>
>>So can you define for me under what conditions the BKL is appropriate
>>to use?  Removing it from legitimate uses would be bad, of course, but
>>part of the problem here is that it's currently used for a variety of
>>unrelated purposes.
> 
> If the trade-offs weigh in about the same, removing the BKL from
> legitimate uses in favor of a different (neither better nor worse)
> approach would be more than acceptable, would it not?

I think Greg's main protests are about the methods, not the means.

> Would creating a few new names for lock_kernel() and friends be
> acceptable? Just a few macros to give slightly more meaningful names to
> each function call for 2.5. Then take lock_kernel() entirely away (the
> name, not the function), in 2.7. By 2.9 it should be able to be removed
> from nearly all "inappropriate" uses. This seems like it would encourage
> more  explicit usage of the BKL, while giving maintainers ample time to
> comply.

I would really prefer not to see the name changed.  In some places 
people do this:

#define mydriver_lock() lock_kernel();
#define mydriver_unlock() unlock_kernel();

All that this really does is obscure the BKL's use -- it makes it 1 
step harder to track down.  If you need a spinlock, use a spinlock. 
If you need the BKL, by all means, take the BKL.

A comment is immeasurable better than a different name.  I would say, 
if you need/want the BKL, justify it with a comment, not a name.

> Note that I have never added or removed a lock from the kernel. I am
> simply thinking aloud; half hoping to be corrected.

I know the feeling :)

-- 
Dave Hansen
[e-mail]