Messages in this thread | | | Date | Mon, 13 Jan 2003 15:06:32 +0530 | From | Dipankar Sarma <> | Subject | Re: 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.
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/
| |