Re: [Xen-devel] [PATCH][pvops_dom0][2/4] Introduce the external control operation interface for domain0 ACPI parser

[Jeremy Fitzhardinge <jeremy@goop.org>]

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