Re: New ACPI power resource code for testing

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

On Sun, Mar 07, 2010 at 06:28:25AM -0800, Paul Goyette wrote:
> I'm thinking more of people who want to compile their own kernels and 
> keep the memory footprint to a minimum.  They should be able to compile 
> the acpitz device without the acpipower.  The typical(?) situation would 
> be to boot up a generic kernel and examine the device tree, then create 
> a custom config file.  With the proposed acpipower, a system might not 
> have any acpipoer devices attach, but the code would still be required.
> 
> Somehow, it just seems counter-intuitive to me that device support code 
> is required for a device that is not present.  If the code is required, 
> then in my opinion it should not be represented as a configurable 
> device.

Perhaps a compromise would be to split the interface-handling code (namely
getting and setting the power state) and the device-specific code. This way
you would have the best of both worlds; you could have acpitz(4) but compile
the whole kernel without power resource code. This of course may cripple the
functionality. Either way, keeping memory footprint at minimum and
unconditionally compiling things to the kernel are kind of conflicting
goals (not that it matters with this tiny bit of code).

Actually, it would be best to move the power state etc. -flags to the acpi
device node structure. The same thing should perhaps be done to all ACPI
code (e.g. wakedevs) that deals with the device nodes but maintains local
data structures.

Nota bene: there is already a well-known implicit dependency built-in to the
whole acpi(4) subsystem; practically each and every driver already depends
on acpiec(4).

- Jukka.