lkml.org 
[lkml]   [2001]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: ACPI fundamental locking problems
Date
> From: Jeff Garzik [mailto:jgarzik@mandrakesoft.com]
> 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 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.073 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site