All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Anton Ivanov <anton.ivanov@kot-begemot.co.uk>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] RFC - best way to organize a multiprotocol transport?
Date: Fri, 21 Mar 2014 14:14:04 +0100	[thread overview]
Message-ID: <20140321131404.GA21862@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <532C0DE5.1090402@kot-begemot.co.uk>

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

  reply	other threads:[~2014-03-21 13:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-21 10:01 [Qemu-devel] RFC - best way to organize a multiprotocol transport? Anton Ivanov
2014-03-21 13:14 ` Stefan Hajnoczi [this message]
2014-03-21 14:06   ` Anton Ivanov
2014-03-21 15:27     ` Stefan Hajnoczi
2014-03-21 17:00       ` Anton Ivanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140321131404.GA21862@stefanha-thinkpad.redhat.com \
    --to=stefanha@redhat.com \
    --cc=afaerber@suse.de \
    --cc=anton.ivanov@kot-begemot.co.uk \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.