Re: New ACPI power resource code for testing

[Paul Goyette <paul%whooppee.com@localhost>]

On Sun, 7 Mar 2010, Jukka Ruohonen wrote:

> > > > dependency with acpitz.  Is it conceivable that an acpitz can be fully
> > > > functional without needing the acpipower device?  (I'm thinking of
> > > > passive-only situations.)  If so, then the dependency should be removed.
> > >
> > > Yes, it is possible, even likely. Perhaps some autoconfiguration glue would
> > > help here?
> >
> > Well, since there isn't any way for our configuration tree to indicate
> > "sibling dependency", I would suggest moving the power stuff back into
> > the generic acpi framework rather than making it a separate device?
>
> 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.


> As for ACPI generally, one could even play with an idea of providing
> "pseudo" or "fake" HIDs (PNPxxxxs) for every component and then running them
> all through autoconfiguration or a related procedure. Note that acpitz(4) is
> not a conventional ACPI device node either (i.e. it lacks a _HID).
>
> And well, this discussion touches also acpismbus(4); in the future some ACPI
> driver may want to access iic(4) through it?

Hmmm, yes, this could be an issue.   :)



-------------------------------------------------------------------------
|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------