On Sun, 2012-06-10 at 16:18 +0100, Ben Hutchings wrote: [...] > The problems I've found so far (by inspection): > > 1. The daemon leaks a file handle on every configuration update. Fixed by the attached 'tools-hv-fix-file-handle-leak.patch' > 2. It doesn't check for write failures, and it doesn't check correctly > for read failures. Fixed by the attached 'tools-hv-check-for-read-write-errors.patch'. > 3. It stores state in /var/opt/hyperv, which is only appropriate for > programs installed in /opt. This should be configurable at build time. Changed by the attached 'tools-hv-fix-var-subdirectory.patch', but not made configurable (because I don't see the need). > 4. The protocol between driver and daemon does not appear to be stable. > Do they need to be upgraded in lockstep, or will either be backward- > compatible with older versions of the other? Please answer this. > 5. The daemon uses incorrect types for strings, resulting in a large > number of compiler warnings when building with 'gcc -Wall' (which is > generally good practice). Fixed by the attached 'tools-hv-fix-string-types.patch'. > 6. When and how should the daemon be started? There is no init script > (or upstart job) provided, either in the linux source or the Ubuntu > packaging. I downloaded the Linux Integration Services from <https://www.microsoft.com/en-us/download/details.aspx?id=28188> and found an init script in that. I also found <https://launchpad.net/ubuntu/+source/hv-kvp-daemon-init>, but this is not useful for Debian (we don't use upstart by default). > [Less important:] > 7. There is no Makefile, and the one added by Ubuntu is incorrect (make > install doesn't respect $(DESTDIR)). Still TBD. > 8. The daemon doesn't detect or parse the OS release correctly (even, so > far as I can see, on the distributions which it has explicit support > for). Fixed by the attached 'tools-hv-parse-etc-os-release.patch'. > 9. Permissions of S_IRUSR | S_IWUSR | S_IROTH (octal 604) make no sense. Fixed by the attached 'tools-hv-fix-permissions.patch'. > According to the manual page, 'This pairing allows the Hyper-V host to > pass configuration information (such as IP addresses) to the guest...' > but I don't see any sign that the daemon actually applies any > configuration. Is this intended to be done by some other 'guest tool' > distributed by Microsoft? Is that the reason for (3) and/or (6)? I'm assuming this is not the case, since the package I downloaded from MS did not contain any extra tools. So the manual page should probably be fixed too. I have *not* tested these changes beyond actually compiling, as I don't have a Hyper-V installation on which to test. Would you be able to test a binary package, or provide remote access to a suitable VM? It is still important that I get an answer to question 4. Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure.
Attachment:
tools-hv-patches.tar.gz
Description: application/compressed-tar
Attachment:
signature.asc
Description: This is a digitally signed message part