Re: [Xen-devel] [PATCH 09 of 10] xenalyze: add a basic plugin infrastructure

[David Vrabel <david.vrabel@xxxxxxxxxx>]

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<david.vrabel@xxxxxxxxxx>
> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel