On Sat, 2008-08-16 at 04:06 +0200, Andi Kleen wrote: > Daniel Walker wrote: > > On Sat, 2008-08-16 at 00:17 +0200, Andi Kleen wrote: > >> Daniel Walker wrote: > >>> The semaphore usage in ACPI is more like completions. The ASL > >>> functions getting implemented here are signals which follow a > >>> "wait for", signaled, or reset format. > >>> > >>> This implements the ACPI signaling methods with the Linux > >>> completion API, instead of using semaphores. > >> NACK. I don't see the point of emulating semaphores when > >> there are already perfectly fine semaphores available. > > > > > > With semaphores as a super set, under that you have mutexes and > > completions, and other un-classified usages.. Mutex usage is obviously > > for mutual exclusion (semaphore initialized to 1), completions are used > > for signaling (semaphore initialized to 0). > > Let's put it differently: I just don't see how your change improves > the code. Replacing one locking primitive with another has no value > in itself that I can see unless it fixes something. > > And when there is the choice I think it's cleaner and less confusing to use > semaphores when the ACPICA asks for semaphores instead of something else. Semaphore are very far from the right solution to any problem. They are too broad, and they are _harder_ to understand.. They have so many usages that who knows what ACPI is really doing unless you commit to a specific sub-set of semaphores. I think ACPI "asks" for semaphores because it's multi-OS, that's not an excuse to keep using semaphores when they aren't needed. We have other API's that will satisfy ACPI which are less broad, and ultimately better. 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
