All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: peter.maydell@linaro.org, mst@redhat.com, qemu-devel@nongnu.org,
	peterx@redhat.com, qemu-arm@nongnu.org, pbonzini@redhat.com,
	jean-philippe@linaro.org, bbhushan2@marvell.com,
	eric.auger.pro@gmail.com
Subject: Re: [PATCH v3 1/5] qdev: Introduce DEFINE_PROP_RESERVED_REGION
Date: Tue, 23 Jun 2020 17:22:33 +0200	[thread overview]
Message-ID: <e5964e6e-2ee2-577d-775a-b02d63bca651@redhat.com> (raw)
In-Reply-To: <87imfhhkyz.fsf@dusky.pond.sub.org>

Hi Markus,

On 6/23/20 5:15 PM, Markus Armbruster wrote:
> Auger Eric <eric.auger@redhat.com> writes:
> 
>> Hi Markus,
>>
>> On 6/22/20 1:22 PM, Markus Armbruster wrote:
>>> Eric Auger <eric.auger@redhat.com> writes:
>>>
>>>> Introduce a new property defining a reserved region:
>>>> <low address>, <high address>, <type>.
> [...]
>>> I dimly remember discussing the wisdom of numeric type here, dig, dig,
>>> ..., aha:
>>>
>>>     Subject: Re: [PATCH for-5.0 v11 12/20] qapi: Introduce DEFINE_PROP_INTERVAL
>>>     Date: Fri, 13 Dec 2019 11:03:02 +0100
>>>     Message-ID: <87y2vg4k6h.fsf@dusky.pond.sub.org>
>>>
>>>     >> So the "label" part of "<low address>,<high address>,label" is a number?
>>>     > yes it is.
>>>     >> 
>>>     >> Is a number appropriate for your use case, or would an enum be better?
>>>     > I think a number is OK. There might be other types of reserved regions
>>>     > in the future. Also if we want to allow somebody else to reuse that
>>>     > property in another context, I would rather leave it open?
>>>
>>>     I'd prioritize the user interface over possible reuse (which might never
>>>     happen).  Mind, I'm not telling you using numbers is a bad user
>>>     interface.  In general, enums are nicer, but I don't know enough about
>>>     this particular case.
>> Yep I remember too ;-) I left as it was because I think this property
>> could be used for other use cases.
> 
> YAGNI :)
> 
> A string would work, too, wouldn't it?
:-)

Eric
> 
> [...]
> 
> 



  reply	other threads:[~2020-06-23 15:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-11 15:12 [PATCH v3 0/5] VIRTIO-IOMMU probe request support and MSI bypass on ARM Eric Auger
2020-06-11 15:12 ` [PATCH v3 1/5] qdev: Introduce DEFINE_PROP_RESERVED_REGION Eric Auger
2020-06-22 11:22   ` Markus Armbruster
2020-06-23  8:22     ` Auger Eric
2020-06-23  8:57       ` Markus Armbruster
2020-06-23 15:15       ` Markus Armbruster
2020-06-23 15:22         ` Auger Eric [this message]
2020-06-11 15:12 ` [PATCH v3 2/5] virtio-iommu: Implement RESV_MEM probe request Eric Auger
2020-06-17  9:16   ` Jean-Philippe Brucker
2020-06-18  9:04     ` Auger Eric
2020-06-11 15:12 ` [PATCH v3 3/5] virtio-iommu: Handle reserved regions in the translation process Eric Auger
2020-06-17  9:16   ` Jean-Philippe Brucker
2020-06-11 15:12 ` [PATCH v3 4/5] virtio-iommu-pci: Add array of Interval properties Eric Auger
2020-06-11 15:12 ` [PATCH v3 5/5] hw/arm/virt: Let the virtio-iommu bypass MSIs Eric Auger
2020-06-17  9:18   ` Jean-Philippe Brucker

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=e5964e6e-2ee2-577d-775a-b02d63bca651@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=armbru@redhat.com \
    --cc=bbhushan2@marvell.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=jean-philippe@linaro.org \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-arm@nongnu.org \
    --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.