From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LY0jx-0000kK-Iq for qemu-devel@nongnu.org; Fri, 13 Feb 2009 11:18:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LY0jt-0000k7-4Z for qemu-devel@nongnu.org; Fri, 13 Feb 2009 11:18:08 -0500 Received: from [199.232.76.173] (port=57009 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LY0js-0000k4-V7 for qemu-devel@nongnu.org; Fri, 13 Feb 2009 11:18:04 -0500 Received: from mx20.gnu.org ([199.232.41.8]:33966) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LY0js-0000BE-N5 for qemu-devel@nongnu.org; Fri, 13 Feb 2009 11:18:04 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LY0jq-0000sJ-Jr for qemu-devel@nongnu.org; Fri, 13 Feb 2009 11:18:02 -0500 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 References: <20090210212841.9760.96780.stgit@kvm.aw> <200902131240.21150.paul@codesourcery.com> <20090213160039.GG18471@shareable.org> In-Reply-To: <20090213160039.GG18471@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902131617.54616.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kvm@vger.kernel.org, Alex Williamson 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