On 6/16/20 5:41 PM, Eric Blake wrote:
> 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?
>
It should be pretty trivial (I think) to just rebase the bitpop job on
top of mainline QEMU without needing this, I'd recommend doing that.
I started porting the job runner to the standalone qemu package instead
and it's going to take me longer to do that than it would be to just not
use this patchset for the bitpop test.
If you ping me on IRC tomorrow (Sorry) I can wean the dependency myself.
--js