> Suppose the BKL has just become optional. As a *user*, suppose I do not use *any* module or code using the BKL.
> Would it make any difference to me to run a BKL-free kernel compared to a stock kernel compiled with most features,
> including an unused BKL?
Not much. The task_struct can shrink by four bytes and the schedule() function loses a few bytes for calling release_kernel_lock()/reaquire_kernel_lock().
The -rt kernel tree wins a bit more because it does not have to work around the BKL being weird any more.
If we get distros to disable the BKL while it's still there, that will help annoy certain companies providing binary-only kernel modules, but if you're building your own kernels and don't use those modules, it won't make a difference.
I originally thought we'd have a lot more legacy modules that are not worth fixing and need to be disabled, but now the config option is not so important any more.
> In such cases isn't it better to just let this suboptimal but tested and working code depend forever on an optional BKL?
> The few remaining users of such old code might still enjoy it without having the resources to free it from the BKL.
The only remaining modules that nobody has volunteered to fix are now only i810/i830 (drm), and a few file systems (adfs, coda, freevxfs, hpfs, smbfs and ufs). I guess we can either declare them BROKEN_ON_SMP or remove them if nobody steps up to fix them by the end of the following (2.6.38) merge window.