On Fri, 2009-08-07 at 13:51 +0200, Arnd Bergmann wrote: > On Friday 07 August 2009, Mark McLoughlin wrote: > > slirp has started using VLANClientState::opaque and this has caused the > > kvm specific tap_has_vnet_hdr() hack to break because we blindly use > > this opaque pointer even if it is not a tap client. > > > > Add yet another hack to check that we're actually getting called with a > > tap client. > > > > [Needed on stable-0.11 too] > > > > Signed-off-by: Mark McLoughlin <mar...@redhat.com> > > Jens and I discovered the same bug before, but then we forgot about > sending a fix (sorry). Your patch should work fine as a workaround, > but I wonder if it is the right solution. > > The abstraction of struct VLANClientState is otherwise done through > function pointers taking the VLANClientState pointer as their > first argument. IMHO a cleaner abstraction would be to do the same > for tap_has_vnet_hdr(), like the patch below, and similar for > other functions passing 'opaque' pointers.
Indeed, but using vc->vlan->first_client is a great big hole in the abstraction as it is. The vnet_hdr code in qemu-kvm.git is a hack which we plan to (eventually) replace by allowing a nic to be paired directly with a backend. Your patch is fine, but I'd suggest since both are a hack we stick with mine since it'll reduce merge conflicts. Both hacks will go away eventually, anyway. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
