Re: [Qemu-devel] [PATCH 0/4] cpu: Implement cpu_generic_new()

[Eduardo Habkost]

On Fri, Feb 17, 2017 at 08:05:22PM +0100, Igor Mammedov wrote:
> On Mon, 13 Feb 2017 14:28:15 +0000
> Peter Maydell <address@hidden> wrote:
> 
> > This patchset adds a new function cpu_generic_new()
> > which is similar to cpu_generic_init() except that it
> > does not realize the created CPU object. This means that
> > board code can do a "new cpu; set QOM properties; realize"
> > sequence without having to do all the work of splitting
> > the CPU model string and calling parse_features by hand.
> > 
> > Patch 2 clarifies a TODO comment, hopefully correctly,
> > based on an email conversation I had with Eduardo a
> > little while back.
> > 
> > Patches 3 and 4 change the ARM boards which currently
> > call parse_features by hand to use the new function.
> > 
> > 
> > If there's consensus that this is the right general
> > direction to go in, then I think that some other
> > architectures could also make cleanups to use this:
> >  * cpu_s390x_create() is almost exactly this function,
> >    give or take some fine detail of error handling
> >  * ppc_cpu_parse_features is almost the same thing,
> >    except that it doesn't actually create the CPU object,
> >    it only calls parse_features
> >  * hw/i386/pc.c does a manual parse_features
> > 
> > I'm not strongly attached to this particular approach
> > (though it seems like a reasonable one, especially given
> > the proliferation of different arch-specific helpers
> > listed above and the bugs in boards which don't call
> > parse_features when they should), but I would like us to
> > figure out and document what the right way for a board
> > to create and configure its CPU objects is...
> 
> series looks like a step back adding yet another way
> to create CPU and makes code even more inconsistent,
> instead of removing TODO item by doing proper generalization.
> So I'm sort of object to it.
> 
> I'll just posted RFC which show idea how generalization of
> cpu_model/features parsing should be implemented.
> 
> However I don't have cycles to complete it, only
> virt-arm/spapr/pc are converted as example.
> One who would pick the task up should complete it for
> all boards to make code consistent.

If conversion of the code will take a while and this wrapper
removes code duplication of the current boards, I believe this
series is stlil a step in the right direction, even if the plan
is to replace the wrapper one day. But I will take a look at your
RFC first, before giving my opinion on which approach to take.

-- 
Eduardo