[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Xen-devel] xen_disk qdevification (was: [PATCH 0/3] Pe
From: |
Paul Durrant |
Subject: |
Re: [Qemu-devel] [Xen-devel] xen_disk qdevification (was: [PATCH 0/3] Performance improvements for xen_disk v2) |
Date: |
Wed, 12 Dec 2018 09:22:23 +0000 |
> -----Original Message-----
> From: Olaf Hering [mailto:address@hidden
> Sent: 12 December 2018 09:00
> To: Kevin Wolf <address@hidden>
> Cc: Tim Smith <address@hidden>; Stefano Stabellini
> <address@hidden>; address@hidden; address@hidden; qemu-
> address@hidden; Max Reitz <address@hidden>; Paul Durrant
> <address@hidden>; Anthony Perard <address@hidden>;
> address@hidden
> Subject: Re: [Xen-devel] xen_disk qdevification (was: [PATCH 0/3]
> Performance improvements for xen_disk v2)
>
> On Fri, Nov 02, Kevin Wolf wrote:
>
> > A while ago, a downstream patch review found out that there are some QMP
> > commands that would immediately crash if a xen_disk device were present
> > because of the lacking qdevification. This is not the code quality
> > standard I envision for QEMU. It's time for non-qdev devices to go.
>
> Do you have that backwards by any chance? IMO the presence of assert()
> contributes to bad code quality, not the drivers that trigger those
> asserts. It is bad enough that two QEMU releases went out while being in
> bad shape.
>
> Anyway, hopefully Paul or whoever will find the time and energy to
> convert the code at some point.
It's done. V4 of my series has acks from the Xen maintainers. I think it needs
some other acks from block maintainers but it's basically ready to go in (and
I've verified that no assert is tripped by xentop at least). Also I hope to
post the re-based patches from Tim (one of which fixes the memory issues) later
today.
Paul
>
> Olaf