> +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."
Paul
--
To unsubscribe from thi
On Thu, 2009-02-12 at 16:26 +, 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
On Thursday 12 February 2009, Alex Williamson wrote:
> On Thu, 2009-02-12 at 16:26 +, 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 li
On Thu, 2009-02-12 at 17:05 +, Paul Brook wrote:
> On Thursday 12 February 2009, Alex Williamson wrote:
> > On Thu, 2009-02-12 at 16:26 +, Paul Brook wrote:
> > > > +static void virtio_net_vlan_client_added(void *opaque)
> > > >...
> > > > +static void virtio_net_vlan_client_removed(void *o
Alex Williamson wrote:
> They don't, but they do need to know whether a filter they previously
> applied successfully is no longer in place. If they don't know this,
> they have to assume the filter on the other side of the vlan is
> transient and always double check it with their own filtering, w
> - A device requests a filter and is told if the request is successful
> - On success the device may skip it's own filtering
> - If another vlan client is added, the following _must_ occur:
> - The "filterer" must clear (remove) the filter
> - The "filteree" must revert to using their own fi
Paul Brook wrote:
> > We could use a changed() function, but it would need to know the
> > direction of the change, which leads back to the same mechanics. If
> > there's a better way, please suggest it. Thanks,
>
> I still don't see why the device needs to know what's changed. The response
> s
On Friday 13 February 2009, Jamie Lokier wrote:
> Paul Brook wrote:
> > > We could use a changed() function, but it would need to know the
> > > direction of the change, which leads back to the same mechanics. If
> > > there's a better way, please suggest it. Thanks,
> >
> > I still don't see why
Paul Brook wrote:
> > Well, you do need some way to notify a client that the filter which
> > used to work has been removed because it's no longer available, for
> > example when migrating between host kernels.
>
> This is actually more evidence that the "add" and "remove" callbacks are
> bogus.
> > A simple "Something changed, please try your filter again" callback
> > automatically covers all these cases.
>
> It doesn't, if tap has no memory of how many clients require a filter.
I'm talking about a callback for devices requesting an inbound filter. Devices
implementing outgoing (device
Paul Brook wrote:
> > > A simple "Something changed, please try your filter again" callback
> > > automatically covers all these cases.
> >
> > It doesn't, if tap has no memory of how many clients require a filter.
>
> I'm talking about a callback for devices requesting an inbound
> filter. Device
> The callback you suggest for devices requesting an inbound filter will
> infinite-loop when there's two such devices on the same vlan bus,
> because each time the callback is called, that device will re-issue
> its filter request which triggers the callback on the other similar
> device. Back an
12 matches
Mail list logo
