> >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. > >>> 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. 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. thanks, Len Brown, Intel Open Source Technology Center. -- 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
