Re: BKL removal

[Larry McVoy]

> The problem is, of course, that to responsibly use the BKL, you must
> fully understand ALL the code that utilizes it, so that you know your
> new use of it doesn't conflict or interfere with existing code and
> usage.  

Indeed.

       v
> With a narrowly defined and used lock, it is much less difficult to
       ^

If you were talking about replacing a big lock with one lock, you
might have a point.  But you aren't.  You can't be, because by
definition if you take out the big lock you have to put in lots
of little locks.  And then you get discover all the problems that
the BKL was hiding that you just exposed by removing it.

If you think that managing those is easier than managing the BKL,
you don't understand the first thing about threading.

I think the kernel crowd is starting to sense how complex things
are getting and are pushing back a bit.  Don't fight them, this
isn't IRIX/Dynix/PTX/AIX/Solaris.  It's Linux and part of the
appeal, part of the reason you are here, is that it is (was) simple.
All you are doing is suggesting that it should be more complex.
I don't agree at all.

> So can you define for me under what conditions the BKL is appropriate
> to use?  

Can you tell me for sure that there are no races introduced by your
proposed change?

Can you tell me the list of locks and what they cover in the last 
multi threaded OS you worked in?  I thought not.  Nobody could.