Messages in this thread | | | Date | Sun, 19 Sep 1999 06:25:49 +0200 (CEST) | From | Simon Richter <> | Subject | Re: [PATCH] generic ACPI support |
| |
On Thu, 16 Sep 1999, Andy Henroid wrote:
> 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/
| |