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.
Thanks
Dipankar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:44 EST