FPS Standalone and CMD Modes¶
Overview¶
The Function Parameter Structure (FPS) in the milk package
provides a unified way to manage parameters for processes
and CLI tools. Developers expose FPS-driven functionalities
using two primary modes:
- CMD/CLI Mode: Registered commands inside the
milk-clienvironment. - Standalone Mode: Self-contained executables invoked
directly from the terminal (
milk-fpsexec-*).
These modes unify function parameter management so developers write core logic once, bind arguments to FPS parameters, and expose them universally.
See also: FPS · CLI Reference · Programmer's Guide · Developer Tutorial
1. CMD / CLI Mode (Integrated)¶
Implementation¶
CMD mode allows a function to be executed through the
interactive milk-cli shell. It is implemented by
registering a custom wrapper function with the CLI
framework using RegisterCLIcmd().
In this mode, arguments are captured via the CLI parser
(stored in data.cmdargtoken) rather than argv.
Key Characteristics¶
- Local Memory FPS: CLI implementations maintain an
entirely local
FUNCTION_PARAMETER_STRUCT(with.SMfd = -1) preventing the need for shared memory allocations if the command executes synchronously in a single shot. - Data Binding: A binding structure (e.g.,
FPS_CLI_BINDING) maps native C variables to their respective FPS representations. - Argument Processing: When the CLI command executes,
FPS_process_CLI_and_sync()extracts the typed arguments from the CLI tokens, updates the internal FPS values, and synchronizes them to the statically or dynamically allocated C variables.
Example Implementation (examplefunc_fps_cli_poc.c):
static FPS_CLI_BINDING my_bindings[] = {
FPS_PARAMS(FPS_X_BINDING)
};
static const int nb_bindings =
sizeof(my_bindings) / sizeof(FPS_CLI_BINDING);
static errno_t CLIfunction(void) {
return safe_fps_generic_CLIfunction(
&FPS_app_info, farg, &CLIcmddata,
my_bindings, nb_bindings,
compute_function);
}
2. Standalone Mode¶
Implementation¶
Standalone mode allows executing an FPS-driven module
directly as an independent binary (e.g.,
milk-fpsexec-mymodule). It handles native OS arguments
(argc, argv) while hooking into the underlying FPS
metadata architecture.
This mode uses the FPS_MAIN_STANDALONE_V2 macro provided
in fps.h.
Command Line Parsing¶
Standalone executables support two layers of argument parsing:
A. Standard FPS Process Control Commands
Before mapping to business logic, the executable looks for built-in flags and process control commands. This establishes the lifecycle of the shared memory FPS segment.
- Options:
-h,--help: View detailed parameter bindings and command help.-h1,--help-oneline: Print one-line description and exit.-tmux: Automatically create atmuxsession and dispatch commands isolated from the main terminal.-n,--name <fpsname>: Override the default FPS shared memory name.-k,-d: Pass keywords and descriptions forfpsinit.- Commands:
fpsinit: Create the FPS shared memory segment.confstart,confstep,confstop: Manage the configuration loop.runstart,runstop: Manage the execution loop.
B. Direct Execution (Positional Arguments)
If the user passes positional arguments that do not
match the built-in control commands (e.g.,
./milk-fpsexec-mymod 2.5 100), the standalone
operates as a streamlined one-shot execution tool:
- FPS Handshake: Attempts to connect to the shared memory FPS (if running). If not found, provisions a temporary local FPS memory space inline.
- Positional Parsing: Maps positional
argvelements against definedFPS_CLI_BINDINGconfigurations, converting types as needed. - Synchronization & Execution: Bound C pointers are
updated synchronously, and the core logic executes
exactly as it would inside the
milk-clienvironment.
Using FPS_MAIN_STANDALONE_V2¶
For all applications, use the V2 macro:
This macro automatically orchestrates standard commands
(fpsinit, confstart, etc.), integrates -tmux
dispatch, and registers with processinfo for
heartbeat monitoring.
If you have a custom configuration check function, use: