> > [ and on a similar notion, i still havent given up on seeing all BKL > > use gone from the kernel. I expect it to happen any decade now ;-) ]
> 2.6.21 had 476 lock_kernel() calls. 2.6.22-git has 473 lock_kernel() > calls currently. With that kind of flux we'll see the BKL gone in about > 40 years =B-) > 'struct semaphore' use on the other hand has gone down by 10% in this > release, which is a good rate. I guess the lack of lockdep coverage for > semaphores might be one of the driving forces? ;-) The problem with removing uses of the BKL is that a "lock_kernel()" gives no clue about what it is protecting against, and so it requires a lot of very difficult auditing to replace with appropriate locking. To take a couple of examples at random: fs/ext4/ioctl.c takes the BKL in ext4_compat_ioctl() around the call to ext4_ioctl(). Kind of sad that a "next-generation" FS still uses the BKL, but who understands things well enough to say how all the cases in ext4_ioctl() are relying on being called with the BKL held? As a second example, msr_seek() in arch/i386/kernel/msr.c... is the inode semaphore enough or not? Who understands the implications well enough to say? Most semaphores on the other hand can be replaced by mutexes or completions in a fairly straightforward way. - R. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
