Messages in this thread | | | Date | Mon, 8 Jul 2002 22:21:27 -0700 | From | Larry McVoy <> | Subject | Re: BKL removal |
| |
> 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. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |