All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>, Markus Armbruster <armbru@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>,
	qemu-devel@nongnu.org, alex.bennee@linaro.org,
	qemu-block@nongnu.org, mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH v7] pflash: Require backend size to match device, improve errors
Date: Fri, 8 Mar 2019 15:26:51 +0100	[thread overview]
Message-ID: <952775a8-3736-320a-9f4a-1b3ec396e208@redhat.com> (raw)
In-Reply-To: <20190308133510.GC31583@localhost.localdomain>

On 3/8/19 2:35 PM, Kevin Wolf wrote:
> Am 08.03.2019 um 13:28 hat Markus Armbruster geschrieben:
>> Laszlo Ersek <lersek@redhat.com> writes:
>>> This one has got to be one of the longest bike-shedding sessions! :)
>>>
>>> I'm fine with this patch, but I could suggest two improvements.
>>>
>>> (1) When blk_getlength() fails, we could format the negative error code
>>> returned by it into the error message.
>>
>> I can do that.
> 
> By using error_setg_errno(), I assume. Not throwing away error details
> is always good.
> 
>>> (2) We could extract the common code to a new function in
>>> "hw/block/block.c". (It says "Common code for block device models" on
>>> the tin.)
>>
>> There's so much common code in these two files even before this patch...
> 
> My understanding is that hw/block/block.c contains code that is
> potentially useful to all kinds of block devices, not random code that
> two specific similar devices happen to share.
> 
> If we want to deduplicate some code in the flash devices, without any
> expectation that other devices will use it at some point, I'd rather
> create a new source file hw/block/pflash_common.c or something like
> that.

Agreed, I like that suggestion too.
Actually we already have been talking about a such
cleanup/refactor/rewrite with Markus, but this will wait the next QEMU
dev cycle.

  parent reply	other threads:[~2019-03-08 14:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-08  6:24 [Qemu-devel] [PATCH v7] pflash: Require backend size to match device, improve errors Markus Armbruster
2019-03-08 10:00 ` Alex Bennée
2019-03-08 12:16   ` Markus Armbruster
2019-03-08 11:47 ` Laszlo Ersek
2019-03-08 12:28   ` Markus Armbruster
2019-03-08 13:35     ` Kevin Wolf
2019-03-08 14:09       ` Laszlo Ersek
2019-03-08 14:26       ` Philippe Mathieu-Daudé [this message]
2019-03-08 14:29       ` Markus Armbruster
2019-03-08 15:40         ` Kevin Wolf
2019-03-08 16:45           ` Philippe Mathieu-Daudé
2019-03-08 17:03           ` Markus Armbruster
2019-03-08 17:18             ` Kevin Wolf
2019-03-08 18:51           ` Philippe Mathieu-Daudé
2019-03-09  9:20             ` Markus Armbruster
2019-03-08 14:40   ` Philippe Mathieu-Daudé

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=952775a8-3736-320a-9f4a-1b3ec396e208@redhat.com \
    --to=philmd@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mreitz@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.