search for: osinfo_o

This patch series integrates libosinfo in virt-v2v to get the list of files for Windows from libosinfo, if possible. The actual data is still from virtio-win, just unpacked. Pino Toscano (3): build: require libosinfo v2v: add a minimal libosinfo interface v2v: try to get windows driver files from libosinfo m4/guestfs-v2v.m4 | 3 + v2v/Makefile.am | 9 +-

This patch series integrates libosinfo in virt-v2v to get the list of files for Windows from libosinfo, if possible. The actual data is still from virtio-win, just unpacked. Changes from v1: - adapt to use the priority in libosinfo 1.7.0+ - filter out non-pre-installable drivers - collect all the drivers matching the requirements, not just the first, sorting them by priority like libosinfo does

...ased. (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 about this, and according to knowledge this would be needed > only if we want osinfo_os objects alive even when the osinfo_db gets > "out of scope". Considering that the osinfo_db is kept basically > statically this should be fine. Right. I don't believe the current code is wrong, my concern is more about clearing up valgrind errors before the release. Rich. -...

...1.8.0 check is not done, as already covered by the check above) - */ -#if !IS_LIBOSINFO_VERSION(1, 7, 0) || !GLIB_CHECK_VERSION(2, 63, 3) -G_DEFINE_AUTOPTR_CLEANUP_FUNC(OsinfoList, g_object_unref) -#endif G_DEFINE_AUTOPTR_CLEANUP_FUNC(OsinfoOsList, g_object_unref) #endif @@ -157,7 +146,7 @@ v2v_osinfo_os_find_os_by_short_id (value dbv, value osv) CAMLlocal1 (rv); g_autoptr(OsinfoFilter) filter = NULL; g_autoptr(OsinfoOsList) os_list = NULL; - g_autoptr(OsinfoList) list = NULL; + OsinfoList *list; OsinfoOs *os; os_list = osinfo_db_get_os_list (OsinfoDb_t_val (dbv)); @@ -165,11 +1...

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:

...OsinfoDb_t_finalize (g_object_unref'ing the OsinfoDb) wouldn't be called? > It could be that to express > this properly we'd need to expose (db, os) tuples to the OCaml garbage > collector. I thought about this, and according to knowledge this would be needed only if we want osinfo_os objects alive even when the osinfo_db gets "out of scope". Considering that the osinfo_db is kept basically statically this should be fine. > BTW the informational string given here seems to be wrong - copy and > paste error? > > https://github.com/libguestfs/virt-v2v/blo...

...hat behaviour somehow? > > > It could be that to express > > > this properly we'd need to expose (db, os) tuples to the OCaml garbage > > > collector. > > > > I thought about this, and according to knowledge this would be needed > > only if we want osinfo_os objects alive even when the osinfo_db gets > > "out of scope". Considering that the osinfo_db is kept basically > > statically this should be fine. > > Right. > > I don't believe the current code is wrong, my concern is more about > clearing up valgrind e...