On 7/11/06, Paul Fulghum <[email protected]> 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
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
