From: David Gibson <david@gibson.dropbear.id.au>
To: Igor Mammedov <imammedo@redhat.com>
Cc: qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
qemu-ppc@nongnu.org
Subject: Re: [Qemu-devel] [PATCH for-2.11 2/6] ppc: make cpu_model translation to type consistent
Date: Fri, 25 Aug 2017 23:28:00 +1000 [thread overview]
Message-ID: <20170825132800.GM2772@umbus.fritz.box> (raw)
In-Reply-To: <20170825134007.73d69fa3@nial.brq.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 5017 bytes --]
On Fri, Aug 25, 2017 at 01:40:07PM +0200, Igor Mammedov wrote:
> On Fri, 25 Aug 2017 19:45:38 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
> > On Fri, Aug 25, 2017 at 09:27:40AM +0200, Igor Mammedov wrote:
> > > On Fri, 25 Aug 2017 11:38:19 +1000
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >
> > > > On Thu, Aug 24, 2017 at 10:21:47AM +0200, Igor Mammedov wrote:
> > > > > PPC handles -cpu FOO rather incosistently,
> > > > > i.e. it does case-insensitive matching of FOO to
> > > > > a CPU type (see: ppc_cpu_compare_class_name) but
> > > > > handles alias names as case-sensitive, as result:
> > > > >
> > > > > # qemu-system-ppc64 -M mac99 -cpu g3
> > > > > qemu-system-ppc64: unable to find CPU model ' kN�U'
> > > > >
> > > > > # qemu-system-ppc64 -cpu 970MP_V1.1
> > > > > qemu-system-ppc64: Unable to find sPAPR CPU Core definition
> > > > >
> > > > > while
> > > > >
> > > > > # qemu-system-ppc64 -M mac99 -cpu G3
> > > > > # qemu-system-ppc64 -cpu 970MP_v1.1
> > > > >
> > > > > start up just fine.
> > > > >
> > > > > Considering we can't take case-insensitive matching away,
> > > > > make it case-insensitive for all alias/type/core_type
> > > > > lookups.
> > > > >
> > > > > As side effect it allows to remove duplicate core types
> > > > > which are the same but use lower-case letters in name.
> > > > >
> > > > > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > > >
> > > > Hmm. So, I'm certainly good with making the matching more consistent,
> > > > and removing extra entries differing only in case.
> > > >
> > > > However, I don't like capitalizing everything in the model table. The
> > > > "canonical" capitalization - as in how it appears in manuals and
> > > > marketing info - is quite frequently mixed case. So I think making
> > > > everything caps in the table will make it harder to read in the
> > > > context of looking at the corresponding documentation.
> > > only cpu models => typenames are made caps, the rest
> >
> > Yes, I know. A number of the CPU model names themselves have mixed
> > case. Really.
> >
> > > incl. description is kept as is in mixed case.
> > > It looks like _desc is the thing one would use for
> > > 1:1 lookup in spec, while _name isn't direct match consistently
> > > (i.e. sometimes it skips spaces and sometimes spaces are replaced by underscore).
> > > So keeping _name in mixed case unnecessarily complicates name->type lookup.
> > >
> > > These mixed case + case-insensitive is what made lookup
> > > code over-engineered and overly complex.
> >
> > I'm fine with making all the lookups case insensitive. I just don't
> > want to drop the case on the names in the actual code.
> I've tried to find a way but considering that names are statically
> 'converted' into typenames and lack of ability to magically
> uppercase them with preprocessor, I've gave up on this approach.
Ok.
> Providing that there is _desc with model name that should be
> greppable in spec and complexity of lookup code that mixed-cased
> typenames incur, I've opted in favor of simplifying lookup
> code at expense uniform typenames (which is inter QEMU thingy).
> It is easier to maintain and less chances to make mistake.
Yeah, I guess. It just looks weird to have non-standard capsing in
the table field.
Any chance we could standardize on lowercase rather than upper - for
some reason that would seem less odd to me (I guess because C-ish
names and identifiers are usually lowercased).
> Other targets use exact match for cpu_model so whether
> they use mixed casing or not doesn't matter.
>
> > > As result it evolved (regressed) to inconsistent name handling
> > > since it's rather hard to understand what's going on there.
> >
> > Yeah, I know :/.
> >
> > > > Can we instead retain mixed case in the table, and capitalize both
> > > > sides at the comparison time?
> > > it has to be the same-case since PPC has case-insensitive cpu_model
> > > matching (sometimes :/). Normalized /same case/ typenames
> > > are necessary for object_class_by_name() to work as it does exact match.
> > > So it would be possible to replace custom fetching of CPU types
> > > and iterating over it with custom comparator with object_class_by_name().
> > > As it's done in 4/6.
> > > This patch and 3/6 are only preparatory patches for 4/6.
> >
> > Ah. Hrm. That's awkward.
> It's fine to squash all 3 in 1 patch, but then it becomes huge and
> unreview-able, as logic changes are buried within names normalization.
Sorry, I meant it's awkward that that object_class_by_name() uses exact
and so we'd need a custom iterator to do a case insensitive search.
The patch structure is fine.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-08-25 13:29 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-24 8:21 [Qemu-devel] [PATCH for-2.11 0/6] ppc: cpu_model handling cleanups Igor Mammedov
2017-08-24 8:21 ` [Qemu-devel] [PATCH for-2.11 1/6] ppc: use macros to make cpu type name from string literal Igor Mammedov
2017-08-25 1:30 ` David Gibson
2017-08-25 7:28 ` Igor Mammedov
2017-08-25 13:24 ` David Gibson
2017-08-24 8:21 ` [Qemu-devel] [PATCH for-2.11 2/6] ppc: make cpu_model translation to type consistent Igor Mammedov
2017-08-25 1:38 ` David Gibson
2017-08-25 7:27 ` Igor Mammedov
2017-08-25 9:45 ` David Gibson
2017-08-25 11:40 ` Igor Mammedov
2017-08-25 13:28 ` David Gibson [this message]
2017-08-25 14:34 ` Igor Mammedov
2017-08-29 7:26 ` David Gibson
2017-08-24 8:21 ` [Qemu-devel] [PATCH for-2.11 3/6] ppc: make cpu alias point only to real cpu models Igor Mammedov
2017-08-25 1:40 ` David Gibson
2017-08-24 8:21 ` [Qemu-devel] [PATCH for-2.11 4/6] ppc: replace inter-function cyclic dependency/recurssion with 2 simple lookups Igor Mammedov
2017-08-25 4:12 ` David Gibson
2017-08-25 7:34 ` Igor Mammedov
2017-08-30 3:05 ` David Gibson
2017-08-30 6:16 ` Igor Mammedov
2017-08-24 8:21 ` [Qemu-devel] [PATCH for-2.11 5/6] ppc: simplify cpu model lookup by PVR Igor Mammedov
2017-08-25 4:16 ` David Gibson
2017-08-25 7:40 ` Igor Mammedov
2017-08-25 9:32 ` David Gibson
2017-08-25 11:41 ` Igor Mammedov
2017-08-30 10:50 ` Igor Mammedov
2017-08-31 5:54 ` David Gibson
2017-08-24 8:21 ` [Qemu-devel] [PATCH for-2.11 6/6] ppc: drop caching ObjectClass from PowerPCCPUAlias Igor Mammedov
2017-08-25 4:22 ` David Gibson
2017-08-25 7:49 ` Igor Mammedov
2017-08-29 7:30 ` David Gibson
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=20170825132800.GM2772@umbus.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=agraf@suse.de \
--cc=imammedo@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/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).