lukechilds
/
lightning
mirror of https://github.com/lukechilds/lightning.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
7336 Commits
55 Branches
107 Tags
38 MiB
Tree: b6b2e6727e
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'b6b2e6727e'
${ noResults }
lightning/lightningd/plugin_hook.h

115 lines
5.2 KiB
Raw Normal View History

plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it's unlikely that we'll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker <decker.christian@gmail.com>
6 years ago
#ifndef LIGHTNING_LIGHTNINGD_PLUGIN_HOOK_H
#define LIGHTNING_LIGHTNINGD_PLUGIN_HOOK_H
#include "config.h"
#include <ccan/autodata/autodata.h>
#include <ccan/tal/tal.h>
#include <ccan/typesafe_cb/typesafe_cb.h>
common: move json_stream from lightningd/ to common/ It&#39;s not lightningd-specific and we are going to need it for libplugin. The only drawback is the log_io removal in json_stream_output_write()..
5 years ago
#include <common/json_stream.h>
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
#include <lightningd/lightningd.h>
#include <lightningd/plugin.h>
/**
* Plugin hooks are a way for plugins to implement custom behavior and
* reactions to certain things in `lightningd`. `lightningd` will ask
* plugins that have registered a hook for a given event how it'd like
* to proceed. This allows plugins to deviate from the default
* behavior that `lightningd` otherwise implements.
*
* Examples include storing an additional backup of important
* information belonging to the wallet before committing to it, or
* holding an incoming payment that is guaranteed to succeed for some
* time in order to check that the delivery of goods works correctly,
* giving the option of instantly refunding should something go wrong.
*
* Hooks are commonly structured into a number of converter functions
* and a callback. The converter functions convert from an internal
* struct representation of the method arguments to a JSON-object for
* delivery to the plugin, and from a JSON-object to the internal
* representation:
*
* - `serialize_payload` which takes a payload of type `payload_type`
* and serializes it into the given `json_stream`. `
*
lightningd: remove deserialize step for plugin hooks. This seems like overkill, at least for now. Handling the JSON inline is clearer, for the existing examples at least. We also remove the dummy hook, rather than fix it. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
* - `response_cb` is called once the plugin has responded (or with
* buffer == NULL if there's no plugin). In addition an arbitrary
* additional argument of type `cb_arg_type` can be passed along
* that may contain any additional context necessary.
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
*
*
* To make hook invocations easier, each hook registered with
* `REGISTER_PLUGIN_HOOK` provides a `plugin_hook_call_hookname`
* function that performs typechecking at compile time, and makes sure
* that all the provided functions for serialization, deserialization
* and callback have the correct type.
*/
struct plugin_hook {
const char *name;
lightningd: remove deserialize step for plugin hooks. This seems like overkill, at least for now. Handling the JSON inline is clearer, for the existing examples at least. We also remove the dummy hook, rather than fix it. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
void (*response_cb)(void *arg, const char *buffer, const jsmntok_t *toks);
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
void (*serialize_payload)(void *src, struct json_stream *dest);
/* Which plugin has registered this hook? */
struct plugin *plugin;
};
AUTODATA_TYPE(hooks, struct plugin_hook);
/* Do not call this directly, rather use the `plugin_hook_call_name`
* wrappers generated by the `PLUGIN_HOOK_REGISTER` macro.
*/
void plugin_hook_call_(struct lightningd *ld, const struct plugin_hook *hook,
void *payload, void *cb_arg);
/* Create a small facade in from of `plugin_hook_call_` to make sure
* arguments are of the correct type before downcasting them to `void
* *`. Not really necessary, but nice since it also makes sure that
* the method-name is correct for the call.
*/
/* FIXME: Find a way to avoid back-to-back declaration and definition */
#define PLUGIN_HOOK_CALL_DEF(name, payload_type, response_cb_arg_type) \
plugin: Add hooks that a plugin might register This is the first use of the `hooks` autodata field, and it required a dummy element in order for the section not to be dropped, it&#39;ll be removed once we have actual hooks.
6 years ago
UNNEEDED static inline void plugin_hook_call_##name( \
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
struct lightningd *ld, payload_type payload, \
response_cb_arg_type cb_arg) \
{ \
plugin_hook_call_(ld, &name##_hook_gen, (void *)payload, \
(void *)cb_arg); \
}
/* Typechecked registration of a plugin hook. We check that the
* serialize_payload function converts an object of type payload_type
* to a json_stream (.params object in the JSON-RPC request), that the
* deserialize_response function converts from the JSON-RPC response
* json_stream to an object of type response_type and that the
* response_cb function accepts the deserialized response format and
* an arbitrary extra argument used to maintain context.
*/
#define REGISTER_PLUGIN_HOOK(name, response_cb, response_cb_arg_type, \
lightningd: remove deserialize step for plugin hooks. This seems like overkill, at least for now. Handling the JSON inline is clearer, for the existing examples at least. We also remove the dummy hook, rather than fix it. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
serialize_payload, payload_type) \
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
struct plugin_hook name##_hook_gen = { \
stringify(name), \
lightningd: remove deserialize step for plugin hooks. This seems like overkill, at least for now. Handling the JSON inline is clearer, for the existing examples at least. We also remove the dummy hook, rather than fix it. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
typesafe_cb_cast(void (*)(void *, const char *, const jsmntok_t *),\
void (*)(response_cb_arg_type, \
const char *, const jsmntok_t *), \
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
response_cb), \
typesafe_cb_cast(void (*)(void *, struct json_stream *), \
void (*)(payload_type, struct json_stream *), \
serialize_payload), \
NULL, /* .plugin */ \
}; \
AUTODATA(hooks, &name##_hook_gen); \
PLUGIN_HOOK_CALL_DEF(name, payload_type, response_cb_arg_type);
bool plugin_hook_register(struct plugin *plugin, const char *method);
lightningd/plugin_hook: make it possible to unregister a hook This adds &#39;plugin_unregister_hook&#39; and &#39;plugin_unregister_hook_all&#39; functions to unregister a given hook a plugin registered, or all hooks a plugin registered for. Since hooks can only be registered once, it&#39;s useful in the case a new plugin is added which would be prefered for hook registration over an already loaded plugin.
6 years ago
/* Unregister a hook a plugin has registered for */
bool plugin_hook_unregister(struct plugin *plugin, const char *method);
/* Unregister all hooks a plugin has registered for */
void plugin_hook_unregister_all(struct plugin *plugin);
db: Consolidate access to the changes in a db We were passing them in separately, while we could just retrieve them from the db instance instead.
5 years ago
/* Special sync plugin hook for db. */
void plugin_hook_db_sync(struct db *db);
plugin_hook: special case for db hook. I started by trying to change the current infrastructure, but this is really the only completely sync hook which makes sense; it needs to avoid doing the db_transation, as well as waiting, and using a callback is just overkill. So with some regret, I open coded it. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
#endif /* LIGHTNING_LIGHTNINGD_PLUGIN_HOOK_H */