qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 17/40] job: Move BlockJobCreateFlags to Job


From: John Snow
Subject: Re: [Qemu-devel] [PATCH v2 17/40] job: Move BlockJobCreateFlags to Job
Date: Thu, 24 May 2018 13:46:38 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0


On 05/24/2018 04:17 AM, Kevin Wolf wrote:
> Am 24.05.2018 um 00:24 hat John Snow geschrieben:
>>
>>
>> On 05/18/2018 09:20 AM, Kevin Wolf wrote:
>>> +    job->auto_finalize = !(flags & JOB_MANUAL_FINALIZE);
>>> +    job->auto_dismiss  = !(flags & JOB_MANUAL_DISMISS);
>>
>> Job API might be a good chance to say "No, this is the default behavior
>> for this API."
>>
>> I don't know how possible this is, but could we remove these behavior
>> flags for jobs (but keep them for block jobs), and then any legacy block
>> job creation interfaces we have can enable/disable them as the user
>> requested,
>>
>> and the block job layer itself has hooks that persuade the core job
>> layer to automatically transition without user input, if appropriate.
>>
>> (Unless that happens later?)
> 
> That's really a question for job-create, which we don't have yet. I'm
> not sure whether job-create would expose those options, and if so, what
> the defaults would be.
> 
> I think auto-dismiss=false is a good default because the reason for
> having a manual job-dismiss is shared by all jobs (you want to be able
> to query the job result after it finished).
> 

Sounds good to me.

> auto-finalize is different. We introduced it to avoid surprise graph
> changes, but this implies that every job changes the block graph when it
> completes. This is obviously not true for non-block jobs. They might
> still commonly change something else that shouldn't be done as a
> surprise, but I am working right now on at least a single job type that
> doesn't do anything like that on completion (blockdev-create).
> 

I'll have to stay tuned.

> For now, I made it unconditionally auto-finalize=true and
> auto-dismiss=false without offering the options in QMP, but that's open
> for discussion.

Sure. I was wondering if we didn't want to change the internal API's
defaults around, but I guess that can happen whenever based on what the
QMP looks like.

> 
> Kevin
> 



reply via email to

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