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

[Cyrill Gorcunov]

On Fri, Mar 14, 2014 at 05:47:26PM +0400, Pavel Emelyanov wrote:
> >>
> >> Why is the 2nd approach better?
> > 
> > No, with second approach plugin writer can use any name he likes for the hook, but define the hook as
> > 
> >      | static int dump_ext_file(int fd, int id)
> >      | {
> >      |	pr_info("dump_ext_file: fd %d id %d\n", fd, id);
> >      |	return 0;
> >      | }
> >      |
> >      | CR_PLUGIN_REGISTER_HOOK(CR_PLUGIN_HOOK__DUMP_EXT_FILE, dump_ext_file)
> 
> OK, why not do it simpler, by introducing a helper
> 
> #define CR_PLUGIN_REGISTER_HOOK(type, fn, args)		\
> static int type(args)					\
> {							\
> 	return fn(args);				\
> }
> 
> and use it
> 
> static int my_dump_fn()
> {
> }
> 
> CR_PLUGIN_REGISTER_HOOK(dump_ext_unix_sk, my_dump_fn, (int fd, int id))
> 
> ?

Yeah, we can do that, I'll update the series and resend if this is the
only issue and the rest of team agreed. Andrey?

> > 
> > have you read changelog? Same is done by linux modules for init and exit functions,
> 
> In the kernel this is done to properly resolve init/exit locations of such
> and initcalls, not just for neat names.

I know, but neat names a bonus still.

	Cyrill