We added the spinlock support for the GPE data structures for this reason, that the GPE data needed to be locked at interrupt level. If it's correct to do this with the hardware lock, then we should do this as well -- then cleanup the Linux OSL semaphore implementation, starting with the check for interrupt level. > -----Original Message----- > From: Brown, Len > Sent: Thursday, June 01, 2006 3:15 PM > To: Moore, Robert > Cc: 'linux-acpi@xxxxxxxxxxxxxxx' > Subject: RE: ACPI locking > > Bob, > I agree that mutex vs semaphore is an optimization. > > However (mutex or semaphore) vs spinlock is about correctness. > > 1. Linux needs to know if the lock being requested by ACPICA > can be accessed at interrupt time. > 2. Linux needs to know if ACPICA might sleep when holding the lock. > > I agree about making osl.c go away. > We've succeeded in doing this with the kmalloc() > interface, and I'm hopeful we can do so with the > locking interface also. But to #define a request > in ACPICA to multiple types of native requests, > ACPICA must internally differentiate between the > different types of locks that it needs. > > I'm talking about spinlock vs. mutex vs. semaphore here. > The global lock and the routine to handle ASL Acquire() > are special cases. > > -Len - 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
