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
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 email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/