On Thursday 12 February 2009, Alex Williamson wrote: > On Thu, 2009-02-12 at 16:26 +0000, Paul Brook wrote: > > > +static void virtio_net_vlan_client_added(void *opaque) > > >... > > > +static void virtio_net_vlan_client_removed(void *opaque) > > > > Why are these two different? > > > > It looks like what you really want is a callback for "Something changed, > > and you need to reset your MAC filter." > > I think we'd end up with a race if we only had one callback. For > instance if "change" was the result of a vlan client being removed, the > tap would clear the filter and the nic would try to install a filter. > The results would be different based on the calling order.
In that case either your implementation or your abstraction is wrong. Devices shouldn't need to know or care why a filter failed to apply. I'm not sure what you mean by "the tap would clear the filter". You have three options: - Devices request a filter, and that request may fail. qemu notifies the device when it needs to retry the filter. It doesn't make any difference whether we think we just broke the old filter, or we think a previously failed filter may succeed now, the device response is the same: Try to set a filter and see if it works. This is what I assume you're trying to implement. - Implement reliable filters. The device requests a filter once[1]. qemu makes sure that filter is always honored. - Devices request a filter once. qemu remembers what that filter is, and notifies the device if/when that filter becomes active/inactive. Paul [1] once == every time the filter set changes. -- 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
