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 the device needs to know what's changed. The > > response should always be the same: Request a filter, and see if it > > works. > > 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. My point is that we're allowing the filter to fail for arbitrary reasons. Once you assume this, trying to be clever is just going to catch you out when we encounter a case you didn't think of. A simple "Something changed, please try your filter again" callback automatically covers all these cases. It may be that in some cases qemu already knows the filter is going to fail. However these events are rare (i.e. not performance critical) so it's far simpler to just use the same callback and have the device try anyway. 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
