In order for any OS to work correctly (provide all the benefit of OSPM/ACPI
using acpi define interfaces), OSPM must be resident very early and very
late. OSPM is a term we use to describe all software that touches ACPI
define interfaces whether they be configuration or power management.
1. The AML interpreter (AMLI) is required in a number of cases. It is needed
to get interrupt routing so it must be around very early or the loader must
be able to get this info.
2. AMLI is required to parse the names space to perform motherboard device
initialization and configuration including all PCI root bridges, keyboard,
mouse, embedded controllers etc.. Some systems will need GPEs to enumerate
and so that support must be available during config time.
3. In general OSPM requires access address spaces like memory, PCI, PCI
config, the SCI interrupt, and ACPI defined "fixed" hardware.
4. To transition into the sleeping state, the system should shut down all
applications then run a control method or two and then hit the sleep type
and sleep enable registers. This can become tricky if OSPM itself is an
application. Upon wake, OSPM must perform configuration and power mgt tasks
before applications are re-enabled (awoken).
It is for these reasons and others that every OS that has implemented or is
implementing OSPM/ACPI has put the support in the OS kernel. While Linux of
course is not every OS, there is merit to the choice.
Guy
P.S. The AMLI itself is currently around 70K code and data and has been
shrinking overtime as it has been optimized.
-----Original Message-----
From: Jeff Garzik [mailto:jgarzik@mandrakesoft.com]
Sent: Sunday, April 30, 2000 10:08 AM
To: Simon Richter
Cc: Cesar Eduardo Barros; linux-kernel@vger.rutgers.edu;
acpi@phobos.fachschaften.tu-muenchen.de
Subject: [Acpi] Re: [RFC] Getting rid of useless daemons
Simon Richter wrote:
>
> On Sat, 29 Apr 2000, Cesar Eduardo Barros wrote:
>
> > acpid (as far as I know at least) is like apmd but also parses the
> > ACPI tables (easy to do within a boot script, at the same spot acpid
> > would be loaded).
>
> acpid does more than table parsing, so it cannot be easily replaced by a
> "boot script". Most of its functionality (table parsing, AML code
> execution) will move into the kernel later on, as future systems will
> depend on that for hardware enumeration, but for now having a separate
> daemon eases development.
After having re-read the ACPI spec a few days ago, I agree that more
ACPI stuff is gonna wind up in the kernel. We don't want to have to
bounce back to userspace just to parse tables which tell us key things
like APIC or CPU info.
(fwiw here is a kernel traffic reference for ACPI:
http://kt.linuxcare.com/kernel-traffic/kt19991004_37.epl#1 )
Parsing tables is way different from parsing AML. Why does there need
to be an AML parser in the kernel? It seems like Andy adequate
responded to your list of drawbacks at the above link, so I hope you
mind my request for a clarification of the issue.
Thanks,
Jeff
-- Jeff Garzik | Nothing cures insomnia like the Building 1024 | realization that it's time to get up. MandrakeSoft, Inc. | -- random fortune_______________________________________________ acpi maillist - acpi@phobos.fachschaften.tu-muenchen.de http://phobos.fachschaften.tu-muenchen.de/mailman/listinfo/acpi
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:08 EST