From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 3/4] qemu:virtio-net: Add support for qemu_vlan_rxfilter Date: Fri, 13 Feb 2009 16:00:39 +0000 Message-ID: <20090213160039.GG18471@shareable.org> References: <20090210212841.9760.96780.stgit@kvm.aw> <200902121705.54473.paul@codesourcery.com> <1234462898.25178.277.camel@bling> <200902131240.21150.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, Alex Williamson To: qemu-devel@nongnu.org Return-path: Received: from mail2.shareable.org ([80.68.89.115]:42785 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752222AbZBMQAn (ORCPT ); Fri, 13 Feb 2009 11:00:43 -0500 Content-Disposition: inline In-Reply-To: <200902131240.21150.paul@codesourcery.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. Or implement reliable filtering in the infrastructure which relays packets internally in QEMU, so that each client can request a filter and it always works, and the tap driver can tell the QEMU infrastructure when kernel filtering is working and not, but each client doesn't need to know that. -- Jamie