On Fri, Feb 17, 2017 at 08:05:22PM +0100, Igor Mammedov wrote: > On Mon, 13 Feb 2017 14:28:15 +0000 > Peter Maydell <peter.mayd...@linaro.org> 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
