Defines the API used by the Tools Services for dynamically loading plugins.
More...
Defines the API used by the Tools Services for dynamically loading plugins.
Plugins are dynamically loaded into the Tools service process, and may provide applications that hook into the functionality provided by the service, such as the glib main loop and the GuestRPC channel.
Plugins that want to remain loaded by the service should always return registration data when their registration function (ToolsPluginOnLoad()) is called. The registration data, defined by the ToolsPluginData data structure, provides information about what events the plugin is interested in (for example, incoming RPCs).
◆ TOOLS_CORE_PROP_CTX
#define TOOLS_CORE_PROP_CTX "tcs_app_ctx" |
Property where the container's ToolsAppCtx is stored.
This property is useful in cases where the client code has access to the service object instance but not to the container's context object, such as in the callback for the object's "notify" signal.
◆ TOOLS_CORE_SIG_CAPABILITIES
#define TOOLS_CORE_SIG_CAPABILITIES "tcs_capabilities" |
Signal sent when registering or unregistering capabilities.
- Parameters
-
[in] | src | The source object. |
[in] | ctx | ToolsAppCtx *: the application context. |
[in] | set | gboolean: TRUE if setting capabilities, FALSE if unsetting them. |
[in] | data | Client data. |
- Returns
- A GArray instance with the capabilities to be set or unset. The elements should be of type ToolsAppCapability.
◆ TOOLS_CORE_SIG_CONF_RELOAD
#define TOOLS_CORE_SIG_CONF_RELOAD "tcs_conf_reload" |
Signal sent when the config file is reloaded.
- Parameters
-
[in] | src | The source object. |
[in] | ctx | ToolsAppCtx *: The application context. |
[in] | data | Client data. |
◆ TOOLS_CORE_SIG_DUMP_STATE
#define TOOLS_CORE_SIG_DUMP_STATE "tcs_dump_state" |
Signal sent when the service receives a request to dump its internal state to the log. This is for debugging purposes, and plugins can respond to the signal by dumping their own state also.
- Parameters
-
[in] | src | The source object. |
[in] | ctx | ToolsAppCtx *: The application context. |
[in] | data | Client data. |
◆ TOOLS_CORE_SIG_NO_RPC
#define TOOLS_CORE_SIG_NO_RPC "tcs_no_rpc" |
Signal sent when RpcChannel is going to be destroyed.
- Parameters
-
[in] | src | The source object. |
[in] | ctx | ToolsAppCtx *: The application context. |
[in] | data | Client data. |
◆ TOOLS_CORE_SIG_RESET
#define TOOLS_CORE_SIG_RESET "tcs_reset" |
Signal sent when a successful RpcChannel reset occurs.
- Parameters
-
[in] | src | The source object. |
[in] | ctx | ToolsAppCtx *: The application context. |
[in] | data | Client data. |
◆ TOOLS_CORE_SIG_SET_OPTION
#define TOOLS_CORE_SIG_SET_OPTION "tcs_set_option" |
Signal sent when a "set option" RPC message arrives.
- Parameters
-
[in] | src | The source object. |
[in] | ctx | ToolsAppCtx *: The application context. |
[in] | option | gchar *: Option being set. |
[in] | value | gchar *: Option value. |
[in] | data | Client data. |
- Returns
- A gboolean saying whether the option was recognized and the value was valid.
◆ TOOLS_CORE_SIG_SHUTDOWN
#define TOOLS_CORE_SIG_SHUTDOWN "tcs_shutdown" |
Signal sent when shutting down the service.
- Parameters
-
[in] | src | The source object. |
[in] | ctx | ToolsAppCtx *: The application context. |
[in] | data | Client data. |
◆ TOOLS_CORE_SIG_XIOERROR
#define TOOLS_CORE_SIG_XIOERROR "tcs_de_xioerror" |
Signal emitted upon X I/O error callback firing.
- Parameters
-
[in] | src | The source object. |
[in] | ctx | ToolsAppCtx *: the application context. |
[in] | data | Client data. |
◆ TOOLS_CORE_SIG_XSM_DIE
#define TOOLS_CORE_SIG_XSM_DIE "tcs_de_xsm_die" |
Signal emitted upon SmcCallbacks::die.
- Parameters
-
[in] | src | The source object. |
[in] | ctx | ToolsAppCtx *: the application context. |
[in] | data | Client data. |
◆ TOOLS_CORE_SIG_XSM_SAVE_COMPLETE
#define TOOLS_CORE_SIG_XSM_SAVE_COMPLETE "tcs_de_xsm_save_complete" |
Signal emitted upon SmcCallbacks::save_complete.
- Parameters
-
[in] | src | The source object. |
[in] | ctx | ToolsAppCtx *: the application context. |
[in] | data | Client data. |
◆ TOOLS_CORE_SIG_XSM_SAVE_YOURSELF
#define TOOLS_CORE_SIG_XSM_SAVE_YOURSELF "tcs_de_xsm_save_yourself" |
Signal emitted upon SmcCallbacks::save_yourself.
- Parameters
-
[in] | src | The source object. |
[in] | ctx | ToolsAppCtx *: the application context. @parma[in] saveType Refer to SMlib.xml. |
[in] | shutdown | 0 = checkpoint, 1 = shutdown. |
[in] | interactStyle | May interact with user? |
[in] | fast | Shutdown as quickly as possible. |
[in] | data | Client data. |
◆ TOOLS_CORE_SIG_XSM_SHUTDOWN_CANCELLED
#define TOOLS_CORE_SIG_XSM_SHUTDOWN_CANCELLED "tcs_de_xsm_shutdown_cancelled" |
Signal emitted upon SmcCallbacks::shutdown_cancelled.
- Parameters
-
[in] | src | The source object. |
[in] | ctx | ToolsAppCtx *: the application context. |
[in] | data | Client data. |
◆ TOOLS_IS_MAIN_SERVICE
#define TOOLS_IS_MAIN_SERVICE |
( |
|
ctx | ) |
|
Value: (strcmp((ctx)->name, \
VMTOOLS_GUEST_SERVICE) == 0)
Checks if the Tools service is main (system) service or not.
- Parameters
-
[in] | ctx | The application context or tools service state. |
◆ TOOLS_IS_USER_SERVICE
#define TOOLS_IS_USER_SERVICE |
( |
|
ctx | ) |
|
Value: (strcmp((ctx)->name, \
VMTOOLS_USER_SERVICE) == 0)
Checks if the Tools service is user (logged in user) service or not.
- Parameters
-
[in] | ctx | The application context or tools service state. |
◆ TOOLS_MODULE_EXPORT
#define TOOLS_MODULE_EXPORT VMTOOLS_EXTERN_C |
Definition for tagging functions to be exported in the plugin binary. Use this to tag the plugin entry point function, and any other functions that the plugin needs to export.
◆ VMTOOLSAPP_ATTACH_SOURCE
#define VMTOOLSAPP_ATTACH_SOURCE |
( |
|
ctx, |
|
|
|
src, |
|
|
|
cb, |
|
|
|
data, |
|
|
|
destroy |
|
) |
| |
Value: do { \
GSource *__src = (src); \
g_source_set_callback(__src, (GSourceFunc) (cb), (data), (destroy)); \
g_source_attach(__src, g_main_loop_get_context((ctx)->mainLoop)); \
} while (0)
Attaches the given event source to the app context's main loop.
- Parameters
-
[in] | ctx | The application context. |
[in] | src | Source to attach. |
[in] | cb | Callback to call when event is "ready". |
[in] | data | Data to provide to the callback. |
[in] | destroy | Destruction notification callback. |
◆ VMTOOLSAPP_ERROR
#define VMTOOLSAPP_ERROR |
( |
|
ctx, |
|
|
|
err |
|
) |
| |
Value: do { \
ASSERT((err) != 0); \
(ctx)->errorCode = (err); \
g_main_loop_quit((ctx)->mainLoop); \
} while (0)
Error reporting macro. Call this if the app encounters an error that requires the service to quit. The service's main loop will stop as soon as it regains control of the application.
- Parameters
-
[in] | ctx | The application context. |
[in] | err | Error code. Must not be 0. |
◆ ToolsAppCapability
Information about a capability supported by the application. This structure supports both old-style capabilities (which have a separate RPC message for each capability) and new-style capabilities (as defined in guestCaps.h).
The service will register all capabilities with non-zero values when the service is started (or the host asks for the service to register its capabilities).
◆ ToolsAppCtx
Defines the context of a tools application. This data is provided by the core services to applications when they're loaded.
◆ ToolsAppProvider
Defines the registration data for an "application provider". Application providers allow plugins to hook into new application frameworks that will be then managed by vmtoolsd - for example, an HTTP server or a dbus endpoint.
Application providers will be loaded during startup but not activated until at least one plugin provides registration data for that provider.
◆ ToolsAppReg
Defines a "app-specific" registration. The array contains data specific to an "application provider" implementation.
When the service is shutting down, if the data field is not NULL, the array instance will be freed, including its backing element array. See the documentation for g_array_free(). This will happen only after any plugin's shutdown callback is called, so plugins have a chance of performing custom clean up of this data.
◆ ToolsPluginData
The registration data for an application. This gives the service information about all functionality exported by the application, and any events that the application may be interested in.
When the plugin is shut down, if the regs field is not NULL, it (and its element array) are freed with g_array_free().
Plugins shouldn't try to free the returned structure, since the container will try to use it even after the shutdown signal is sent to plugins. The pointer should either point to statically allocated memory, or be leaked (which should't be a problem since it will only be really leaked when the process is shutting down).
◆ ToolsPluginOnLoad
Signature for the plugin entry point function. The function should be called ToolsOnLoad, and be exported in the plugin binary (e.g., by tagging it with TOOLS_MODULE_EXPORT).
If the plugin wants to stay loaded, it always should return the registration data, even if all it contains is the (mandatory) plugin name. Plugins which return NULL will be unloaded before the service is started, so they shouldn't modify the service state (for example, by adding callbacks to the service's main loop).
◆ ToolsPluginSignalCb
Defines a struct for mapping callbacks to signals. Normally it would suffice to use g_signal_connect() directly to register interest in signals; but to allow dynamic registration of signals by plugins, using this struct allows registration to be delayed until all plugins have been loaded and have had the chance to register their own signals. The daemon code then can go through the plugins' registration data and connect all desired signals.
◆ ToolsServiceProperty
Defines a property that is exposed through the containers instance object (ToolsAppCtx::serviceObj). Plugins can expose properties through this mechanism to share state with other plugins. Properties can be accessed using GObject's g_set_property / g_get_property APIs, or monitored by registering for the "notify" signal on the object.
All properties exposed using this mechanism are opaque pointers. It's up for individual plugins to define the actual types of the properties.
Properties are not ref counted, so consumers (code calling "g_get_property") should be aware of the life cycle of the property as defined by the producer.
◆ ToolsAppType
Type of the application feature being registered.
Enumerator |
---|
TOOLS_APP_GUESTRPC | Denotes a list of GuestRPC registrations (type RpcChannelCallback).
|
TOOLS_APP_SIGNALS | Denotes a list of signals the application is interested in (type ToolsPluginSignalCb).
|
TOOLS_APP_PROVIDER | Denotes an application provider (type ToolsAppProvider). This allows plugins to extend the functionality of vmtoolsd by adding new application types (that other plugins can hook into).
|
TOOLS_SVC_PROPERTY | Denotes a property made available through the service's instance object (ToolsAppCtx::serviceObj).
|
◆ ToolsCapabilityType
Identifies the type of a Tools capability.
◆ ToolsCoreAPI
This enum lists all API versions that different versions of vmtoolsd support. The "ToolsAppCtx" instance provided to plugins contains a "version" field which is a bit-mask of these values, telling plugins what features the container supports.
Refer to a specific feature's documentation for which version of the API is needed for it to be supported.