On Tue, 18 Jun 2019 10:55:16 -0300 Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Tue, Jun 18, 2019 at 01:34:10PM +0200, Igor Mammedov wrote: > > On Mon, 17 Jun 2019 13:27:00 -0300 > > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > > > On Mon, Jun 17, 2019 at 05:33:43PM +0200, Igor Mammedov wrote: > > > > On Mon, 17 Jun 2019 17:15:21 +0200 > > > > Philippe Mathieu-Daudé <phi...@redhat.com> wrote: > > > [...] > > > > > Yes. Eduardo and you should write some lines to explain this, and then > > > > > we will follow :) > > > > Unfortunately I don't recall details anymore. One could check out all > > > > implementations of class_by_name callbacks to find out current state. > > > > > > > > > > See this message for a summary of existing class_by_name quirks: > > > > > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg615503.html > > > Date: Wed, 08 May 2019 10:34:44 +0200 > > > Message-ID: <877eb173a3....@dusky.pond.sub.org> > > > Subject: Re: [Qemu-devel] [PATCH 0/7] Delete 16 *_cpu_class_by_name() > > > functions > > > > > > I'm unsure about Igor's suggestion to get rid of CPU model names > > > and use only QOM type names in external interfaces. In either > > > case, we can still simplify the rules rules and reduce the amount > > > of arch-specific code. > > as far as we have cpu_class_by_name, we have to watch over that > > new patches/targets won't add some custom handling/fallbac/whatnot. > > We can get rid of CPUClass::cpu_class_by_name() without changing > the external interfaces provided by QEMU. if you mean QMP, than it is possible to keep model there where it already exists. Based on experiment [1](x86) I did, it's local to affected target and doesn't pollute other code. > I don't have a strong opinion about using only QOM types at -cpu, > yet. But first we need to get rid of the arch-specific CPU model > name exceptions enumerated at the URL above (which would be very > welcome). One way to get rid of them is to deprecate them in favor of strict match (no fallback/substitutions/aliases) to typename and when we drop it make switch type based naming only. 1) I've just took a quick look at how much of duplicated/confusing code we could get rid off if we drop cpu_class_by_name/*_cpu_list. It amounts to >800LOC of trivial removal (not counting ppc/s390 that depend on model naming heavily and in need of some non trivial refactoring) > > > > > On contrary -device works just with type names for all devices, > > applying the same to -cpu which is basically translator > > model->type[,-global type.foo,...] > > would be consistent with -device and less confusing for everyone > > (not counting significant code reduction). > > It would certainly simplify contributing new targets as contributor > > won't have to care about cpu model naming and do something about it. > > > > This option wasn't considered before because we didn't have deprecation > > back then, but now it opens possibility to simplify qemu and consolidate > > naming. (we probably would be able to fold '-cpu help' into '-device help' > > as well). > > >
