From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Lu8Tt-0004JO-F6
	for qemu-devel@nongnu.org; Wed, 15 Apr 2009 13:01:01 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Lu8To-0004Gu-If
	for qemu-devel@nongnu.org; Wed, 15 Apr 2009 13:01:00 -0400
Received: from [199.232.76.173] (port=44809 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Lu8To-0004Gm-BK
	for qemu-devel@nongnu.org; Wed, 15 Apr 2009 13:00:56 -0400
Received: from mx2.redhat.com ([66.187.237.31]:55165)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <markmc@redhat.com>) id 1Lu8Tn-0002G9-Lt
	for qemu-devel@nongnu.org; Wed, 15 Apr 2009 13:00:55 -0400
From: Mark McLoughlin <markmc@redhat.com>
In-Reply-To: <49E5E953.8060207@siemens.com>
References: <20090414172954.15035.73053.stgit@mchn012c.ww002.siemens.net>
	<20090414172954.15035.35711.stgit@mchn012c.ww002.siemens.net>
	<1239800979.4431.128.camel@blaa>  <49E5E953.8060207@siemens.com>
Content-Type: text/plain
Date: Wed, 15 Apr 2009 18:00:51 +0100
Message-Id: <1239814851.4431.147.camel@blaa>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 2/7] net: Add VLAN client cleanup handler
Reply-To: Mark McLoughlin <markmc@redhat.com>, qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: qemu-devel@nongnu.org

On Wed, 2009-04-15 at 16:04 +0200, Jan Kiszka wrote:
> Mark McLoughlin wrote:
>  
> >  - Rather than adding yet another param to new_vlan_client(), I just 
> >    initialize vc->cleanup after creating the client; another patch in
> >    my queue removes all callbacks to new_vlan_client() because as more
> >    are added it just gets terribly unwieldy.
> 
> Personally, I prefer a function-based API over, well, hacking the
> structures directly. The driver should not have to poke into its device
> descriptor.

I see this as similar to filing out a vtable. Perhaps it makes sense to
split the function pointers out into a separate struct.

>  Yes, this breaks existing code each time you add another
> callback, but this has the effect that you
>  a) normally think twice if you really need it before doing this,
>  b) likely enhance all users, and
>  c) that new users will find prominent information about this
>     (hopefully) useful callback.

The way I see it is that often when you're adding a new callback, you
don't want to require all users to implement it. Instead you make sure
there is a reasonable default behaviour for when the callback is NULL,
and only set it to non-NULL for the users that really need it.

Cheers,
Mark.