On Wed, 30 Nov 2011 15:12:43 +0200, Sasha Levin <levinsasha928@xxxxxxxxx> wrote: > On Wed, 2011-11-30 at 10:10 +1030, Rusty Russell wrote: > > On Mon, 28 Nov 2011 11:15:31 +0200, Sasha Levin <levinsasha928@xxxxxxxxx> wrote: > > > On Mon, 2011-11-28 at 11:25 +1030, Rusty Russell wrote: > > > > I'd like to see kvmtools remove support for legacy mode altogether, > > > > but they probably have existing users. > > > > > > While we can't simply remove it right away, instead of mixing our > > > implementation for both legacy and new spec in the same code we can > > > split the virtio-pci implementation into two: > > > > > > - virtio/virtio-pci-legacy.c > > > - virtio/virtio-pci.c > > > > > > At that point we can #ifdef the entire virtio-pci-legacy.c for now and > > > remove it at the same time legacy virtio-pci is removed from the kernel. > > > > Hmm, that might be neat, but we can't tell the driver core to try > > virtio-pci before virtio-pci-legacy, so we need detection code in both > > modules (and add a "force" flag to virtio-pci-legacy to tell it to > > accept the device even if it's not a legacy-only one). > > I was thinking more in the direction of fallback code in virtio-pci.c to > virtio-pci-legacy.c. > > Something like: > #ifdef VIRTIO_PCI_LEGACY > [Create BAR0 and map it to virtio-pci-legacy.c] > #endif > > So BAR0 isn't defined as long as legacy code is there, which makes > falling back to legacy pretty simple. But it's nicer to see the driver actually labelled "virtio-pci-legacy", and such a module. I'll code something up, see what it looks like. Cheers, Rusty. -- 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
