On 5/14/20 2:31 PM, John Snow wrote:
Nah, it's fine. I'll clean it up. This is pretty close to an RFC series
anyway, so I didn't really polish it.
(Or, I will try to clean it up. I probably won't work on it again in the
near term. I think I just wanted to see if this seemed useful in general
to people.
Ah, there isn't much missing for this series, though. We don't have to
wait for a fix-the-world series when we can incrementally improve
things.
Alright, I'll try to hit it halfway -- I spent some time thinking about
a "full" job running framework but ran into some dead-ends I wasn't too
happy with, and wasn't convinced this was a simplification of any kind.
Still, seeing part of the job running code get duplicated in 040 was a
motivation to try and provide some universal job-running monster that
would be extensible for nearly any task.
Unfortunately that complexity does generally make the calling sites look
worse, so I cooled off on the idea since.
So I did intend this as an RFC, because I'm not really 100% happy with
the design.
I noticed that the block-dirty-bitmap-populate series depends on this
one; is it going to be simpler for me to fix the few things that Kevin
pointed out here, or to wait for you to post a v5 of this series, or to
rewrite the iotest in that series to not depend on JobRunner after all?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org