On 13 February 2017 at 14:28, 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...
I know it's only been a few days, but I just wanted to say that I'd appreciate it if we could manage relatively quick review on this one, since I have a set of patches pending that depend on this and which it would be nice to get into 2.9 (softfreeze approaching rapidly). thanks -- PMM
