Re: Fixing the tty layer was Re: any chance of 2.6.0-test*?

[Russell King]

On Mon, Jan 13, 2003 at 01:42:33PM +0530, Dipankar Sarma wrote:
> > The idea of the BKL was to protect the protect context code against
> > itself (code lock) and also the few global data structures that 
> > are only accessed from process context (like the tty drivers list)
> 
> In that case would it not be better to replace all BKLs by a single tty
> lock ?

No.  The tty layer relies on being able to safely reschedule with the
BKL held.  If you replace it with a "tty lock" you need to find all
those schedule() points throughout _every_ tty line discipline and
tty driver and release that lock.

Basically, the tty later was written upon the assumption that there
would be only _one_ thread of execution running tty code at any one
time, and we only reschedule when we explicitly want to (which was
the general kernel coding rule before we got spinlocks etc.)  Every
point where a reschedule is possible, state checks are (should be)
made to prevent races.

When analysing the tty layer, you have to think not "what data does
this protect" but "what code are we protecting".  Note that you must
apply the same approach towards what were the global-cli points.

I don't think its the BKL points you have to worry about; they've
stayed the same over many kernel versions.  The places that need
deeper consideration are where the global-cli was replaced with the
local-cli.  Obviously the latter is not a direct subsitute for the
former.

-- 
Russell King ([e-mail])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html