[CRIU] [PATCH 2/3] plugin: Rework plugins API, v2

Pavel Emelyanov xemul at parallels.com
Fri Mar 14 05:50:21 PDT 2014


On 03/14/2014 04:38 PM, Cyrill Gorcunov wrote:
> On Fri, Mar 14, 2014 at 04:27:59PM +0400, Pavel Emelyanov wrote:
>> On 03/13/2014 06:55 PM, Cyrill Gorcunov wrote:
>>> On Thu, Mar 13, 2014 at 06:41:17PM +0400, Cyrill Gorcunov wrote:
>>>>
>>>> Here we define new api to be used in plugins.
>>
>>> The idea behind is to not limit plugins authors with names
>>> of functions they might need to use for particular hook.
>>
>> Is that the only thing we're trying to address?
>> Why do we consider this as problem?
> 
> Because it's more convenient to work with. Look, with new plugin API if
> you introduce new hook entry you need
> 
> 1) Add new enum CR_PLUGIN_HOOK__
> 2) Specify arguments for hook as
> 
> 	DECLARE_PLUGIN_HOOK_ARGS(CR_PLUGIN_HOOK__DUMP_UNIX_SK, int fd, int id);

So before the patches the plugin writer had to write

   static int dump_ext_unix_sk(int fd, int id)

where the "dump_ext_unix_sk" is constant name. After the patch, the writer has to write

   DECLARE_PLUGIN_HOOK_ARGS(CR_PLUGIN_HOOK__DUMP_UNIX_SK, int fd, int id)

were the whole "DECLARE_PLUGIN_HOOK_ARGS(CR_PLUGIN_HOOK__DUMP_UNIX_SK" string
is constant (and in capitals).

Why is the 2nd approach better?

> 
> that's all.
> 
> You can easily grep for all plugins entries in criu, because the all
> run as a call to @run_plugins helper.
> 
> Again, this is my _personal_ opiniton, if any objection here lets
> drop the series.
> .
> 




More information about the CRIU mailing list