On Saturday 24 April 2010 22:01:18 Linus Torvalds wrote:
With CONFIG_BKL disabled, we gain a few cyles in the scheduler,
since we no longer need to check if the BKL was held and needs to
be released. Not much, but better than just a few bytes of object size.
With CONFIG_BKL=m, what we gain is visibility: Doing an lsmod will
show you if bkl.ko is loaded and what other modules are using it.
My hope is that this will motivate people to remove it from the
remaining modules.
One of the crazier ideas was to automatically taint the kernel when
bkl.ko gets loaded. This does not gain us anything besides making a
statement.
Being able to grep is not the reason for this patch. The reason is that
we're trying to eliminate the BKL from all non-obscure code in the kernel
and one of the nasty ones is fs/ioctl.c, which always gets compiled in.
The trick with bkl.ko requires that any code calling lock_kernel() needs
to be a module, so the deprecated_ioctl() helper will have to be part
of bkl.ko as well.
Ok. We'll go back to my intial approach for ioctl then, doing it all at
once. The reason for the staged approach was to avoid bisect breakage
and conflicts with maintainer updates, but since most of the remaining
users at this point are really unmaintained (or staging drivers), there's
probably not much to worry about here.
There will be one patch that does three things:
- add a deprecated_ioctl() function
- rename fops->ioctl to fops->bkl_ioctl
- set fops->unlocked_ioctl=deprecated_ioctl for any file_operations instance
that uses bkl_ioctl
Is this ok for you?
Regarding the CONFIG_BKL option, should that also be done as another patch
changing all the Kconfig files? My preference would be to have one patch
adding the Kconfig option first, giving the maintainers the choice to either
mark their code 'depends on BKL' or to remove the dependency by changing
their code.
Arnd
--
