Re: [Qemu-devel] [PATCH v17 7/9] add MachineClass->default_props for setting default device properties

[Eduardo Habkost]

On Tue, Jan 26, 2016 at 11:28:01AM +0100, Igor Mammedov wrote:
> On Sat, 23 Jan 2016 12:59:56 -0200
> Eduardo Habkost <address@hidden> wrote:
> 
> > On Tue, Jan 19, 2016 at 02:06:27PM +0100, Igor Mammedov wrote:
> > > Signed-off-by: Igor Mammedov <address@hidden>
> > > ---
> > >  include/hw/boards.h | 1 +
> > >  vl.c                | 4 ++++
> > >  2 files changed, 5 insertions(+)
> > > 
> > > diff --git a/include/hw/boards.h b/include/hw/boards.h
> > > index 0f30959..d495611 100644
> > > --- a/include/hw/boards.h
> > > +++ b/include/hw/boards.h
> > > @@ -90,6 +90,7 @@ struct MachineClass {
> > >      const char *default_machine_opts;
> > >      const char *default_boot_order;
> > >      const char *default_display;
> > > +    GlobalProperty *default_props;
> > >      GlobalProperty *compat_props;  
> > 
> > Could you explain (in a comment?) the purpose of each field? They
> > seem to do exactly the same thing, so why couldn't they become a
> > single linked list, where the compat classes just append new
> > items to the existing default_props list?
> > 
> > (If we build default_props by appending instead of overwriting
> > the parent class list, we will be able to finally eliminate
> > PC_COMPAT_* macro nesting)
> The only reason I've added it as separate field is to keep the
> current way compat_props are working instead of rewriting
> not related to this series part.
> 

OK to me, but I would like to have the reason for having two very
similar fields documented in struct MachineClass.

> Alternatively we could add qdev_prop_prepend_global_list() API
> and add static defaults calling it from board's machine-init.

If we can choose between having stuff in MachineClass and adding
extra machine-init code, I prefer to have it in MachineClass.

-- 
Eduardo