search for: libosinfo_util

...bosinfo interface v2v: try to get windows driver files from libosinfo m4/guestfs-v2v.m4 | 3 + v2v/Makefile.am | 9 +- v2v/libosinfo-c.c | 221 ++++++++++++++++++++++++++++++++++++++++ v2v/libosinfo.ml | 52 ++++++++++ v2v/libosinfo.mli | 47 +++++++++ v2v/libosinfo_utils.ml | 34 +++++++ v2v/libosinfo_utils.mli | 26 +++++ v2v/windows_virtio.ml | 63 +++++++++++- 8 files changed, 450 insertions(+), 5 deletions(-) create mode 100644 v2v/libosinfo-c.c create mode 100644 v2v/libosinfo.ml create mode 100644 v2v/libosinfo.mli create mode 100644 v2v/libosinfo_...

...libosinfo interface v2v: try to get windows driver files from libosinfo m4/guestfs-v2v.m4 | 3 + v2v/Makefile.am | 9 +- v2v/libosinfo-c.c | 237 ++++++++++++++++++++++++++++++++++++++++ v2v/libosinfo.ml | 53 +++++++++ v2v/libosinfo.mli | 48 ++++++++ v2v/libosinfo_utils.ml | 34 ++++++ v2v/libosinfo_utils.mli | 26 +++++ v2v/windows_virtio.ml | 78 ++++++++++++- 8 files changed, 483 insertions(+), 5 deletions(-) create mode 100644 v2v/libosinfo-c.c create mode 100644 v2v/libosinfo.ml create mode 100644 v2v/libosinfo.mli create mode 100644 v2v/libosinfo_...

...se. > > Hm it is never freed? Wouldn't that result in actual leaks, since > OsinfoDb_t_finalize (g_object_unref'ing the OsinfoDb) wouldn't be > called? I was thinking because of this: https://github.com/libguestfs/virt-v2v/blob/cc294b7735dda467179b93a061d3631ac3547f26/v2v/libosinfo_utils.ml#L24 which IIUC will allocate a DB (on first access) but it is never released. (Note: I'm not saying this code is wrong) > > It could be that to express > > this properly we'd need to expose (db, os) tuples to the OCaml garbage > > collector. > > I thought abo...

...freed? Wouldn't that result in actual leaks, since > > OsinfoDb_t_finalize (g_object_unref'ing the OsinfoDb) wouldn't be > > called? > > I was thinking because of this: > > https://github.com/libguestfs/virt-v2v/blob/cc294b7735dda467179b93a061d3631ac3547f26/v2v/libosinfo_utils.ml#L24 > > which IIUC will allocate a DB (on first access) but it is never > released. Oh this is interesting. I read in the documentation that custom blocks have tag Custom_tag, which is higher than No_scan_tag, and thus they aren't scanned by the GC. Indeed, even trying to Gc.fina...

...or the same architecture + * - the location of the drivers is a local directory + * + * Files that do not exist are silently skipped. + * + * Returns list of copied files. + *) +and copy_from_libosinfo g inspect destdir = + let { i_osinfo = osinfo; i_arch = arch } = inspect in + try + let os = Libosinfo_utils.get_os_by_short_id osinfo in + let driver = + List.find ( + fun { Libosinfo.architecture; location } -> + (* Ignore different architectures than the guest's. *) + if architecture <> arch then + false + else + try +...

...or the same architecture + * - the location of the drivers is a local directory + * + * Files that do not exist are silently skipped. + * + * Returns list of copied files. + *) +and copy_from_libosinfo g inspect destdir = + let { i_osinfo = osinfo; i_arch = arch } = inspect in + try + let os = Libosinfo_utils.get_os_by_short_id osinfo in + let drivers = os#get_device_drivers () in + (* + * Filter out drivers that we cannot use: + * - for a different architecture + * - non-pre-installable ones + * - location is an invalid URL, or a non-local one + *) + let drivers = + L...

Hi Pino: I've suppressed some OCaml and libosinfo valgrind errors in virt-v2v. The remaining valgrind errors are here: http://oirase.annexia.org/tmp/v2vvg/ They all seem to be basically the same. But I couldn't work out if these are expected leaks in the libosinfo code (in which case we should suppress them), or if they are actual bugs because we are missing a true destructor here: