qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Gavin Shan <gshan@redhat.com>,
	Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>,
	qemu-arm@nongnu.org, qemu-devel@nongnu.org, pbonzini@redhat.com,
	eduardo@habkost.net, marcel.apfelbaum@gmail.com,
	philmd@linaro.org, wangyanan55@huawei.com, shan.gavin@gmail.com,
	berrange@redhat.com
Subject: Re: [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation
Date: Tue, 25 Jul 2023 08:46:47 +0200	[thread overview]
Message-ID: <20230725084647.082428f3@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <CAFEAcA-Tp7_vpGUea4W6cf3rTDqqGKy6VtsguDjiSAbRX=dL=Q@mail.gmail.com>

On Mon, 24 Jul 2023 16:14:22 +0100
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Mon, 24 Jul 2023 at 16:06, Igor Mammedov <imammedo@redhat.com> wrote:
> > I've seen others asking why you print type name instead of shorter cpu-model
> > used on CLI. To do that would make you write a patch to implement reverse mapping.
> > In some cases it's simple, in others plain impossible unless you can get
> > access to -cpu foo stored somewhere.
> >
> > What I don't particularity like about adding reverse type->cpu_model mapping,
> > is that it would complicate code to carter to QEMU's interface inconsistencies.
> > And if you do it easy way (instead of fixing every target) touching only ARM,
> > it will be spotty at best and just add to technical debt elsewhere ->
> > more inconsistencies.
> >
> > What I'm proposing is for you to keep printing type names.
> > So if others won't object to type names I'm more or less fine with your
> > current approach.  
> 
> I do object to type names, because the UI for choosing
> a CPU ("-cpu whatever") does not take type names, it
> takes CPU names. The QOM type names that those end up
> being under the hood are a detail of QEMU's implementation
> that we shouldn't expose to users in the help messages.

those are exposed to users as a part of -device interface
which uses typenames for any device and based on that interface
in some monitor/qmp commands 

> > Instead of adding type->cpu_model mapping (it's not the first time
> > this particular question had arisen - there were similar patches before
> > on qemu-devel), get rid of shortened cpu_model in user interface (-cpu)
> > altogether and use CPU type name there.  
> 
> I also think we should not do this, because it will break
> a ton of existing command lines, and it's not clear it
> has any benefit to users.

Yes it will break existing scripts but that for users to fix up once
(not to mention that could be worked around with a wrapper,
QEMU can even supply that for existing cpu types).
(so along with deprecation, we can provide a warning +
a wrapper to use, and after deprecation make it a hard error
but keep wrapper around for those that do not wish to use typenames)

Consistent naming across UI and consistent name -> type handling 
would be beneficial to users in the long run (especially ones
that have to deal with both interfaces so that they won't
have to bother which use where).

> thanks
> -- PMM
> 



  reply	other threads:[~2023-07-25  6:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-13  5:44 [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation Gavin Shan
2023-07-13  5:45 ` [PATCH 1/3] machine: Factor CPU type invalidation out into helper Gavin Shan
2023-07-14 12:07   ` Igor Mammedov
2023-07-18  6:11     ` Gavin Shan
2023-07-24 14:39       ` Igor Mammedov
2023-07-13  5:45 ` [PATCH 2/3] hw/arm/virt: Use generic CPU type invalidation Gavin Shan
2023-07-14 11:59   ` Igor Mammedov
2023-07-18  6:17     ` Gavin Shan
2023-07-13  5:45 ` [PATCH 3/3] hw/arm/virt: Support host CPU type only when KVM or HVF is configured Gavin Shan
2023-07-13 12:46   ` Cornelia Huck
2023-07-13 13:16     ` Gavin Shan
2023-07-13 11:44 ` [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation Peter Maydell
2023-07-13 11:52   ` Marcin Juszkiewicz
2023-07-13 11:59     ` Peter Maydell
2023-07-14 11:50       ` Igor Mammedov
2023-07-14 12:56         ` Peter Maydell
2023-07-17 12:44           ` Igor Mammedov
2023-07-18 10:31             ` Gavin Shan
2023-07-24 15:06               ` Igor Mammedov
2023-07-24 15:14                 ` Peter Maydell
2023-07-25  6:46                   ` Igor Mammedov [this message]
2023-07-13 12:34     ` Gavin Shan
2023-07-13 12:44       ` Marcin Juszkiewicz
2023-07-13 13:00         ` Gavin Shan
2023-07-13 16:29       ` Philippe Mathieu-Daudé
2023-07-14  0:51         ` Gavin Shan
2023-07-14  9:14           ` Gavin Shan
2023-07-13 19:27       ` Richard Henderson
2023-07-14  0:54         ` Gavin Shan
2023-07-13 12:42   ` Gavin Shan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230725084647.082428f3@imammedo.users.ipa.redhat.com \
    --to=imammedo@redhat.com \
    --cc=berrange@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=gshan@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=marcin.juszkiewicz@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shan.gavin@gmail.com \
    --cc=wangyanan55@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).