On Mon, 2012-05-14 at 23:21 +0100, Ben Hutchings wrote: > On Mon, May 14, 2012 at 08:33:23PM +0000, Mike Sterling wrote: [...] > > We've done a lot of work with Andy Whitcroft at Canonical to get the > > drivers integrated into Ubuntu 12.04 and higher. What we'd like to > > discuss is doing the same thing for Debian. > > > > What would be the best way to start or discuss this effort? > > The drivers were already updated (in 3.2.15-1). > > I have a to-do item to look at tools/hv and build those tools from > the linux-tools source package, but it wouldn't hurt for you to open a > bug report requesting it. If you can provide a patch then that would > make it a lot easier to fix. > > Currently the linux-tools source package in Debian builds binary > packages that are specific to upstream kernel versions > (linux-kbuild-3.2, linux-tools-3.2), I assume tools/hv is not > version-specific and therefore it would belong in a new package, say, > 'linux-tools-common' (*not* 'linux-tools', which somewhat confusingly > is a meta-package). So I've had a proper look at tools/hv now, and I'm not very impressed. The problems I've found so far (by inspection): 1. The daemon leaks a file handle on every configuration update. 2. It doesn't check for write failures, and it doesn't check correctly for read failures. 3. It stores state in /var/opt/hyperv, which is only appropriate for programs installed in /opt. This should be configurable at build time. 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? 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). 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. [Less important:] 7. There is no Makefile, and the one added by Ubuntu is incorrect (make install doesn't respect $(DESTDIR)). 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). 9. Permissions of S_IRUSR | S_IWUSR | S_IROTH (octal 604) make no sense. 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)? Ben. -- Ben Hutchings The program is absolutely right; therefore, the computer must be wrong.
Attachment:
signature.asc
Description: This is a digitally signed message part