In retrospect, perhaps having a separate directory under /kernel would
be better, and then vendors could deploy their own acpi modules without
having to touch the acpi_drv binary.
E.g.:
/kernel/acpi/acpi_toshiba
/kernel/acpi/amd64/acpi_toshiba
(Perhaps even /platform would be better...
/platform/i86pc/kernel/acpi/acpi_toshiba, etc.)
If the "strings" are sufficiently unique, you could even use something
along the lines of:
/kernel/acpi/acpi_TOS1900
There's a possibly different approach as well -- you could have acpi_drv
be a nexus, and create child nodes with the node name of the form
"acpi,TOS1900" or somesuch. That might actually be the *most* elegant.
-- Garrett
Kerry Shu wrote:
>
>
> James Carlson wrote:
>> Kerry Shu writes:
>>> My current implementation is to define a static array with known vendor
>>> specific modules name(currently only acpi_toshiba) in acpi_drv.
>>> Yes, it expects at most one of them to return 0 from _init().
>>
>> OK; thanks. That's what I was looking for.
>>
>>> Got it. If I do find conflicts in our testing, I'll take your
>>> suggestion. Thanks! Btw, for Toshiba, we are searching for "TOS6208"
>>> and
>>> "TOS1900" in ACPI namespace.
>>
>> But no TOS6200?
>
> We only got docs about "TOS6208" and "TOS1900" from Toshiba. And the
> Toshiba laptops we have support either of them. I'll ask IHV team for
> help to get info about "TOS1900". It should be straightforward to add it
> or more in if we have the related docs. Thanks!
>
>>
>> (I think Linux is trying to unify the various naming schemes,
>> including ACPI modules, PCI IDs, and others, through lkddb. It'd be
>> nice if we could do something similar rather than having a new wheel.)
>>
>
> How do you think about our current ACPI modules naming?
> acpi_drv: for generic ACPI method
> acpi_toshiba, acpi_XXXX: for vendor specific ACPI method
>
> Regards,
> Kerry
