On Mon, 24 Jul 2023 16:14:22 +0100
Peter Maydell <peter.mayd...@linaro.org> wrote:
> On Mon, 24 Jul 2023 at 16:06, Igor Mammedov <imamm...@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
>
