qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Xen-devel] xen_disk qdevification (was: [PATCH 0/3] Pe


From: Paul Durrant
Subject: Re: [Qemu-block] [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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]