![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 12:32 [W:0.095 / U:0.320 seconds] ©2003-2008 Jasper Spaans | |||||||||||||