> This is one of the two ideas floating around in
> the ACPI4Linux project. I'm calling this one the
> "thin ACPI driver" model. The alternate idea
> basically integrates the AML interpreter directly
> into the kernel which adds quite a bit of size
> to the kernel (guessing maybe 300k+, ouch)
I think there is still need for discussion here (Obviously, I favor the
idea with the VM in the kernel...).
I think that the "thin driver" model has some important drawbacks:
ACPI does device enumeration, and although current systems do not require
that for booting, doing the enumeration after booting (when the daemon is
running) means shutting down all affected subsystems (IDE, USB, PCMCIA,
...), reinitializing the hardware using the AML method the BIOS provided
for this (there is no way to circumvent this, as only this AML code knows
about the ACPI specific registers in the chipset) and then restart the
drivers. Also, even if we do this, we still have to go to a solid VM when
hardware is available that relies on ACPI enum.
The second big drawback is that not only sleeping but also proper waking
depends on a userspace program, which needs to take precautions not to get
swapped out because it needs to work even when only the CPU and memory are
powered. You can easily shoot yourself in the foot with that. :-)
The third thing that disturbs me is that a userspace program tells the
kernel where to peek and poke. This program can easily be replaced by
someone breaking in from the network, while this is harder to do for the
kernel. Also, you cannot easily determine what accesses are legal because
the driver needs to be able to access all hardware. By a skilled attacker,
this can be used to circumvent the file system and low level harddisk
drivers, or to read or write arbitrary memory. Short, a huge security
hole.
This is why I favor the static solution, even if it bloats the kernel and
is hard to debug.
> > Also please consider a good generic power management
> > interface underneath ACPI. Non-ACPI devices[1] can
> > use this interface to achieve the same things.
If a device complies to the ACPI hardware requirements, the easiest way to
support it is to add own AML code for that device. If it does not, it is
perhaps possible to kludge some AML code as well, but the best idea is not
to touch that device. Handling non-compliant power management devices adds
too much complexity, I fear.
> I definitely need to start putting together a good
> device power management interface to implement
> ACPI D-states. Something like (to the driver)
> "going into D2, save your device state".
We are too few people to do everything at the same time. This is why I've
frozen the userland code.
> Support for broken or non-ACPI devices will
> certainly be kept in mind. Of course, the
> ACPI4Linux project needs to get a bit further
> along before that's even an issue.
Implementing non-ACPI devices will be a PITA. I want compliant devices to
work first, so that we have some working code to go back to if support for
noncompliant devices starts to get messy.
Simon
PGP public key available from ftp://phobos.fs.tum.de/pub/pgp/geier.asc
Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E C1
-
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/