mirrors/core-lightning
1
0
Fork 0
mirror of https://github.com/ElementsProject/lightning.git synced 2024-11-19 09:54:16 +01:00
Code Issues Projects Releases Wiki Activity
a32b3b68e2
core-lightning/lightningd/plugin_control.h

21 lines
653 B
C
Raw Normal View History

lightningd/plugin_control: add a 'plugin' command This adds a new pair of files : lightningd/plugin_control, along with a new RPC command : 'plugin'. This command can be used to manage plugins without restarting lightningd: lightning-cli plugin start helloworld.py lightning-cli plugin stop helloworld.py
2019-06-29 13:47:48 +02:00
#ifndef LIGHTNING_LIGHTNINGD_PLUGIN_CONTROL_H
#define LIGHTNING_LIGHTNINGD_PLUGIN_CONTROL_H
#include "config.h"
plugins: cleanup shared headers between dynamic and static plugins
2019-09-14 17:35:28 +02:00
#include <lightningd/plugin.h>
lightningd/plugin_control: add a 'plugin' command This adds a new pair of files : lightningd/plugin_control, along with a new RPC command : 'plugin'. This command can be used to manage plugins without restarting lightningd: lightning-cli plugin start helloworld.py lightning-cli plugin stop helloworld.py
2019-06-29 13:47:48 +02:00
plugins: add `command` field to subcommand output. Makes it possible to write a decent JSON schema, but means we need to carry additional data, so we create a `struct plugin_command`. We remove the unused struct dynamic_plugin, too. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-06-16 03:02:17 +02:00
struct plugin_command;
lightningd: attach plugins natively to the command which started it. This will let us unify the startup and runtime-started infrastructure. Note that there are two kinds of notifications: 1. Starting a single plugin (i.e. `plugin start`) 2. Starting multiple plugins (i.e. `plugin rescan` or `plugin startdir`). In the latter case, we want the command to complete only once *all* the plugins are dead/finished. We also call plugin_kill() in all cases, and correctly return afterwards (it matters once we use the same paths for dynamic plugins, which don't cause a fatal error if they don't startup). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2020-05-05 03:13:14 +02:00
/* Plugin startup failed */
plugins: add `command` field to subcommand output. Makes it possible to write a decent JSON schema, but means we need to carry additional data, so we create a `struct plugin_command`. We remove the unused struct dynamic_plugin, too. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-06-16 03:02:17 +02:00
struct command_result *plugin_cmd_killed(struct plugin_command *pcmd,
lightningd: attach plugins natively to the command which started it. This will let us unify the startup and runtime-started infrastructure. Note that there are two kinds of notifications: 1. Starting a single plugin (i.e. `plugin start`) 2. Starting multiple plugins (i.e. `plugin rescan` or `plugin startdir`). In the latter case, we want the command to complete only once *all* the plugins are dead/finished. We also call plugin_kill() in all cases, and correctly return afterwards (it matters once we use the same paths for dynamic plugins, which don't cause a fatal error if they don't startup). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2020-05-05 03:13:14 +02:00
struct plugin *plugin, const char *msg);
/* Plugin startup succeeded */
plugins: add `command` field to subcommand output. Makes it possible to write a decent JSON schema, but means we need to carry additional data, so we create a `struct plugin_command`. We remove the unused struct dynamic_plugin, too. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-06-16 03:02:17 +02:00
struct command_result *plugin_cmd_succeeded(struct plugin_command *pcmd,
lightningd: attach plugins natively to the command which started it. This will let us unify the startup and runtime-started infrastructure. Note that there are two kinds of notifications: 1. Starting a single plugin (i.e. `plugin start`) 2. Starting multiple plugins (i.e. `plugin rescan` or `plugin startdir`). In the latter case, we want the command to complete only once *all* the plugins are dead/finished. We also call plugin_kill() in all cases, and correctly return afterwards (it matters once we use the same paths for dynamic plugins, which don't cause a fatal error if they don't startup). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2020-05-05 03:13:14 +02:00
struct plugin *plugin);
/* All plugins succeeded/failed */
struct command_result *plugin_cmd_all_complete(struct plugins *plugins,
plugins: add `command` field to subcommand output. Makes it possible to write a decent JSON schema, but means we need to carry additional data, so we create a `struct plugin_command`. We remove the unused struct dynamic_plugin, too. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-06-16 03:02:17 +02:00
struct plugin_command *pcmd);
lightningd/plugin_control: add a 'plugin' command This adds a new pair of files : lightningd/plugin_control, along with a new RPC command : 'plugin'. This command can be used to manage plugins without restarting lightningd: lightning-cli plugin start helloworld.py lightning-cli plugin stop helloworld.py
2019-06-29 13:47:48 +02:00
#endif /* LIGHTNING_LIGHTNINGD_PLUGIN_CONTROL_H */
Reference in New Issue Copy Permalink