> From: Jeff Garzik [mailto:[EMAIL PROTECTED]]
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
