On 07/30/09 09:00, Len Brown wrote:
>>> 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.
>>>
>
> Many have incorporated ACPICA into their OS, from BeOS to BSD,
> Solaris to Linux. And I'm not going to tell you that you can't
> do the same and make the xen hypervisor into an OS that knows
> about both policy and the hardware it is running on.
>
> However, ACPI != all the ACPI code in Linux. ACPICA is the
> stuff in the drivers/acpi/acpica directory, and nothing else
> (asside from a few header files outside that directory)
>
> Also, I'm not sure the OS you build will be competitive with
> other OS's when you're done.
>
Yes. The general intent is that Xen tries to avoid having to
reimplement stuff that the guest operating systems are already much
better at. However, it seems that ACPI's
>
>>>>> s/extcntl/xen/ to make it clear why this code exists --
>>>>> or is there an expected "external control" other than Xen?
>>>>>
> ...
>
>>> 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.)
>>>
>> Can you explain what the deeper design problem is?
>>
>
> Obfuscating the code by calling a Xen-specific abstraction
> "extcntl" instead of "xen" will not fly.
>
> Jeremy's desire to create and use generic abstractions that have multliple
> users is a good thing. It simply does not apply here.
>
OK. I don't really understand ACPIs overall design or philosophy,
beyond a rough idea of what kinds of things it gets used for. If there
really is no scope for refactoring things to make Ke's changes fit in
more naturally, then I guess we can live with some explicit hooks.
> I have no objection to having a xen-specific hook being called xen_*
> To do otherwise would be a dis-service to future maintainers of the code.
>
I agree completely. I have no interest in extra layers of
indirection/"abstraction" which are just disguises rather than having
some inherent value.
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
