Andi Kleen wrote:
quoted text > Here's a proposal for some useful code transformations the kernel janitors
> could do as opposed to running checkpatch.pl.
>
> Most ioctl handlers still running implicitely under the big kernel
> lock (BKL). But long term Linux is trying to get away from that. There is=
a
quoted text > new ->unlocked_ioctl entry point that allows ioctls without BKL, but the
> code needs to be explicitely converted to use this.
>
> The first step of getting rid of the BKL is typically to make it visible
> in the source. Once it is visible people will have incentive to eliminate
> it. That is how the BKL conversion project for Linux long ago started too.
> On 2.0 all system calls were still implicitely BKL and in 2.1 the
> lock/unlock_kernel()s were moved into the various syscall functions and
> then step by step eliminated.
Can you explain the rationale behind that running on the BKL? What type of=
=20
things needs to be protected so that this huge hammer is needed? What would=
=20
be an earlier point to release the BKL?
Greetings,
Eike
