On 07/28/09 23:20, Yu, Ke wrote:
> Your question is reasonable. there is also debate here before. People discuss if it is possible to add acpica stuff to xen hypervisor and let xen control the acpi completely. Unfortunately, this will lead dilemma here, i.e. some devices are controlled by dom0 and also need acpi info, e.g. battery, thermal, etc. and pci hotplug in dom0 is another example. Tian Kevin has detail description on this issue in the attached mail.
>
What would happen if we special-cased dom0 VCPUs to be bound 1:1 to
PCPUs. Would that simplify this stuff? Wouldn't that make CPU control
equivalent to battery, fan, etc?
> On the other hand, the dom0 acpica approach has other benefit, i.e. current linux acpica stuff is pretty mature and has numerous bug fix. Leveraging acpica in linux kernel is more practical.
>
My understanding is that all that code is supposed to be
kernel-independent. We could lift all that code as-is, write some new
kernel interface shims and shove it all into Xen. But I don't know if
that solves any more problems than it causes.
>> s/extcntl/xen/ to make it clear why this code exists --
>> or is there an expected "external control" other than Xen?
>>
>> -Len
>>
>
> Ok, I can try this. BTW, besides this naming change, do you have other comment on the code? So that I can make it more clean.
>
I don't think that's a good idea. If we need to do that, then there's a
deeper design problem we need to address. (And, if nothing else, people
have become hypersensitive to naked Xen-specific code references in
non-Xen files, and I'm tired of having those arguments.)
J
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
