qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-block] [RFC PATCH 0/7] BlockBackends, nodes and g


From: John Snow
Subject: Re: [Qemu-devel] [Qemu-block] [RFC PATCH 0/7] BlockBackends, nodes and guest devices
Date: Tue, 12 Jul 2016 13:11:59 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1


On 07/12/2016 04:14 AM, Kevin Wolf wrote:
> Am 12.07.2016 um 02:13 hat John Snow geschrieben:
>> No oxford comma in the subject? :)
> 
> It's already hard enough to keep the German comma rules straight and
> avoid confusing the pre-reform rules with the post-reform ones. I don't
> think I should bother with the comma rules of a language where even the
> native speakers can't seem to agree. :-)
> 
> (But thanks, I wasn't aware that this disagreement even exists before
> reading it up now.)
> 

Only teasing, of course.

(I was searching for this thread via the patches tool and used the
oxford comma myself and had to figure out why it wasn't showing up. Not
a real critique!)

>> On 06/23/2016 10:36 AM, Kevin Wolf wrote:
>> 1-4: Reviewed-by: John Snow <address@hidden>
>> 5: Looks good, pending discussion on the right thing to name "ID", but
>> the patch itself looks perfectly cromulent.
>> 6: Causes only a minor regression in 030 due to different error class
>> names, but R-B otherwise.
>> 7: No opinion. Looks sane mechanically but I don't know enough about
>> core block properties to have a meaningful opinion. "ACK."
> 
> Thanks!
> 
>> For non-RFC, some new iotests would be good.
> 
> Anything specific you have in mind to be tested?
> 

Just basic usage that demonstrates the new API for any converted
commands, and something that uses the new WCE options.

Would like to see the code in patch one tested at least lightly, to
prevent us from goofing up the assertions in the cleanup in the future.

> The problem with everything related to devices is that it requires
> running a qemu process and most likely a specific machine type. But I
> guess we can just skip some tests if we don't have the right binary.
> 
> Kevin
> 

Wishing more and more for python-based qtests. (ptests !?)

--js



reply via email to

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