From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 3/4] qemu:virtio-net: Add support for qemu_vlan_rxfilter Date: Fri, 13 Feb 2009 16:17:53 +0000 Message-ID: <200902131617.54616.paul@codesourcery.com> References: <20090210212841.9760.96780.stgit@kvm.aw> <200902131240.21150.paul@codesourcery.com> <20090213160039.GG18471@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Jamie Lokier , Alex Williamson , kvm@vger.kernel.org To: qemu-devel@nongnu.org Return-path: Received: from mail.codesourcery.com ([65.74.133.4]:42305 "EHLO mail.codesourcery.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751654AbZBMQSA (ORCPT ); Fri, 13 Feb 2009 11:18:00 -0500 In-Reply-To: <20090213160039.GG18471@shareable.org> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: 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