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

[Andrew Vagin]

On Wed, Mar 12, 2014 at 04:04:10PM +0400, Cyrill Gorcunov wrote:
> On Wed, Mar 12, 2014 at 03:47:02PM +0400, Andrew Vagin wrote:
> > On Wed, Mar 12, 2014 at 03:05:06PM +0400, Cyrill Gorcunov wrote:
> > > On Wed, Mar 12, 2014 at 02:57:27PM +0400, Andrew Vagin wrote:
> > > > > +
> > > > > +/*
> > > > > + * Strictly speaking this CR_PRIV_CHAIN_ENTRY_SIZE stands for
> > > > > + * double linked list entry size.
> > > > > + */
> > > > > +#define CR_PRIV_CHAIN_ENTRY_SIZE	(2 * sizeof(void *))
> > > > > +#define CR_PRIV_SIZE			((CR_PLUGIN_HOOK__MAX) * CR_PRIV_CHAIN_ENTRY_SIZE + \
> > > > > +					 CR_PRIV_CHAIN_ENTRY_SIZE + 16 * sizeof(void *))
> > > > 
> > > > What is a magic 16 here?
> > > 
> > > 16 cells for further use if ever needed.
> > > 
> > > > > +typedef struct {
> > > > > +	const char		*name;
> > > > > +	int			(*init)(void);
> > > > > +	void			(*exit)(void);
> > > > > +	unsigned int		version;
> > > > > +	unsigned int		max_hooks;
> > 
> > struct {
> > 	int (*func)();
> > 	cr_plugin_desc_t *next; /* Don't touch this field from plugins */
> > } hooks[CR_PLUGIN_HOOK__MAX];
> > 
> > Can we use this code and remove the private blob?
> 
> Well, sure we can, but I tried to escape exposing internal plugins data.
> IOW, the @private should look for users as some binary data which should
> not touched by plugin code itself and reserved for internal criu usage.
> 
> At the moment I use @private to keep
> 
> +typedef struct {
> +	struct list_head	list;
> +	void			*dlhandle;
> +	struct list_head	link[0];
> +} __packed plugin_desc_t;
> 
> there.

Can we ask criu to allocate cr_plugin_desc_t? In this case we can
completly hide private from users and avoid problems with supporting
backward compatibility. What do you think about this way?