On Thu, Aug 06, 2009 at 06:08:27AM -0600, Gregory Haskins wrote: > Hi Michael, > > >>> On 8/6/2009 at 4:19 AM, in message <20090806081955.GA9752@xxxxxxxxxx>, > "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: > > On Mon, Aug 03, 2009 at 01:17:30PM -0400, Gregory Haskins wrote: > >> (Applies to v2.6.31-rc5, proposed for linux-next after review is complete) > > > > These are guest drivers, right? > > Yep. > > > Merging the guest first means relying on > > kernel interface from an out of tree driver, which well might change > > before it goes in. > > ABI compatibility is already addressed/handled, so even if that is true its not a problem. It is? With versioning? Presumably this: + params.devid = vdev->id; + params.version = version; + + ret = vbus_pci_hypercall(VBUS_PCI_HC_DEVOPEN, + ¶ms, sizeof(params)); + if (ret < 0) + return ret; Even assuming host even knows how to decode this structure (e.g. some other host module doesn't use VBUS_PCI_HC_DEVOPEN), checks the version and denies older guests, this might help guest not to crash, but guest still won't work. > > Would it make more sense to start merging with the host side of the project? > > Not necessarily, no. These are drivers for a "device", so its no > different than merging any other driver really. This is especially > true since the hypervisor is also already published and freely > available today, so anyone can start using it. The difference is clear to me: devices do not get to set kernel/userspace interfaces. This "device" depends on a specific interface between kernel and (guest) userspace. -- MST -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
