Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder
available to components other than hvmloader"):
> But we'd still have to deal with mk_dsdt.c which is where the second,
> larger, chunk of Lenovo patch went.
Right, sorry, I ha
On 09/19/2016 11:30 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder
> available to components other than hvmloader"):
>> _S5 object still exists but it's content has been modified by subsequent
>> non-Lenovo ch
Boris Ostrovsky writes ("Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder
available to components other than hvmloader"):
> _S5 object still exists but it's content has been modified by subsequent
> non-Lenovo changes so I think we can not worry about lines 20-30.
>
>
On 09/16/2016 11:22 AM, Lars Kurth wrote:
>
> On 16/09/2016 13:41, "Boris Ostrovsky" wrote:
>
>> On 09/16/2016 02:45 AM, Jan Beulich wrote:
> And then there's the question of whether excluding things from the
> build, but having them present in the sources actually helps.
The main rea
On 16/09/2016 13:41, "Boris Ostrovsky" wrote:
>On 09/16/2016 02:45 AM, Jan Beulich wrote:
>>
And then there's the question of whether excluding things from the
build, but having them present in the sources actually helps.
>>> The main reason for this whole relicensing debacle is to pr
On 09/16/2016 02:45 AM, Jan Beulich wrote:
>
>>> And then there's the question of whether excluding things from the
>>> build, but having them present in the sources actually helps.
>> The main reason for this whole relicensing debacle is to prevent non-GPL
>> binaries from linking against GPL obje
>>> On 15.09.16 at 18:40, wrote:
> On 09/15/2016 12:05 PM, Jan Beulich wrote
>
>>> Maybe even without changes to mk_dsdt.c
>> But isn't that the critical part?
>
> Not necessarily since we'd use --gpl option only for
> dsdt_anycpu_qemu_xen, dsdt_anycpu and dsdt_15cpu and these files are not
> u
On 09/15/2016 12:05 PM, Jan Beulich wrote
>> Maybe even without changes to mk_dsdt.c
> But isn't that the critical part?
Not necessarily since we'd use --gpl option only for
dsdt_anycpu_qemu_xen, dsdt_anycpu and dsdt_15cpu and these files are not
used by the non-GPL caller, which is libxl (it on
>>> On 15.09.16 at 17:28, wrote:
> Something along the lines of this (attached as well to prevent line
> wrapping)
Looks reasonable with some polishing (GPL=y on the make lines and
using C_SRC-$(GPL) and CSRC-y).
> Maybe even without changes to mk_dsdt.c
But isn't that the critical part? And -
On 09/15/2016 10:21 AM, Jan Beulich wrote:
On 15.09.16 at 16:07, wrote:
>> On 09/15/2016 09:48 AM, Julien Grall wrote:
>>> On 15/09/2016 13:39, Boris Ostrovsky wrote:
One option could be to provide a 'gpl_all' (or some such) target in
libacpi in addition to 'all' and that target wil
>>> On 15.09.16 at 16:07, wrote:
> On 09/15/2016 09:48 AM, Julien Grall wrote:
>> On 15/09/2016 13:39, Boris Ostrovsky wrote:
>>> 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
On 09/15/2016 09:48 AM, Julien Grall wrote:
> Hi Boris,
>
> On 15/09/2016 13:39, Boris Ostrovsky wrote:
>> 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 a
Hi Boris,
On 15/09/2016 13:39, Boris Ostrovsky wrote:
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, Bor
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
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
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 provi
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/liba
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 change
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/bostrov
19 matches
Mail list logo
