Re: New ACPI power resource code for testing

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

Without understanding ACPI at all...

>> After thinking this and reading the intriguing discussions around the new
>> modularized world order, why this is a problem? In another words, the
>> "sibling dependency" you mentioned could perhaps be understood so that a
>> consumer (acpitz, etc.) depends on a producer (power resources).
>
> 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.

Is it possible to call functions via function pointers put in the common
parent (acpi.c)?  acpi_power implements the "power" interface in the acpi
driver.  acpi_power_attach() just needs to assign the parent's pointer (to
array of power ops) with its implementation.

Personally I want to keep device tree structure to reflect its physical
representation naturally.  It'd be nice if acpi drivers follow an intuitive
rule which helps people *guess* ACPI's internal by its topology.

Masao

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635