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. 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). > > 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). > -- Eduardo