Hi all, I've done the initial work for a new library, libosinfo (better name recommendations appreciated). This library will provide OS meta data for use in virt applications, replacing the dictionary we currently keep in virtinst. This is based off of a post by Dan Berrange: https://www.redhat.com/archives/et-mgmt-tools/2009-March/msg00028.html The code can be fetched with: git clone http://fedorapeople.org/~crobinso/osinfo/.git Check out the TODO list for a simple roadmap. http://fedorapeople.org/~crobinso/osinfo/TODO The public API looks like: /** * Values stored in the OS dictionary */ enum _os_value_type { OS_VALUE_NAME = 1, /** Human readable family/distro... name */ OS_VALUE_MEDIA_INSTALL_URL, /** URL to an install tree */ }; typedef enum _os_value_type os_value_t; int os_init(); void os_close(); int os_find_families (char ***list); int os_find_distros (const char *parent_id, char ***list); int os_find_releases (const char *parent_id, char ***list); int os_find_updates (const char *parent_id, char ***list); int os_lookup_value (os_value_t value_type, const char *os_id, char **value); The unique identifier for each distro is its 'id', which is a simple human readable string, similar to values we use for virt-install --os-variant today. The user will ask the API for available families/distros/releases/updates, which will return a list of ids. We then pass an id to os_lookup_value to actually retrieve data. The family/distro/... separation will likely be removed pretty soon, in favor of an arbitrary hierarchy, where every OS can have child OSes: no doubt hardcoding the family/distro/... split would come back to bite us in the ass. As an example, the following code will list the 'Name' of every id at the'family' level, where name is full name of the OS (id = rhel5.3, name = Red Hat Enterprise Linux 5.3): char *value = NULL; char **namelist = NULL; int i, num_fams; if (os_init() < 0) goto error; if ((num_fams = os_list_families(&namelist)) < 0) goto error; for (i = 0; i < num_fams; ++i) { if (os_lookup_value(OS_VALUE_NAME, namelist[i], &value) < 0) goto error; printf("%s\n", value); free(value); } error: free(namelist); free(value); os_close(); There is a simple tool called 'osinfo-tool' which allows listing an ASCII repr of the OS hierarchy, and listing all values for an individual id (which is pretty sparse at the moment since most of these values haven't been filled in yet). So, things that I'm interested in feedback on: - How do we expect apps to list OS choices? Currently, virt-manager lists type (linux, windows, unix, etc.) and associated distros (Fedora 8, RHEL4, Debian Lenny, etc.). The linux/windows/unix info isn't represented in the xml (should it be?) so the best way seems to be: Distro | --> Release | --> Update Ex. RHEL | -> RHEL5 | -> 5.0 5.1 5.2 If we do away with the family/distro/... distinction, the user won't have much choice in the matter, but the 'family' concept (e.g. value of 'Red Hat') isn't very useful to expose to a user. - How should we handle derivatives like Scientific Linux + CentOS: should we expect users to understand they are based on RHEL, or give them explicit IDs? - Querying for device values (supported buses, models, etc.). Dan's original proposal talks about this; to recommend a default with the best chance of actually working, we need to know: - OS being installed - Virt type ('hvm' vs. 'xen') - Guest Architecture (i386, x86_64, ...) - Hypervisor (kvm, qemu, xen, vbox, ...) - Hypervisor version - Libvirt version We would need to find the intersection of what the OS, the hypervisor, and libvirt support, and return what we decide is the best choice. How to expose this in the API? We could simply have one long function os_lookup_device_value(char *os_id, char *virt_type, char *arch, ...) It works, but its pretty tedious, and I'm afraid that we would need even more info to make a correct choice in the future, and the above isn't flexible. We may also need some of the above info for other values (ACPI/APIC settings, returning a proper install url may depend on arch). Any suggestions? - os_init and os_close: Any better ideas for this? os_init just parses the xml document, os_close frees it. We could run os_init with the first API call, but I think that makes it less clear that the user would then need to call os_close(). Any feedback appreciated. Thanks, Cole _______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
