Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 13 Jan 2003 09:15:26 +0000 | From | Russell King <> | Subject | Re: Fixing the tty layer was Re: any chance of 2.6.0-test*? |
| |
On Mon, Jan 13, 2003 at 01:42:33PM +0530, Dipankar Sarma wrote: > > The idea of the BKL was to protect the protect context code against > > itself (code lock) and also the few global data structures that > > are only accessed from process context (like the tty drivers list) > > 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.
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.
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.
-- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html
- 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/
| ![\](/images/icornerr.gif) |