[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader
On 09/15/2016 06:22 AM, Wei Liu wrote: > On Thu, Sep 15, 2016 at 11:20:08AM +0100, Julien Grall wrote: >> Hi Wei, >> >> On 15/09/2016 11:18, Wei Liu wrote: >>> On Wed, Sep 14, 2016 at 11:21:39AM -0400, Boris Ostrovsky wrote: >>>> On 09/07/2016 02:59 PM, Boris Ostrovsky wrote: >>>>> The goal here is to build ACPI tables for PVHv2/HVMlite guests while >>>>> reusing existing >>>>> hvmloader's ACPI builder code. The builder is provided as a library in >>>>> tools/libacpi. >>>>> >>>>> This is version 3 of the series, see individual patches for changes. It >>>>> can >>>>> be fetched from git://oss.oracle.com/git/bostrovs/xen.git:acpi_v3 >>>> Wei, Ian --- are there any comments from the toolstack perspective? >>>> >>>>> The series is probably still gated by lack of an ACK from Lenovo for the >>>>> relicensing patch (included here as patch 1). >>>>> >>>> So I looked again at commit 801d469ad8b2b88f669326327df03d03200efbfb >>>> (which is the patch from Lenovo) and it only does 2 things (assuming I >>>> parsed ASL correctly): >>>> * Adds _PIC method >>>> * Controls and describes legacy PCI interrupt routing. This >>>> functionality has actually been moved into mk_dsdt.c and so this ASL >>>> code is now generated. >>>> >>>> Neither of these two things is used by libxl so technically we may not >>>> need the ACK from Lenovo. OTOH, we may forget about this restriction in >>>> the future and accidentally include those two later. >>>> >>> This is a risk I would rather not take. As you said, we may forget about >>> the restriction in the future. >> Does it mean this series may not be in Xen 4.8? If so, this will also delay >> other series such as the ACPI guest support for ARM. >> > I would like to see this and the subsequent ARM series in 4.8 -- it is > still possible we get an ack from Lenovo any time, but the issue is out > of our control at the moment. It's just one unfortunate incident in open > source software development. Sigh. One option could be to provide a 'gpl_all' (or some such) target in libacpi in addition to 'all' and that target will be careful about not including these small un-ACKed portions of the code. It will be ugly though. -boris _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |