> 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/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:14 EST