On Mon, 2008-07-21 at 22:00 +0200, Andi Kleen wrote: > Now if mutexes were possible (AFAIK that's not possible in the general > case) then that would work too. But using "completions" as the low > level API doesn't make sense to me because it'll just lead to higher > level locking code being reinvented and also because it's unlikely > anything else has those with these semantics. The completions should only be used by the interpreter to implement the ASL style signals which fit completions really well (that was my goal anyway).. > I think what would make sense is to identify the locks in ACPICA > which only have mutex semantics and convert them to a new osl mutex > abstraction. Then at least some of the locks could get lockdep > checking. To an extent that's already done .. There is a osl mutex abstraction which just uses semaphores. I switched that over to use a mutex .. Those areas that already used the osl mutex abstraction should now be using the actual linux mutex. > On the other hand to be honest I'm not looking forward to handle > the usual 90+% false positives that you get out of lockdep ... > > > Clearly this all wasn't extremely clear from the code - otherwise Daniel > > wouldn't even have done these patches. > > > >> Especially now that semaphores are not duplicated per architecture > >> anymore so actually keeping them around is not that costly. > > > > Having them around might give people the idea its a good idea to use > > them. Not having them around is a good way to discourage that. I agree with Peter here.. I've seen a lot of bad locking, and I think we really need explicit checks over just code review. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
