From: Kevin Wolf <kwolf@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-block@nongnu.org, philmd@redhat.com, qemu-devel@nongnu.org,
Laszlo Ersek <lersek@redhat.com>,
mreitz@redhat.com, alex.bennee@linaro.org
Subject: Re: [Qemu-devel] [PATCH v7] pflash: Require backend size to match device, improve errors
Date: Fri, 8 Mar 2019 16:40:44 +0100 [thread overview]
Message-ID: <20190308154043.GE31583@localhost.localdomain> (raw)
In-Reply-To: <87sgvxbft2.fsf@dusky.pond.sub.org>
Am 08.03.2019 um 15:29 hat Markus Armbruster geschrieben:
> Kevin Wolf <kwolf@redhat.com> writes:
>
> > 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.
>
> Yes.
>
> The helper I came up with (appended) isn't really specific to flash
> devices. Would it be okay for hw/block/block.c even though only the two
> flash devices use it for now?
Hm, it feels more like a helper for devices that can't decide whether
they want to be a block device or not. Or that actually don't want to be
a block device, but use a BlockBackend anyway. Reading in the whole
image isn't something that a normal block device would do.
But yes, it doesn't have flash-specific knowledge, even though I hope
that it's functionality that will remain very specific to these two
devices.
So it's your call, I don't have a strong opinion either way.
>
> bool blk_check_size_and_read_all(BlockBackend *blk, void *buf, hwaddr size,
> Error **errp)
> {
> int64_t blk_len;
> int ret;
>
> blk_len = blk_getlength(blk);
> if (blk_len < 0) {
> error_setg_errno(errp, -blk_len,
> "can't get size of block backend '%s'",
> blk_name(blk));
> return false;
> }
> if (blk_len != size) {
> error_setg(errp, "device requires %" PRIu64 " bytes, "
> "block backend '%s' provides %" PRIu64 " bytes",
> size, blk_name(blk), blk_len);
Should size use HWADDR_PRIu?
I'm not sure if printing the BlockBackend name is a good idea because
hopefully one day the BlockBackend will be anonymous even for the flash
devices.
> return false;
> }
>
> /* TODO for @size > BDRV_REQUEST_MAX_BYTES, we'd need to loop */
> assert(size <= BDRV_REQUEST_MAX_BYTES);
I don't think we'd ever want to read in more than 2 GB into a memory
buffer. Before we even get close to this point, the devices should be
reworked to be more like an actual block device and read only what is
actually accessed.
> ret = blk_pread(blk, 0, buf, size);
> if (ret < 0) {
> error_setg_errno(errp, -ret, "can't read block backend '%s'",
> blk_name(blk));
> return false;
> }
> return true;
> }
Kevin
next prev parent reply other threads:[~2019-03-08 15:40 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é
2019-03-08 14:29 ` Markus Armbruster
2019-03-08 15:40 ` Kevin Wolf [this message]
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=20190308154043.GE31583@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=lersek@redhat.com \
--cc=mreitz@redhat.com \
--cc=philmd@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.