From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38942) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQzH9-00006R-Qb for qemu-devel@nongnu.org; Fri, 21 Mar 2014 09:14:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQzH3-0003zw-Rv for qemu-devel@nongnu.org; Fri, 21 Mar 2014 09:14:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12299) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQzH3-0003y8-Jo for qemu-devel@nongnu.org; Fri, 21 Mar 2014 09:14:13 -0400 Date: Fri, 21 Mar 2014 14:14:04 +0100 From: Stefan Hajnoczi Message-ID: <20140321131404.GA21862@stefanha-thinkpad.redhat.com> References: <532C0DE5.1090402@kot-begemot.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <532C0DE5.1090402@kot-begemot.co.uk> Subject: Re: [Qemu-devel] RFC - best way to organize a multiprotocol transport? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anton Ivanov Cc: Paolo Bonzini , qemu-devel@nongnu.org, Andreas =?iso-8859-1?Q?F=E4rber?= On Fri, Mar 21, 2014 at 10:01:09AM +0000, Anton Ivanov wrote: > I am wondering how to re-organize these so that the code is not > duplicated across 3-4 drivers as well as allow people to easily add more > encaps in the future. > One way will be to pull all common routines into a common file and have > different option sets and different inits. Another will be to have > "encaps" as a parameter to a common driver. This, however will make all > params optional making option parsing ugly and prone to coding errors. The user-visible command-line options will be different (e.g. L2TPv3 rx cookie). Therefore, I suggest having independent user-facing netdevs. In other words, give each encapsulation its own NetdevFooOptions in qapi-schema.json and a net_init_foo() function. qemu -netdev gre,... -netdev l2tp,... The actual implementation could be shared. Maybe something like: net/encap.c - common code for encapsulation/tunneling net/encap.h - header used by L2TPv3 and GRE net/l2tpv3.c - L2TPv3 specific code and net_init_l2tp() net/gre.c - GRE specific code and net_init_gre() How exactly the net/encap.h interface looks is something you need to decide based on the details. Does it make sense to have a common NetdevEncap struct that can be embedded and has function pointers for protocol-specific hooks? Or is it better to just provide common functions and let protocols use them as a library? It's up to you. Stefan