On 12/02/21 11:27, Richard W.M. Jones wrote:
On Thu, Dec 02, 2021 at 10:13:29AM +0000, Richard W.M. Jones wrote:
> On Thu, Dec 02, 2021 at 11:09:15AM +0100, Laszlo Ersek wrote:
>> On 12/02/21 10:46, Laszlo Ersek wrote:
>>> Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1961107
>>> v1:
https://listman.redhat.com/archives/libguestfs/2021-November/msg00150.html
>>>
>>> Please see the v2 changes (relative to the v1 posting) in the Notes
>>> sections of the individual patches.
>>>
>>> The v2v QE team at Red Hat has helped a lot with testing (see again the
>>> per-patch v2 notes); the only part that still needs good test results is
>>> the OVF output.
>>
>> Pushed as commit range ddc96fc5aae4..dbbdd4c20a6a (per prior discussion
>> with Rich).
>
> Thanks for pushing this. I did also review the series just now, but
> had no comments, it all looks sensible to me.
I pushed my refactoring on top. This removes the separate helper-*
programs which were an interesting experiment but not in the end very
useful. The longer story behind this is described in this commit
message:
https://github.com/libguestfs/virt-v2v/commit/5609c73c615a8f12c5c6d50908b...
The input and output modules use a new-ish (< 10 years) feature called
first class modules. I found this tutorial useful:
https://dev.realworldocaml.org/first-class-modules.html
Yes, I noticed, because I pulled master very soon after, anyways. It
made me chuckle because the OCaml book I use (drafted by one of the
authors of Real World OCaml, in 2008) explains in detail why modules are
not first class. :)
(The introductory paragraph at the above link sounds a lot like a
rehashing of section "12.2.1 Modules are not first-class" in the 2008 book.)
We're not using all the features there by any means, just a single
feature which allows us to assign the OCaml Input.* or Output.* module
to a name based on the -i/-o flag. You'll see what I mean in these
two commits:
https://github.com/libguestfs/virt-v2v/commit/724ecb5e887e5b71db836143ec0...
https://github.com/libguestfs/virt-v2v/commit/4de22686fe74e1711efd9bfed3f...
... OK, I have a from-orbit understanding of it, I think.
My next steps today are:
- Do an upstream release (1.45.92)
- Do a Fedora release
- Do a RHEL 9 rebase/release
- Split up the large input/input.ml and output/output.ml files into
separate files. Now we have the modules we no longer need these to
be single huge files, and having smaller files should make the code
easier to navigate and each mode self-contained.
I should read a few more chapters in the book...
Thanks!
Laszlo