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 >