>>> On 08.09.16 at 20:53, <boris.ostrov...@oracle.com> wrote:
> On 09/08/2016 10:20 AM, Jan Beulich wrote:
>>> --- a/tools/libacpi/libacpi.h
>>> +++ b/tools/libacpi/libacpi.h
>>> @@ -48,6 +48,15 @@ struct acpi_ctxt {
>>> void (*free)(struct acpi_ctxt *ctxt, void *v, uint32_t size);
>>> unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
>>> } mem_ops;
>>> +
>>> + unsigned int page_size;
>>> + unsigned int page_shift;
>>> +
>>> + /* Memory allocator */
>>> + unsigned long alloc_base_paddr;
>>> + unsigned long alloc_base_vaddr;
>>> + unsigned long alloc_currp;
>>> + unsigned long alloc_end;
>>> };
>> There not being (or getting added) any users of these in libacpi/, I
>> wonder how this is related to the subject of the patch. If this is
>> data that only libxl needs for its own purposes, then surely this
>> shouldn't get added to struct acpi_ctxt, but should be a libxl
>> private extension of that structure.
>
> struct acpi_ctxt {
> ...
>
> void *private;
> };
>
> ?
That's one option; I'd prefer
struct libxl_acpi_ctxt {
struct acpi_ctxt ctxt;
...
};
though, together with whatever equivalent to container_of() exists
in libxl.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
