> - 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 filtering > - If a vlan client is removed, the following _may_ occur: > - vlan clients are notified that they may retry their filter >.. > The added()/removed() interface feels like the right solution to this. I think your analysis is fundamentally flawed. Firstly I'm not sure the above holds when going between 1 and 2 clients on a vlan. Even ignoring that, you are making implicit assumptions about when a filter will succeed. If these assumptions are broken (which seems likely if we ever implement filtering with more than 2 devices on a vlan) they you'll get subtle breakage in every single user of the API. > 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 should always be the same: Request a filter, and see if it works. Paul -- 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
