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

Re: [Xen-devel] xen_disk qdevification (was: [PATCH 0/3] Performance improvements for xen_disk v2)

> -----Original Message-----
> From: Olaf Hering [mailto:olaf@xxxxxxxxx]
> Sent: 12 December 2018 09:00
> To: Kevin Wolf <kwolf@xxxxxxxxxx>
> Cc: Tim Smith <tim.smith@xxxxxxxxxx>; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>; qemu-block@xxxxxxxxxx; armbru@xxxxxxxxxx; qemu-
> devel@xxxxxxxxxx; Max Reitz <mreitz@xxxxxxxxxx>; Paul Durrant
> <Paul.Durrant@xxxxxxxxxx>; Anthony Perard <anthony.perard@xxxxxxxxxx>;
> xen-devel@xxxxxxxxxxxxxxxxxxxx
> 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 


> Olaf
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.