[CRIU] [PATCH 2/3] plugin: Rework plugins API
Cyrill Gorcunov
gorcunov at gmail.com
Wed Mar 12 04:05:06 PDT 2014
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;
> > + void *hooks[CR_PLUGIN_HOOK__MAX];
> > + size_t priv_size;
> > +
> > + /*
> > + * @private is CRIU plugin engine private field,
> > + * don't ever modify inside plugin code!
> > + *
> > + * Also if this structure need to be extended
> > + * put new members _AFTER_ the @private field.
> > + */
> > + char private[CR_PRIV_SIZE];
>
> How we are going to support its backward compatibility in a future?
By version + max_hooks tuple. If we ever change API so that
new format won;t be compatible with new one -- we always
can detect it by comparing @version and wrap data with
some new descriptor generated in memory.
>
> > +} __attribute__((__packed__)) cr_plugin_desc_t;
>
> Why do we need __packed__ here?
To make sure that there is no holes or anything in the
structure. I must admit it's not that required but
decided to put it here just to be safe.
> > +extern cr_plugin_desc_t CR_PLUGIN_DESC;
> > +
> > +#define CR_PLUGIN_REGISTER(___name, ___init, ___exit) \
> > + cr_plugin_desc_t CR_PLUGIN_DESC = { \
> > + .name = ___name, \
> > + .init = ___init, \
> > + .exit = ___exit, \
> > + .version = CRIU_PLUGIN_VERSION, \
> > + .max_hooks = CR_PLUGIN_HOOK__MAX, \
> > + .priv_size = CR_PRIV_SIZE, \
> > + }
> > +
> > +static inline int cr_plugin_dummy_init(void) { return 0; }
> > +static inline void cr_plugin_dummy_exit(void) { }
>
> I think inline is useless here, because you are going to access these
> function by pointers.
Without inline I've got compile warnings in earlier development stages
of this code. Not a big deal can drop it out.
More information about the CRIU
mailing list