On Tue, Sep 21, 2010 at 02:32:18PM -0700, Steven Dake wrote:
> Attached is a brief patch which exposes some new APIs and callbacks
> I am considering adding to the CPG interface.  The general use for
> this is to synchronize state after a configuration change.
> 
> The initialization is as follows:
> 
> cpg_model_initialize (&handle, CPG_MODEL_V2, &model_v2_data, NULL);
> 
> model_v2_data is a typedef of cpg_model_v2_data_t which contains the
> new callbacks:
> 
> typedef void (*cpg_confchg_pending_fn_t) (
>         cpg_handle_t handle,
>         const struct cpg_name *group_name,
>         uint64_t checkpoint_pending_id);
> 
> This is delivered prior to a confchg_fn being called.  This tells
> the application to package a checkpoint and send it with
> cpg_checkpoint_send().  (checkpoint_pending_id is passed into this
> api).  The checkpoint contents are packaged with the apis
> cpg_checkpoint_create() and cpg_checkpoint_add().

Why have this "checkpoint" idea? How about an API like exec/sync.c?

sync_started()
sync_aborted()
sync_complete()

So simerlar to what you have done but without data section.

This way you can keep the cpg API message based and simplify this API.

Also you should have an idea of a "merge method". So an application
developer does not have to figure out how merging works. One
option is to just have "builtin" and custom.

builtin: a master sync'er is chosen and only it's messages are
         delivered.
custom: all messages are sent and the application developer
        makes their own merge technique.

-Angus

> 
> typedef void (*cpg_confchg_pending_deliver_checkpoint_fn_t) (
>         cpg_handle_t handle,
>         const struct cpg_name *group_name,
>         uint32_t nodeid,
>         struct cpg_address *source_member,
>         void *checkpoint_instance);
> 
> When a processor receives the cpg_checkpoint_send data, it processes
> it and starts to replace its internal state with the state of the
> checkpoint information via the cpg_checkpoint_iteration_reset and
> cpg_checkpoint_iteration_next apis.  After it is done, it executes a
> cpg_checkpoint_destroy API call on the data.
> 
> After all checkpoint_deliver_checkpoint_fn checkpoint_instance data
> have been delivered to the cpg clients, the cpg clients then receive
> the original checkpoint_confchg_fn callback.
> 
> When this happens, the cpg applications are in a perfectly consistent state.
> 
> This would be a Y bump of the cpg soname and a X bump of the
> corosync package (corosnync 2.0 but maintaining backwards ABI
> compatability).
> 
> Regards
> -steve

> Index: include/corosync/cpg.h
> ===================================================================
> --- include/corosync/cpg.h    (revision 3041)
> +++ include/corosync/cpg.h    (working copy)
> @@ -80,6 +80,7 @@
>  
>  typedef enum {
>       CPG_MODEL_V1 = 1,
> +     CPG_MODEL_V2 = 2
>  } cpg_model_t;
>  
>  struct cpg_address {
> @@ -132,6 +133,18 @@
>       uint32_t member_list_entries,
>       const uint32_t *member_list);
>  
> +typedef void (*cpg_confchg_pending_fn_t) (
> +     cpg_handle_t handle,
> +     const struct cpg_name *group_name,
> +     uint64_t checkpoint_pending_id);
> +
> +typedef void (*cpg_confchg_pending_deliver_checkpoint_fn_t) (
> +     cpg_handle_t handle,
> +     const struct cpg_name *group_name,
> +     uint32_t nodeid,
> +     struct cpg_address *source_member,
> +     void *checkpoint_instance);
> +
>  typedef struct {
>       cpg_deliver_fn_t cpg_deliver_fn;
>       cpg_confchg_fn_t cpg_confchg_fn;
> @@ -151,6 +164,15 @@
>       unsigned int flags;
>  } cpg_model_v1_data_t;
>  
> +typedef struct {
> +     cpg_model_t model;
> +     cpg_deliver_fn_t cpg_deliver_fn;
> +     cpg_confchg_fn_t cpg_confchg_fn;
> +     cpg_confchg_pending_fn_t cpg_confhg_pending_fn;
> +     cpg_confchg_pending_deliver_checkpoint_fn_t 
> cpg_onfhg_pending_deliver_checkpoint_fn;
> +     cpg_totem_confchg_fn_t cpg_totem_confchg_fn;
> +     unsigned int flags;
> +} cpg_model_v2_data_t;
>  
>  /** @} */
>  
> @@ -279,6 +301,37 @@
>  cs_error_t cpg_iteration_finalize (
>       cpg_iteration_handle_t handle);
>  
> +/*
> + * V2 Model checkpoint features
> + */
> +cs_error_t cpg_checkpoint_create (
> +     void **checkpoint_instance);
> +
> +cs_error_t cpg_checkpoint_destroy (
> +     void *checkpoint_instance);
> +
> +cs_error_t cpg_checkpoint_add (
> +     void *checkpoint_instance,
> +     void *checkpoint_id,
> +     uint64_t checkpoint_id_len,
> +     void *checkpoint_data,
> +     uint64_t checkpoint_data_len);
> +
> +cs_error_t cpg_checkpoint_iteration_reset (
> +     void *checkpoint_instance);
> +
> +cs_error_t cpg_checkpoint_iteration_next (
> +     void *checkpoint_instance,
> +     void **checkpoint_id,
> +     uint64_t *checkpoint_id_len,
> +     void **checkpoint_data,
> +     uint64_t *checkpoint_data_len);
> +
> +cs_error_t cpg_checkpoint_send (
> +     cpg_handle_t handle,
> +     uint64_t checkpoint_pending_id,
> +     void *checkpoint_instance);
> +
>  #ifdef __cplusplus
>  }
>  #endif

> _______________________________________________
> Openais mailing list
> [email protected]
> https://lists.linux-foundation.org/mailman/listinfo/openais

_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais

Reply via email to