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

[Cyrill Gorcunov]

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.