Messages in this thread | | | Date | Tue, 11 Jul 2006 20:00:55 -0400 | From | "Jon Smirl" <> | Subject | Re: tty's use of file_list_lock and file_move |
| |
On 7/11/06, Paul Fulghum <paulkf@microgate.com> wrote: > Alan Cox wrote: > > Ar Maw, 2006-07-11 am 18:08 -0400, ysgrifennodd Jon Smirl: > > > >>What about adjusting things so the BKL isn't required? I tried > >>completely removing it and died in release_dev. tty_mutex is already > >>locks a lot of stuff, maybe it can be adjusted to allow removal of the > >>BKL. > > > > > > Thats what is happening currently. However it is being done piece by > > piece, slowly and carefully. > > I hate to chime in since I don't have time in the near term > to contribute to the subject, but I do like the idea of removing > the BKL dependence as a first step. I find its semantics akward to keep > track of, and error prone. More explicit locking, even global, would clear things > up for a later push to finer grained (per tty?) locking (where appropriate). > > Making the necessary changes to all the individual drivers, > as Russel's comment about explicitly dropping the new lock when > sleeping pointed out, would be a time consuming (and probably > tedious) task.
I'm still looking at doing work in the tty layer but it is turning out to be more complex that I initially thought. I may give removing the BLK another attempt when I understand things better.
I have all of the lock debugging turned on in my kernel. I did get nice messages when I did dumb things like sleeping with locks held or deadlocking that led to quickly fixing the code. Much better than the old system of freezing the box up.
-- Jon Smirl jonsmirl@gmail.com - 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/
| |