Port-i386 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: New ACPI power resource code for testing



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  |
-------------------------------------------------------------------------


Home | Main Index | Thread Index | Old Index