All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, Geoffrey McRae <geoff@hostfission.com>
Subject: Re: [Qemu-devel] [for-4.0 PATCH v3 3/9] qapi: Define PCIe link speed and width properties
Date: Wed, 5 Dec 2018 08:53:38 -0700	[thread overview]
Message-ID: <20181205085338.358dc9bd@x1.home> (raw)
In-Reply-To: <87y394wd9p.fsf@dusky.pond.sub.org>

On Wed, 05 Dec 2018 10:09:38 +0100
Markus Armbruster <armbru@redhat.com> wrote:

> Alex Williamson <alex.williamson@redhat.com> writes:
> 
> > Create properties to be able to define speeds and widths for PCIe
> > links.  The only tricky bit here is that our get and set callbacks
> > translate from the fixed QAPI automagic enums to those we define
> > in PCI code to represent the actual register segment value.  
> 
> QAPI can only generate enumerations with values 0, 1, 2, ...  You want
> different enumeration values, namely the actual register values.  You
> still want QAPI to get its standard mapping to and from strings.
> 
> This patch's solution is to define a non-QAPI enumeration type with the
> values you want [PATCH 1/9], then map between the enumerations in the
> PropertyInfo methods.  Works.
> 
> You could instead use the encoding chosen by QAPI for the properties,
> and map it to the register values on use.  Differently ugly.  Might be
> simpler.  Your choice to make.

As we discussed offline, I personally don't like using the magic macros
that QAPI generates outside of QAPI code; I can't git grep for them and
I need to remember to build the tree before using cscope in order to
find them.  Therefore I prefer to keep the translation to standard
macros within the QAPI code to make things more obvious, thus the
approach chosen.  I appreciate the feedback and alternative ideas.

> We could extend QAPI to permit specification of the enumeration values.
> Marc-André's work to permit conditionals makes the syntax flexible
> enough to support that.  Of course, adding QAPI features is worthwhile
> only if we get sufficient mileage out of them to result in an overall
> improvement.  Even if we decided to do it right now, I'd recommend not
> to wait for it, but instead plan to simplify after the feature lands.

Good to know.

> > Cc: Eric Blake <eblake@redhat.com>
> > Cc: Markus Armbruster <armbru@redhat.com>
> > Tested-by: Geoffrey McRae <geoff@hostfission.com>
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>  
> 
> Reviewed-by: Markus Armbruster <armbru@redhat.com>

Thanks!

Alex

  reply	other threads:[~2018-12-05 15:53 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-04 16:25 [Qemu-devel] [for-4.0 PATCH v3 0/9] pcie: Enhanced link speed and width support Alex Williamson
2018-12-04 16:26 ` [Qemu-devel] [for-4.0 PATCH v3 1/9] pcie: Create enums for link speed and width Alex Williamson
2018-12-04 17:02   ` Philippe Mathieu-Daudé
2018-12-06 11:08   ` Auger Eric
2018-12-04 16:26 ` [Qemu-devel] [for-4.0 PATCH v3 2/9] pci: Sync PCIe downstream port LNKSTA on read Alex Williamson
2018-12-06 11:08   ` Auger Eric
2018-12-04 16:26 ` [Qemu-devel] [for-4.0 PATCH v3 3/9] qapi: Define PCIe link speed and width properties Alex Williamson
2018-12-05  9:09   ` Markus Armbruster
2018-12-05 15:53     ` Alex Williamson [this message]
2018-12-05 12:42   ` Auger Eric
2018-12-05 14:16     ` Markus Armbruster
2018-12-05 14:27       ` Auger Eric
2018-12-05 16:21         ` Markus Armbruster
2018-12-05 16:44       ` Alex Williamson
2018-12-06 16:04     ` Alex Williamson
2018-12-04 16:26 ` [Qemu-devel] [for-4.0 PATCH v3 4/9] pcie: Add link speed and width fields to PCIESlot Alex Williamson
2018-12-06 11:08   ` Auger Eric
2018-12-04 16:26 ` [Qemu-devel] [for-4.0 PATCH v3 5/9] pcie: Fill PCIESlot link fields to support higher speeds and widths Alex Williamson
2018-12-06 11:08   ` Auger Eric
2018-12-06 16:00     ` Alex Williamson
2018-12-06 16:35       ` Auger Eric
2018-12-04 16:26 ` [Qemu-devel] [for-4.0 PATCH v3 6/9] pcie: Allow generic PCIe root port to specify link speed and width Alex Williamson
2018-12-06 11:22   ` Auger Eric
2018-12-04 16:27 ` [Qemu-devel] [for-4.0 PATCH v3 7/9] vfio/pci: Remove PCIe Link Status emulation Alex Williamson
2018-12-06 11:17   ` Auger Eric
2018-12-04 16:27 ` [Qemu-devel] [for-4.0 PATCH v3 8/9] q35/440fx/arm/spapr: Add QEMU 4.0 machine type Alex Williamson
2018-12-04 19:04   ` [Qemu-devel] [for-4.0 PATCH v3.1 8/9] q35/440fx/arm/spapr/ccw: " Alex Williamson
2018-12-04 19:16     ` Christian Borntraeger
2018-12-04 19:26       ` Alex Williamson
2018-12-04 19:29         ` Peter Maydell
2018-12-04 19:56           ` Alex Williamson
2018-12-04 20:02             ` Christian Borntraeger
2018-12-05  8:32             ` Cornelia Huck
2018-12-05 15:42               ` Alex Williamson
2018-12-05 16:01                 ` Cornelia Huck
2018-12-06 12:52             ` Eduardo Habkost
2018-12-06 16:24               ` Alex Williamson
2018-12-04 19:39       ` Marc-André Lureau
2018-12-06 11:20   ` [Qemu-devel] [for-4.0 PATCH v3 8/9] q35/440fx/arm/spapr: " Auger Eric
2018-12-06 19:12   ` Eduardo Habkost
2018-12-06 19:27     ` Alex Williamson
2018-12-04 16:27 ` [Qemu-devel] [for-4.0 PATCH v3 9/9] pcie: Fast PCIe root ports for new machines Alex Williamson
2018-12-05 21:35   ` Alex Williamson
2018-12-06 11:22   ` Auger Eric

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=20181205085338.358dc9bd@x1.home \
    --to=alex.williamson@redhat.com \
    --cc=armbru@redhat.com \
    --cc=geoff@hostfission.com \
    --cc=qemu-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.