From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 09 of 10] xenalyze: add a basic plugin infrastructure Date: Thu, 7 Jun 2012 16:26:45 +0100 Message-ID: <4FD0C835.4070507@citrix.com> References: <794833ac346b80acbed5.1338462985@qabil.uk.xensource.com> <4FD08B04.30709@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FD08B04.30709@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 07/06/12 12:05, George Dunlap wrote: > On 31/05/12 12:16, David Vrabel wrote: >> Allow xenalyze to be include (at build time) plugins that can do >> per-record actions and a summary. These plugins can be in C or C++. >> >> The plugins entry points are in struct plugin and pointers to all the >> plugins linked in xenalyze are placed in a "plugin" section so >> plugin_init() can find them all. >> >> A new command line option (-p, --plugin=PLUGIN) is added to enable one >> or more plugins. >> >> A sample plugin (skeleton) is included (mostly because at least one >> plugin must be present for the build to work). >> >> Signed-off-by: David Vrabel > So what's the main motivation of having this plugin infrastructure? The > one plugin example you have ("batch-size", patch 10) seems simple enough > that it should be fairly straightforward to just add as an option, with > not much more boilerplate than C++ already requires. > > Looks like potential advantages may include: > * Ability to use C++ language (for those who care for such things) > * Ability to use STL for complex data structures > * Ability to add an option like the "batch-size" plugin in a concise, > self-contained way These are the main reasons. The last is the most important. > Potential disadvantages include: > * An extra O(N) loop on the hot path (where N = # of enabled plugins) > * For each enabled plugin, an extra full function call on the hot path; > and a C++ function at that, which (my prejudice tells me) is likely to > be more wasteful time and space-wise than a C function. I'd be surprised if these had any practical performance penalty but I'll collect some measurements. David