[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