[Libguestfs] [virt-v2v RFC wave 2 03/10] convert/windows_virtio: restrict the warning with virtio-win.iso absent

[Laszlo Ersek]

On 11/06/21 18:40, Richard W.M. Jones wrote:
> On Sat, Nov 06, 2021 at 04:45:33PM +0100, Laszlo Ersek wrote:
>> On 11/02/21 09:52, Richard W.M. Jones wrote:
>>> I hesitate to submit patches for parts of the code where someone else
>>> is working since it creates a mess of conflicts, but would you like me
>>> to have a go at a patch for removing rcaps?
>>
>> Yes, absolutely; please go ahead and do it. I'm happy to rebuild my
>> patches on top of that -- I won't really approach the new situation as a
>> rebase, with conflicts to resolve, but as a series of potential
>> individual cherry picks, and reimplementations from zero.
> 
> I'll have a go at this, probably not going to be til Monday though.

I'm done with the raw rebase (without handling the OVF, JSON and
OpenStack outputs).

I've noticed that the cirrus device model has become effectively dead
too, meaning both the Cirrus constructor of type "guestcaps_video_type",
and the Source_Cirrus constructor of type "source_video".

If I remove those constructors, then each type will be left with a
single constructor -- "guestcaps_video_type" will only have Standard_VGA
(not parametric), and "source_video" will have only "Source_other_video
of string" (basically: a string).

This suggests that "guestcaps_video_type" should be eliminated
altogether (its occurrences could be replaced by constants), and that
"source_video" should be replaced by plain "string".

(I'll go further: "source_video" looks unused beyond "--print-source",
so it could be removed fully as well!)

Should I attempt doing this at the end of the series?

I'm asking now because these simplifications look technically possible
even before I start investigating the "OVF video device" topic. I expect
the latter to turn into an infinite mess, so if I can (or should) tack
the cirrus cleanup patches to the end of my series, I figure I'd like to
do that first.

Thanks!
Laszlo