qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v3 01/14] blockjobs: add manual property


From: John Snow
Subject: Re: [Qemu-devel] [RFC v3 01/14] blockjobs: add manual property
Date: Mon, 29 Jan 2018 12:34:36 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2


On 01/29/2018 11:59 AM, Kevin Wolf wrote:
> Am 27.01.2018 um 03:05 hat John Snow geschrieben:
>> This property will be used to opt-in to the new BlockJobs workflow
>> that allows a tighter, more explicit control over transitions from
>> one runstate to another.
>>
>> Signed-off-by: John Snow <address@hidden>
> 
>> diff --git a/include/block/blockjob.h b/include/block/blockjob.h
>> index 00403d9482..b94d0c9fa6 100644
>> --- a/include/block/blockjob.h
>> +++ b/include/block/blockjob.h
>> @@ -141,6 +141,11 @@ typedef struct BlockJob {
>>       */
>>      QEMUTimer sleep_timer;
>>  
>> +    /* Set to true when management API has requested 2.12+ job lifetime
>> +     * management semantics.
>> +     */
>> +    bool manual;
> 
> Wouldn't it make more sense to describe what "2.12+ job lifetime
> management semantics" actually are? Maybe then it would be easy to find
> a more specific name, too, like manual_completion.
> 

Sure. At the time I wrote it, I wasn't sure what they were. Maybe I'll
find out after the review; but I'll make a note to document it here.

> In fact, I wonder if the opposite flag wouldn't be nicer, i.e. having a
> bool auto_completion (or finalization or whatever that extra step was
> called in the final draft), defaulting to true.
> 

I could do that, if you feel it'd be more readable. In terms of style I
tend to prefer new additions default to false as that feels more
permanently reliable, but it's only a preference.

> Also, the comment style in this header is already pretty messed up, but
> I think the styles that were originally meant to be used there, are
> 
>     /** this one for single lines */
> 
>     /**
>      * and this one if things get a bit longer
>      * and you need multiple lines.
>      */
> 
> Kevin
> 

I can do a fixup and make 'em consistent.



reply via email to

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