Re: [Qemu-devel] [PATCH 00/13] convert AML API to QOM

[Marcel Apfelbaum]

On 01/28/2015 02:44 PM, Andrew Jones wrote:
> On Wed, Jan 28, 2015 at 10:03:24AM +0000, Igor Mammedov wrote:
> > Example demonstrates use of QOM object for building AML
> > objects tree and freeing it explicitly when requested.
> >
> > Top level ACPI tables blob object is only partially
> > switched to object model now but I hope it demostrates
> > the point of absracting code and hiding parts of code
> > that could be done without user intervention.
> >
> > Pathes 1/2/8 are just a convertion boiler plate which
> > will go away on respin.
> >
> >
> > Igor Mammedov (13):
> >    convert to passing AcpiAml by pointers
> >    make toplevel ACPI tables blob a pointer
> >    qom: add support for weak referenced object: aka UnownedObject
> >    acpi: make AcpiAml an OQM object
> >    acpi: use TYPE_AML_OBJECT inside of AML API
> >    acpi: use TYPE_AML_OBJECT for toplevel ACPI tables blob
> >    acpi: make toplevel ACPI tables blob a dedicated object
> >    i386: acpi: hack not yet converted tables calls to deal with
> >      table_data being a pointer
> >    acpi: add aml_blob() helper
> >    i386: acpi: add DSDT table using AML API
> >    acpi: acpi_add_table() to common cross target file
> >    acpi: prepare for API internal collection of RSDT entries
> >    i386: acpi: mark SSDT as RSDT entry so API would add entry to RSDT
> >      automatically
> >
> >   hw/acpi/acpi-build-utils.c         | 537 +++++++++++++++++++++----------------
> >   hw/i386/acpi-build.c               | 388 +++++++++++++--------------
> >   include/hw/acpi/acpi-build-utils.h | 119 +++++---
> >   include/qom/object.h               |  20 ++
> >   qom/object.c                       |  20 +-
> >   5 files changed, 620 insertions(+), 464 deletions(-)
> >
> > --
> > 1.8.3.1
>
> Thanks for doing this.
Thanks also fomr me! It is really  interesting to see this.

 It's satisfied my curiosity as to how
> much boilerplate we'd need for the conversion. I looked mainly
> at the first half of this series, as it appears the second half
> is an add-on, not directly relevant to the explicit memory
> management vs. object model memory management discussion. The
> additional code, and need for QOM knowledge, appears pretty low.
> So, as this would allow developers focused on ACPI table
> construction to almost completely avoid doing any memory
> management themselves, then, FWIW, it looks like a good trade
> off to me.

While I am not against this approach, maybe a simpler idea of keeping
an internal static map of allocated vars and freeing it in the end would be 
enough.

That being said, this approach gives us the opportunity to create QOM objects
for all AML constructs as AcpiArg for example:
    AcpiAml arg = object_new(ACPI_ARG_TYPE);
and handling the implementation inside the corresponding init function.

Thanks,
Marcel

> drew