RE: ACPI fundamental locking problems

[Grover, Andrew]

> From: Jeff Garzik [mailto:[e-mail]]
> events/evxface.c:610:acpi_acquire_global_lock ->
> events/evmisc.c:337:acpi_ev_acquire_global_lock ->
> include/platform/acgcc.h:52:ACPI_ACQUIRE_GLOBAL_LOCK
> 
> My immediate objections are,
> (a) acgcc.h is re-implementing spinlocks in a non-standard,
> non-portable, and expensive way, and (b) this entire code path is
> incredibly expensive.

Well, when I look at other Linux code, I assume that if it does something
weird, it does it for a reason.

That is the case here. The Global Lock is for synchronizing accesses between
the OS (that's us) and the firmware (SMI). Normal spinlocks are for intra-OS
locking. Here, we're synchronizing access with the BIOS. It's different.

All this code has been working for as long as I can remember.

You mention twice that it is "expensive". Keeping in mind the 80-20 rule, in
what way do you find this code costly?

> But my fundamental objection is,
> we are depending on vendors to get locking right in their 
> ACPI tables. 
> And assume by some magic or design that said locking works 
> with whatever
> unrelated kernel locking is going on.

By design, it works. We get to slipstream Windows a little here in that
vendors need to have a working Global Lock interface to pass WHQL.

> It is my initial belief that a smaller info query interface that can
> parse useful ACPI would be more effective.  For times like
> suspend/resume where we would want to execute control methods, well,
> there's always the disasm -> write-small-driver cycle.  Who knows if
> this is a realistics proposed solution.  But it really scares me to
> depend on vendors to get locking right.

We're depending on vendors (aka the BIOS) for all the ACPI tables, as well
as every other piece of a priori data we need to boot the OS.

Could I please ask that you at least show me a system where this is a
problem before throwing out all the work we've done on ACPI because of this
technical nit?

Thanks -- Regards -- Andy