![]() | |||||||||||||
Messages in this thread |
On Thu, 2006-09-14 at 15:11 -0400, Dmitry Torokhov wrote: > On 9/14/06, Arjan van de Ven <arjan@infradead.org> wrote: > > > > > > > > I think it is - as far as I understand the reason for not tracking > > > every lock individually is just that it is too expensive to do by > > > default. > > > > that is not correct. While it certainly plays a role, > > the other reason is that you can find out "class" level locking rules > > (such as inode->i_mutex comes before <other lock>) for all inodes at a > > time; eg no need to see every inode do this before you can find the > > deadlock. > > > > OK, I can see that. However you must agree that for certain locks we > do want to track them individually, right? I agree that if locks really represent different objects with different locking semantics they should not share the class. Lockdep provides a mechanism for that; however I'm very afraid that for the input layer, they really are not that, they are not different objects with different semantics; they are the same objects with nesting semantics! In that case the "separate lock class" stuff has only disadvantages. The worst thing is that as I understand it this separate class is *dynamic*. Eg it's not even "one class per driver" ;( - 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: 2006-09-15 07:37 [from the cache] ©2003-2008 | |||||||||||||