[lkml]   [2003]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Fixing the tty layer was Re: any chance of 2.6.0-test*?
On Mon, Jan 13, 2003 at 09:15:26AM +0000, Russell King wrote:
> > 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.

Yes, I get it now from this and Andi's mail. I hadn't thought about
that "special feature" of BKL :)

> 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.

Hmm.. This understanding would make it easier for me to go take another look
at the tty layer.

> 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.

BKL confused me here because I wasn't sure whether BKL was implicitly
protecting the tty driver code against anything else apart from itself.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.046 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site