lkml.org 
[lkml]   [2001]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectACPI fundamental locking problems
I used to be pretty excited about ACPI, until today.

I was reading through the ACPI spec, to see what was required to obtain
the IRQ routing table from AML. Continued reading... until I hit a
section talking about the ACPI global lock.

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.

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.

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'll see what 2.5 will bring...

</soapbox>

--
Jeff Garzik | "I respect faith, but doubt is
Building 1024 | what gives you an education."
MandrakeSoft | -- Wilson Mizner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:56    [W:0.046 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site