From: Thomas Huth <thuth@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-block@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
Max Reitz <mreitz@redhat.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Anthony Perard <anthony.perard@citrix.com>,
xen-devel@lists.xenproject.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [QEMU PATCH] block: Remove blk_attach_dev_legacy() / legacy_dev code
Date: Wed, 19 Dec 2018 13:00:09 +0100 [thread overview]
Message-ID: <a1001443-d2ef-732c-fa26-cfa7b88b8e1a@redhat.com> (raw)
In-Reply-To: <878t0mbs79.fsf@dusky.pond.sub.org>
On 2018-12-18 19:33, Markus Armbruster wrote:
> Thomas Huth <thuth@redhat.com> writes:
>
>> The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
>> It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
>> is derived from XenDevice which in turn is derived from DeviceState
>> since commit 3a6c9172ac5951e ("xen: create qdev for each backend device").
>> Thus the code can also simply use blk_attach_dev() with a pointer
>> to the DeviceState instead.
>> So we can finally remove all code related to the "legacy_dev" flag, too,
>> and turn the related "void *" in block-backend.c into "DeviceState *"
>> to fix some of the remaining TODOs there.
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>> Note: I haven't tested the Xen code since I don't have a working Xen
>> installation at hand. I'd appreciate if someone could check it...
[...]
>> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
>> index 36eff94..9605caf 100644
>> --- a/hw/block/xen_disk.c
>> +++ b/hw/block/xen_disk.c
>> @@ -801,7 +801,9 @@ static int blk_connect(struct XenDevice *xendev)
>> * so we can blk_unref() unconditionally */
>> blk_ref(blkdev->blk);
>> }
>> - blk_attach_dev_legacy(blkdev->blk, blkdev);
>> + if (blk_attach_dev(blkdev->blk, DEVICE(blkdev)) < 0) {
>> + return -1;
>> + }
>
> Other error returns in this function call xen_pv_printf() first. Should
> this one, too?
Only some of them do a xen_pv_printf() first, there are also many that
don't. blk_attach_dev() currently only returns an error if a device has
already been attach - which should simply never happen here, so a printf
currently does not seem to be justified to me. Alternatively, we could
also abort() here instead, I think. I'll leave that decision up to the
Xen maintainers...
Thomas
next prev parent reply other threads:[~2018-12-19 12:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-18 16:11 [Qemu-devel] [QEMU PATCH] block: Remove blk_attach_dev_legacy() / legacy_dev code Thomas Huth
2018-12-18 18:33 ` Markus Armbruster
2018-12-19 12:00 ` Thomas Huth [this message]
2019-01-22 14:19 ` Thomas Huth
2019-01-22 14:46 ` Kevin Wolf
2019-01-22 14:57 ` Thomas Huth
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=a1001443-d2ef-732c-fa26-cfa7b88b8e1a@redhat.com \
--to=thuth@redhat.com \
--cc=anthony.perard@citrix.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).