I don't think it can be fully automated. For the majority of the modules,
your approach would work fine, but there are still the well-known
pitfalls in corner cases:
- recursive uses in functions outside of ioctl (possibly none left
after the TTY layer is done, but who knows)
- lock-order problems with other mutexes (see DRM)
- code that depends on autorelease to allow one ioctl while another
is sleeping. (a small number of drivers)
Semi-automated should be fine though. These rules are relatively
easy to check, so we can mass-convert all the trivial cases.
Examples for nontrivial modules are mostly file systems, see ncpfs,
afs, hpfs, ...
I think the immediate goal should be to get the BKL out of everthing
that's either used by real people or that's reasonably easy to do.
We have patches for almost all of these now [1], and I've been running
a kernel with CONFIG_BKL=n for a few weeks now. As we progress
through the remaining modules, an increasing number of systems can
run without this.
I see the next steps as:
1. make it possible to build a kernel without BKL, by removing the BKL
from all core components for good, and making all users depend on
CONFIG_BKL. Make it default y and put it under CONFIG_DEBUG.
2. Remove the BKL from all modules that are either easy to convert
to a private mutex or that are relevant to real users (e.g.
definitely DRM, but maybe not hpfs).
3. Change CONFIG_BKL to "default n, depends on DEPRECATED"
4. Remove the remaining modules that nobody knows how to fix
or cares about. Possibly the number of modules here is close
to zero.
5. Remove the implementation of the BKL, since no users are left.
Getting stage 1 done for 2.6.36 or even 2.6.35 should be possible but
still needs a lot of work. I think we should focus on that for now
and then see how much is left to do for the other stages.
This is still a temporary transition, but since we can't do all at
once, I don't see better way.
Arnd
[1] http://kernelnewbies.org/BigKernelLock
--
