All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonid Bloch <lbloch@janustech.com>
To: Markus Armbruster <armbru@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"eblake@redhat.com" <eblake@redhat.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 0/1] block: Eliminate the S_1KiB, S_2KiB, ... macros
Date: Sun, 13 Jan 2019 09:42:27 +0000	[thread overview]
Message-ID: <5c18782a-4319-e87b-6b1f-6c808d837430@janustech.com> (raw)
In-Reply-To: <20190111191401.18317-1-armbru@redhat.com>

On 1/11/19 9:14 PM, Markus Armbruster wrote:
> Back in September, Leonid Block added a whole bunch of macros (commit

* Bloch. :)

> 540b8492618) to improve readability of qcow2.h a bit (commit
> b6a95c6d100).  He later used them to fix the "vdi" driver's parameter
> cluster_size's default value (commit 3dd5b8f4718).  He has now
> proposed a further patch[1] to auto-generate these macros.  That patch
> feels overengineered to me.
> 
> On closer examination, I found I dislike the macros before his new
> patch.  So did Eric Blake.
> 
> The macros exist because the common KiB, MiB, ... macros aren't usable
> when you need a literal rather than a constant expression.
> stringify() does, and we use it to define the QemuOpts default value.
> 
> Eric proposed to improve QemuOpts to accept integer default values,
> too[2].  Before I review that patch series, I want to establish a
> "stupidest solution that can possibly work" baseline.  And that's what
> this patch is.
> 
> [1] [PATCH v2 0/1] include: Auto-generate the sizes lookup table
> Message-ID: <20190103213320.2653-1-lbloch@janustech.com>
> 
> [2] [PATCH v3 0/6] include: Auto-generate the sizes lookup table
> Message-Id: <20190110191901.5082-1-eblake@redhat.com>
> 
> Markus Armbruster (1):
>    block: Eliminate the S_1KiB, S_2KiB, ... macros
> 
>   block/qcow2.h        | 10 +++---
>   block/vdi.c          |  3 +-
>   include/qemu/units.h | 73 --------------------------------------------
>   3 files changed, 7 insertions(+), 79 deletions(-)
> 

  parent reply	other threads:[~2019-01-13  9:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-11 19:14 [Qemu-devel] [PATCH 0/1] block: Eliminate the S_1KiB, S_2KiB, ... macros Markus Armbruster
2019-01-11 19:14 ` [Qemu-devel] [PATCH 1/1] " Markus Armbruster
2019-01-11 19:28   ` Eric Blake
2019-01-13  9:41   ` Leonid Bloch
2019-01-14 10:36     ` Philippe Mathieu-Daudé
2019-01-14 13:01       ` Markus Armbruster
2019-01-16 12:57   ` [Qemu-devel] [Qemu-block] " Alberto Garcia
2019-01-13  9:42 ` Leonid Bloch [this message]
2019-01-14  6:54   ` [Qemu-devel] [PATCH 0/1] " Markus Armbruster
2019-01-25 10:46 ` Kevin Wolf

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=5c18782a-4319-e87b-6b1f-6c808d837430@janustech.com \
    --to=lbloch@janustech.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@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.