sync pacemakerd with sbd #1957
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,70 @@ | ||
| /* | ||
| * Copyright 2004-2019 the Pacemaker project contributors | ||
| * | ||
| * The version control history for this file may have further details. | ||
| * | ||
| * This source code is licensed under the GNU Lesser General Public License | ||
| * version 2.1 or later (LGPLv2.1+) WITHOUT ANY WARRANTY. | ||
| */ | ||
|
|
||
| #ifndef PACEMAKERD_TYPES__H | ||
| # define PACEMAKERD_TYPES__H | ||
|
|
||
| #ifdef __cplusplus | ||
| extern "C" { | ||
| #endif | ||
|
|
||
| #include <time.h> | ||
|
|
||
| enum pacemakerd_conn_state { | ||
| pacemakerd_conn_connected, | ||
| pacemakerd_conn_disconnected | ||
| }; | ||
|
There was a problem hiding this comment. I'm conflicted about the naming. I'd prefer that new public APIs use the "pcmk_" prefix but I can't think of a good choice for this. Looking at existing client APIs, we have: crm_/crm_cluster_t, cib/cib_t, attrd_/crm_ipc_t, lrmd_/lrmd_t, and stonith_/stonith_t. I'm not a fan of the "d" prefixes because I'd rather use those within the daemons themselves, and be clearer that these APIs are for clients. Going forward I could see something like pcmk_cib_, pcmk_attr_, pcmk_exec_. Maybe "pcmk_master_"?
Contributor
Author
There was a problem hiding this comment. All in all quite a mess as we are ending up with a mixture of the old and the new names. There was a problem hiding this comment. mcp stands for master control process, so that only hides it :)
Contributor
Author
There was a problem hiding this comment. Jeah I know what it stands for but when you see "mcp" it doesn't pattern-match "master" and after unfolding you get what it really is about. There was a problem hiding this comment. pacemaker-launchd was a serious possibility for 2.0 but we decided against it. mcp isn't used at all publicly in 2.0, so we wouldn't be adding a third, we'd just be relabeling it like the other 1.1 names. pcmk_api_ feels redundant. I like "supervisor" as being closest to what it actually does. "global" or "core" might work. |
||
|
|
||
| enum pacemakerd_state { | ||
| pacemakerd_state_invalid = -1, | ||
| pacemakerd_state_init = 0, | ||
| pacemakerd_state_starting_daemons, | ||
| pacemakerd_state_wait_for_ping, | ||
| pacemakerd_state_running, | ||
| pacemakerd_state_shutting_down, | ||
| pacemakerd_state_shutdown_complete, | ||
| pacemakerd_state_max = pacemakerd_state_shutdown_complete, | ||
| }; | ||
|
|
||
| typedef struct pacemakerd_s pacemakerd_t; | ||
|
|
||
| typedef struct pacemakerd_api_operations_s { | ||
| int (*connect) (pacemakerd_t *pacemakerd, const char *name); | ||
| int (*disconnect) (pacemakerd_t *pacemakerd); | ||
| void (*free) (pacemakerd_t *pacemakerd); | ||
| int (*set_ping_callback) (pacemakerd_t *pacemakerd, | ||
| void (*callback) (pacemakerd_t *pacemakerd, | ||
| time_t last_good, | ||
| enum pacemakerd_state state, | ||
| int rc, gpointer userdata), | ||
| gpointer userdata); | ||
| int (*set_disconnect_callback) (pacemakerd_t *pacemakerd, | ||
| void (*callback) (gpointer userdata), | ||
| gpointer userdata | ||
| ); | ||
| int (*ping) (pacemakerd_t *pacemakerd, const char *name, | ||
| const char *admin_uuid, int call_options); | ||
| } pacemakerd_api_operations_t; | ||
|
|
||
| struct pacemakerd_s { | ||
| enum pacemakerd_conn_state conn_state; | ||
| void *pacemakerd_private; | ||
| pacemakerd_api_operations_t *cmds; | ||
|
There was a problem hiding this comment. Since the methods here are invariant, I'd recommend something more like the crm_ipc_t model:
Contributor
Author
There was a problem hiding this comment. Do we really want to break with that? crm_ipc_t is rather the exception so far while other APIs don't make much use of virtual methods either. There was a problem hiding this comment. I don't see the value for a case like this, but I'm fine with keeping pointers if you want them. I'd still hide conn_state (callers shouldn't change it), and I'd put the pointers in the main struct rather than use a separate struct for them (since we're hiding everything else anyway).
Contributor
Author
There was a problem hiding this comment. If we decide to walk away from the pointers on the longer run and with new APIs for now I have nothing against it. Just wanted to be sure we aren't overlooking some potential of what we already have before we alter it or proceed in an inconsistent way. There was a problem hiding this comment. Ah, I didn't think of being able to add to the bottom of each separately. Though even then, it would just be for visual organization -- you could mix new members and methods at the end of a single struct. I like hiding the entire type partly because we have complete freedom over the implementation (don't have to add things at the end, can change types of existing members, etc.) and partly because it's impossible for callers to misuse it by statically declaring a struct or using sizeof() on it. Using the void* private technique gets most of that though. |
||
| }; | ||
|
|
||
| pacemakerd_t * pacemakerd_api_new(void); | ||
| void pacemakerd_api_delete(pacemakerd_t * pacemakerd); | ||
| enum pacemakerd_state pacemakerd_state_text2enum(const char *state); | ||
| const char *pacemakerd_state_enum2text(enum pacemakerd_state state); | ||
|
|
||
| #ifdef __cplusplus | ||
| } | ||
| #endif | ||
|
|
||
| #endif // PACEMAKERD_TYPES__H | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.