2023-02-08 13:17:09 +01:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
/* Scripting foo
|
|
|
|
* Copyright (C) 2020 NVIDIA Corporation
|
|
|
|
* Quentin Young
|
|
|
|
*/
|
|
|
|
#ifndef __FRRSCRIPT_H__
|
|
|
|
#define __FRRSCRIPT_H__
|
|
|
|
|
2020-11-30 23:01:03 +01:00
|
|
|
#include <zebra.h>
|
|
|
|
|
|
|
|
#ifdef HAVE_SCRIPTING
|
|
|
|
|
2020-11-29 20:51:52 +01:00
|
|
|
#include <lua.h>
|
2021-08-18 14:29:22 +02:00
|
|
|
#include <nexthop.h>
|
|
|
|
#include <nexthop_group.h>
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
#include "frrlua.h"
|
2021-07-26 16:45:40 +02:00
|
|
|
#include "bgpd/bgp_script.h" // for peer and attr encoders/decoders
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2021-08-18 14:29:22 +02:00
|
|
|
/* Forward declarations */
|
2023-01-26 16:37:39 +01:00
|
|
|
struct zebra_dplane_ctx;
|
2021-08-18 14:29:22 +02:00
|
|
|
extern void lua_pushzebra_dplane_ctx(lua_State *L,
|
|
|
|
const struct zebra_dplane_ctx *ctx);
|
|
|
|
extern void lua_decode_zebra_dplane_ctx(lua_State *L, int idx,
|
|
|
|
struct zebra_dplane_ctx *ctx);
|
|
|
|
|
2021-10-18 02:23:19 +02:00
|
|
|
/*
|
|
|
|
* Script name hash
|
|
|
|
*/
|
|
|
|
PREDECL_HASH(frrscript_names);
|
|
|
|
|
|
|
|
struct frrscript_names_entry {
|
|
|
|
/* Name of a Lua hook call */
|
|
|
|
char function_name[MAXPATHLEN];
|
|
|
|
|
|
|
|
/* Lua script in which to look for it */
|
|
|
|
char script_name[MAXPATHLEN];
|
|
|
|
|
|
|
|
struct frrscript_names_item item;
|
|
|
|
};
|
|
|
|
|
|
|
|
extern struct frrscript_names_head frrscript_names_hash;
|
|
|
|
|
2024-10-18 14:36:52 +02:00
|
|
|
extern void frrscript_names_config_write(struct vty *vty);
|
|
|
|
|
2021-10-18 02:23:19 +02:00
|
|
|
int frrscript_names_hash_cmp(const struct frrscript_names_entry *snhe1,
|
|
|
|
const struct frrscript_names_entry *snhe2);
|
|
|
|
uint32_t frrscript_names_hash_key(const struct frrscript_names_entry *snhe);
|
|
|
|
|
|
|
|
DECLARE_HASH(frrscript_names, struct frrscript_names_entry, item,
|
|
|
|
frrscript_names_hash_cmp, frrscript_names_hash_key);
|
|
|
|
|
|
|
|
int frrscript_names_add_function_name(const char *function_name);
|
|
|
|
void frrscript_names_destroy(void);
|
|
|
|
int frrscript_names_set_script_name(const char *function_name,
|
|
|
|
const char *script_name);
|
|
|
|
char *frrscript_names_get_script_name(const char *function_name);
|
|
|
|
|
2020-11-29 23:43:16 +01:00
|
|
|
typedef void (*encoder_func)(lua_State *, const void *);
|
lib: add ability to decode from lua scripts
This implements the ability to get results out from lua scripts after
they've run.
For each C type we support passing to Lua, there is a corresponding
`struct frrscript_codec`. This struct contains a typename field - just a
string identifying the type - and two function pointers. The first
function pointer, encode, takes a lua_State and a pointer to the C value
and pushes some corresponding Lua representation onto the stack. The
second, decode, assumes there is some Lua value on the stack and decodes
it into the corresponding C value.
Each supported type's `struct frrscript_codec` is registered with the
scripting stuff in the library, which creates a mapping between the type
name (string) and the `struct frrscript_codec`. When calling a script,
you specify arguments by passing an array of `struct frrscript_env`.
Each of these structs has a void *, a type name, and a desired binding
name. The type names are used to look up the appropriate function to
encode the pointed-at value onto the Lua stack, then bind the pushed
value to the provided binding name, so that the converted value is
accessible by that name within the script.
Results work in a similar way. After a script runs, call
frrscript_get_result() with the script and a `struct frrscript_env`.
The typename and name fields are used to fetch the Lua value from the
script's environment and use the registered decoder for the typename to
convert the Lua value back into a C value, which is returned from the
function. The caller is responsible for freeing these.
frrscript_call()'s macro foo has been stripped, as the underlying
function now takes fixed arrays. varargs have awful performance
characteristics, they're hard to read, and structs are more defined than
an order sensitive list.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 04:09:58 +01:00
|
|
|
typedef void *(*decoder_func)(lua_State *, int);
|
|
|
|
|
|
|
|
struct frrscript_codec {
|
|
|
|
const char *typename;
|
|
|
|
encoder_func encoder;
|
|
|
|
decoder_func decoder;
|
|
|
|
};
|
2020-11-29 05:33:27 +01:00
|
|
|
|
2021-07-04 16:58:21 +02:00
|
|
|
struct lua_function_state {
|
|
|
|
const char *name;
|
|
|
|
lua_State *L;
|
|
|
|
};
|
|
|
|
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
struct frrscript {
|
|
|
|
/* Script name */
|
|
|
|
char *name;
|
|
|
|
|
2021-07-04 16:58:21 +02:00
|
|
|
/* Hash of Lua function name to Lua function state */
|
|
|
|
struct hash *lua_function_hash;
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
};
|
|
|
|
|
2021-07-04 16:58:21 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Hash related functions for lua_function_hash
|
|
|
|
*/
|
|
|
|
|
|
|
|
void *lua_function_alloc(void *arg);
|
|
|
|
|
|
|
|
unsigned int lua_function_hash_key(const void *data);
|
|
|
|
|
|
|
|
bool lua_function_hash_cmp(const void *d1, const void *d2);
|
|
|
|
|
lib: add ability to decode from lua scripts
This implements the ability to get results out from lua scripts after
they've run.
For each C type we support passing to Lua, there is a corresponding
`struct frrscript_codec`. This struct contains a typename field - just a
string identifying the type - and two function pointers. The first
function pointer, encode, takes a lua_State and a pointer to the C value
and pushes some corresponding Lua representation onto the stack. The
second, decode, assumes there is some Lua value on the stack and decodes
it into the corresponding C value.
Each supported type's `struct frrscript_codec` is registered with the
scripting stuff in the library, which creates a mapping between the type
name (string) and the `struct frrscript_codec`. When calling a script,
you specify arguments by passing an array of `struct frrscript_env`.
Each of these structs has a void *, a type name, and a desired binding
name. The type names are used to look up the appropriate function to
encode the pointed-at value onto the Lua stack, then bind the pushed
value to the provided binding name, so that the converted value is
accessible by that name within the script.
Results work in a similar way. After a script runs, call
frrscript_get_result() with the script and a `struct frrscript_env`.
The typename and name fields are used to fetch the Lua value from the
script's environment and use the registered decoder for the typename to
convert the Lua value back into a C value, which is returned from the
function. The caller is responsible for freeing these.
frrscript_call()'s macro foo has been stripped, as the underlying
function now takes fixed arrays. varargs have awful performance
characteristics, they're hard to read, and structs are more defined than
an order sensitive list.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 04:09:58 +01:00
|
|
|
struct frrscript_env {
|
|
|
|
/* Value type */
|
|
|
|
const char *typename;
|
|
|
|
|
|
|
|
/* Binding name */
|
|
|
|
const char *name;
|
|
|
|
|
|
|
|
/* Value */
|
|
|
|
const void *val;
|
|
|
|
};
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
|
|
|
|
/*
|
2021-07-18 00:20:20 +02:00
|
|
|
* Create new struct frrscript for a Lua script.
|
|
|
|
* This will hold the states for the Lua functions in this script.
|
|
|
|
*
|
|
|
|
* scriptname
|
|
|
|
* Name of the Lua script file, without the .lua
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
*/
|
2021-07-18 00:20:20 +02:00
|
|
|
struct frrscript *frrscript_new(const char *scriptname);
|
2021-07-04 17:05:37 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Load a function into frrscript, run callback if any
|
|
|
|
*/
|
|
|
|
int frrscript_load(struct frrscript *fs, const char *function_name,
|
|
|
|
int (*load_cb)(struct frrscript *));
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
|
|
|
|
/*
|
2021-07-18 00:20:20 +02:00
|
|
|
* Delete Lua function states and frrscript
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
*/
|
2021-07-08 11:51:14 +02:00
|
|
|
void frrscript_delete(struct frrscript *fs);
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
|
|
|
|
/*
|
lib: add ability to decode from lua scripts
This implements the ability to get results out from lua scripts after
they've run.
For each C type we support passing to Lua, there is a corresponding
`struct frrscript_codec`. This struct contains a typename field - just a
string identifying the type - and two function pointers. The first
function pointer, encode, takes a lua_State and a pointer to the C value
and pushes some corresponding Lua representation onto the stack. The
second, decode, assumes there is some Lua value on the stack and decodes
it into the corresponding C value.
Each supported type's `struct frrscript_codec` is registered with the
scripting stuff in the library, which creates a mapping between the type
name (string) and the `struct frrscript_codec`. When calling a script,
you specify arguments by passing an array of `struct frrscript_env`.
Each of these structs has a void *, a type name, and a desired binding
name. The type names are used to look up the appropriate function to
encode the pointed-at value onto the Lua stack, then bind the pushed
value to the provided binding name, so that the converted value is
accessible by that name within the script.
Results work in a similar way. After a script runs, call
frrscript_get_result() with the script and a `struct frrscript_env`.
The typename and name fields are used to fetch the Lua value from the
script's environment and use the registered decoder for the typename to
convert the Lua value back into a C value, which is returned from the
function. The caller is responsible for freeing these.
frrscript_call()'s macro foo has been stripped, as the underlying
function now takes fixed arrays. varargs have awful performance
characteristics, they're hard to read, and structs are more defined than
an order sensitive list.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 04:09:58 +01:00
|
|
|
* Register a Lua codec for a type.
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
*
|
|
|
|
* tname
|
|
|
|
* Name of type; e.g., "peer", "ospf_interface", etc. Chosen at will.
|
|
|
|
*
|
lib: add ability to decode from lua scripts
This implements the ability to get results out from lua scripts after
they've run.
For each C type we support passing to Lua, there is a corresponding
`struct frrscript_codec`. This struct contains a typename field - just a
string identifying the type - and two function pointers. The first
function pointer, encode, takes a lua_State and a pointer to the C value
and pushes some corresponding Lua representation onto the stack. The
second, decode, assumes there is some Lua value on the stack and decodes
it into the corresponding C value.
Each supported type's `struct frrscript_codec` is registered with the
scripting stuff in the library, which creates a mapping between the type
name (string) and the `struct frrscript_codec`. When calling a script,
you specify arguments by passing an array of `struct frrscript_env`.
Each of these structs has a void *, a type name, and a desired binding
name. The type names are used to look up the appropriate function to
encode the pointed-at value onto the Lua stack, then bind the pushed
value to the provided binding name, so that the converted value is
accessible by that name within the script.
Results work in a similar way. After a script runs, call
frrscript_get_result() with the script and a `struct frrscript_env`.
The typename and name fields are used to fetch the Lua value from the
script's environment and use the registered decoder for the typename to
convert the Lua value back into a C value, which is returned from the
function. The caller is responsible for freeing these.
frrscript_call()'s macro foo has been stripped, as the underlying
function now takes fixed arrays. varargs have awful performance
characteristics, they're hard to read, and structs are more defined than
an order sensitive list.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 04:09:58 +01:00
|
|
|
* codec(s)
|
|
|
|
* Function pointer to codec struct. Encoder function should push a Lua
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
* table representing the passed argument - which will have the C type
|
lib: add ability to decode from lua scripts
This implements the ability to get results out from lua scripts after
they've run.
For each C type we support passing to Lua, there is a corresponding
`struct frrscript_codec`. This struct contains a typename field - just a
string identifying the type - and two function pointers. The first
function pointer, encode, takes a lua_State and a pointer to the C value
and pushes some corresponding Lua representation onto the stack. The
second, decode, assumes there is some Lua value on the stack and decodes
it into the corresponding C value.
Each supported type's `struct frrscript_codec` is registered with the
scripting stuff in the library, which creates a mapping between the type
name (string) and the `struct frrscript_codec`. When calling a script,
you specify arguments by passing an array of `struct frrscript_env`.
Each of these structs has a void *, a type name, and a desired binding
name. The type names are used to look up the appropriate function to
encode the pointed-at value onto the Lua stack, then bind the pushed
value to the provided binding name, so that the converted value is
accessible by that name within the script.
Results work in a similar way. After a script runs, call
frrscript_get_result() with the script and a `struct frrscript_env`.
The typename and name fields are used to fetch the Lua value from the
script's environment and use the registered decoder for the typename to
convert the Lua value back into a C value, which is returned from the
function. The caller is responsible for freeing these.
frrscript_call()'s macro foo has been stripped, as the underlying
function now takes fixed arrays. varargs have awful performance
characteristics, they're hard to read, and structs are more defined than
an order sensitive list.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 04:09:58 +01:00
|
|
|
* associated with the chosen 'tname' to the provided stack. The decoder
|
|
|
|
* function should pop a value from the top of the stack and return a heap
|
|
|
|
* chunk containing that value. Allocations should be made with MTYPE_TMP.
|
|
|
|
*
|
|
|
|
* If using the plural function variant, pass a NULL-terminated array.
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
*
|
|
|
|
*/
|
lib: add ability to decode from lua scripts
This implements the ability to get results out from lua scripts after
they've run.
For each C type we support passing to Lua, there is a corresponding
`struct frrscript_codec`. This struct contains a typename field - just a
string identifying the type - and two function pointers. The first
function pointer, encode, takes a lua_State and a pointer to the C value
and pushes some corresponding Lua representation onto the stack. The
second, decode, assumes there is some Lua value on the stack and decodes
it into the corresponding C value.
Each supported type's `struct frrscript_codec` is registered with the
scripting stuff in the library, which creates a mapping between the type
name (string) and the `struct frrscript_codec`. When calling a script,
you specify arguments by passing an array of `struct frrscript_env`.
Each of these structs has a void *, a type name, and a desired binding
name. The type names are used to look up the appropriate function to
encode the pointed-at value onto the Lua stack, then bind the pushed
value to the provided binding name, so that the converted value is
accessible by that name within the script.
Results work in a similar way. After a script runs, call
frrscript_get_result() with the script and a `struct frrscript_env`.
The typename and name fields are used to fetch the Lua value from the
script's environment and use the registered decoder for the typename to
convert the Lua value back into a C value, which is returned from the
function. The caller is responsible for freeing these.
frrscript_call()'s macro foo has been stripped, as the underlying
function now takes fixed arrays. varargs have awful performance
characteristics, they're hard to read, and structs are more defined than
an order sensitive list.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 04:09:58 +01:00
|
|
|
void frrscript_register_type_codec(struct frrscript_codec *codec);
|
|
|
|
void frrscript_register_type_codecs(struct frrscript_codec *codecs);
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize scripting subsystem. Call this before anything else.
|
2020-11-30 23:37:18 +01:00
|
|
|
*
|
|
|
|
* scriptdir
|
|
|
|
* Directory in which to look for scripts
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
*/
|
2020-11-30 23:37:18 +01:00
|
|
|
void frrscript_init(const char *scriptdir);
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
|
2022-10-11 19:21:03 +02:00
|
|
|
/*
|
|
|
|
* On shutdown clean up memory associated with the scripting subsystem
|
|
|
|
*/
|
|
|
|
void frrscript_fini(void);
|
|
|
|
|
2021-07-23 11:03:42 +02:00
|
|
|
/*
|
|
|
|
* This macro is mapped to every (name, value) in frrscript_call,
|
|
|
|
* so this in turn maps them onto their encoders
|
|
|
|
*/
|
2021-07-28 23:50:21 +02:00
|
|
|
#define ENCODE_ARGS(name, value) ENCODE_ARGS_WITH_STATE(lfs->L, (value))
|
2021-06-14 08:54:58 +02:00
|
|
|
|
2021-07-23 11:03:42 +02:00
|
|
|
/*
|
|
|
|
* This macro is also mapped to every (name, value) in frrscript_call, but
|
|
|
|
* not every value can be mapped to its decoder - only those that appear
|
|
|
|
* in the returned table will. To find out if they appear in the returned
|
|
|
|
* table, first pop the value and check if its nil. Only call the decoder
|
|
|
|
* if non-nil.
|
|
|
|
*
|
|
|
|
* At the end, the only thing left on the stack should be the
|
|
|
|
* returned table.
|
|
|
|
*/
|
2021-06-14 08:54:58 +02:00
|
|
|
#define DECODE_ARGS(name, value) \
|
|
|
|
do { \
|
2021-07-28 23:50:21 +02:00
|
|
|
lua_getfield(lfs->L, 1, (name)); \
|
2021-07-07 15:53:10 +02:00
|
|
|
if (lua_isnil(lfs->L, 2)) { \
|
|
|
|
lua_pop(lfs->L, 1); \
|
|
|
|
} else { \
|
2021-07-28 23:50:21 +02:00
|
|
|
DECODE_ARGS_WITH_STATE(lfs->L, (value)); \
|
2021-07-07 15:53:10 +02:00
|
|
|
} \
|
|
|
|
assert(lua_gettop(lfs->L) == 1); \
|
2021-06-14 08:54:58 +02:00
|
|
|
} while (0)
|
|
|
|
|
2021-08-09 22:36:30 +02:00
|
|
|
/*
|
|
|
|
* Noop function. Used below where we need a noop decoder for any type.
|
|
|
|
*/
|
|
|
|
void _lua_decode_noop(lua_State *, ...);
|
|
|
|
|
2021-06-24 18:05:37 +02:00
|
|
|
/*
|
|
|
|
* Maps the type of value to its encoder/decoder.
|
|
|
|
* Add new mappings here.
|
|
|
|
*
|
|
|
|
* L
|
|
|
|
* Lua state
|
|
|
|
* scriptdir
|
|
|
|
* Directory in which to look for scripts
|
|
|
|
*/
|
2021-06-20 02:24:44 +02:00
|
|
|
#define ENCODE_ARGS_WITH_STATE(L, value) \
|
|
|
|
_Generic((value), \
|
2021-07-18 00:25:54 +02:00
|
|
|
int : lua_pushinteger, \
|
2021-08-09 22:41:25 +02:00
|
|
|
int * : lua_pushintegerp, \
|
2021-08-09 22:37:32 +02:00
|
|
|
long long : lua_pushinteger, \
|
2021-08-09 22:41:25 +02:00
|
|
|
long long * : lua_pushlonglongp, \
|
2021-06-20 02:24:44 +02:00
|
|
|
struct prefix * : lua_pushprefix, \
|
|
|
|
struct interface * : lua_pushinterface, \
|
|
|
|
struct in_addr * : lua_pushinaddr, \
|
|
|
|
struct in6_addr * : lua_pushin6addr, \
|
|
|
|
union sockunion * : lua_pushsockunion, \
|
2021-06-21 23:03:07 +02:00
|
|
|
char * : lua_pushstring_wrapper, \
|
|
|
|
struct attr * : lua_pushattr, \
|
2021-06-21 23:04:06 +02:00
|
|
|
struct peer * : lua_pushpeer, \
|
2021-08-18 14:29:22 +02:00
|
|
|
const struct prefix * : lua_pushprefix, \
|
|
|
|
const struct ipaddr * : lua_pushipaddr, \
|
|
|
|
const struct ethaddr * : lua_pushethaddr, \
|
|
|
|
const struct nexthop_group * : lua_pushnexthop_group, \
|
|
|
|
const struct nexthop * : lua_pushnexthop, \
|
|
|
|
struct zebra_dplane_ctx * : lua_pushzebra_dplane_ctx \
|
2021-07-28 23:50:21 +02:00
|
|
|
)((L), (value))
|
2021-06-14 08:54:58 +02:00
|
|
|
|
2021-06-20 02:25:22 +02:00
|
|
|
#define DECODE_ARGS_WITH_STATE(L, value) \
|
|
|
|
_Generic((value), \
|
2021-08-09 22:41:25 +02:00
|
|
|
int * : lua_decode_integerp, \
|
|
|
|
long long * : lua_decode_longlongp, \
|
2021-06-20 02:25:22 +02:00
|
|
|
struct prefix * : lua_decode_prefix, \
|
|
|
|
struct interface * : lua_decode_interface, \
|
|
|
|
struct in_addr * : lua_decode_inaddr, \
|
|
|
|
struct in6_addr * : lua_decode_in6addr, \
|
|
|
|
union sockunion * : lua_decode_sockunion, \
|
2021-06-21 23:03:07 +02:00
|
|
|
char * : lua_decode_stringp, \
|
2021-06-21 23:04:06 +02:00
|
|
|
struct attr * : lua_decode_attr, \
|
2021-08-09 22:36:30 +02:00
|
|
|
default : _lua_decode_noop \
|
2021-07-28 23:50:21 +02:00
|
|
|
)((L), -1, (value))
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
|
|
|
|
/*
|
2021-07-18 00:20:20 +02:00
|
|
|
* Call Lua function state (abstraction for a single Lua function)
|
2020-11-29 08:00:26 +01:00
|
|
|
*
|
2021-07-18 00:20:20 +02:00
|
|
|
* lfs
|
2021-07-18 00:25:54 +02:00
|
|
|
* The Lua function to call; this should have been loaded in by
|
2021-07-23 11:04:27 +02:00
|
|
|
* frrscript_load(). nargs Number of arguments the function accepts
|
2020-11-29 08:00:26 +01:00
|
|
|
*
|
lib: add ability to decode from lua scripts
This implements the ability to get results out from lua scripts after
they've run.
For each C type we support passing to Lua, there is a corresponding
`struct frrscript_codec`. This struct contains a typename field - just a
string identifying the type - and two function pointers. The first
function pointer, encode, takes a lua_State and a pointer to the C value
and pushes some corresponding Lua representation onto the stack. The
second, decode, assumes there is some Lua value on the stack and decodes
it into the corresponding C value.
Each supported type's `struct frrscript_codec` is registered with the
scripting stuff in the library, which creates a mapping between the type
name (string) and the `struct frrscript_codec`. When calling a script,
you specify arguments by passing an array of `struct frrscript_env`.
Each of these structs has a void *, a type name, and a desired binding
name. The type names are used to look up the appropriate function to
encode the pointed-at value onto the Lua stack, then bind the pushed
value to the provided binding name, so that the converted value is
accessible by that name within the script.
Results work in a similar way. After a script runs, call
frrscript_get_result() with the script and a `struct frrscript_env`.
The typename and name fields are used to fetch the Lua value from the
script's environment and use the registered decoder for the typename to
convert the Lua value back into a C value, which is returned from the
function. The caller is responsible for freeing these.
frrscript_call()'s macro foo has been stripped, as the underlying
function now takes fixed arrays. varargs have awful performance
characteristics, they're hard to read, and structs are more defined than
an order sensitive list.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 04:09:58 +01:00
|
|
|
* Returns:
|
|
|
|
* 0 if the script ran successfully, nonzero otherwise.
|
2020-11-29 08:00:26 +01:00
|
|
|
*/
|
2021-07-04 17:08:18 +02:00
|
|
|
int _frrscript_call_lua(struct lua_function_state *lfs, int nargs);
|
2021-06-14 08:54:58 +02:00
|
|
|
|
2021-06-24 18:05:37 +02:00
|
|
|
/*
|
2021-08-10 01:07:06 +02:00
|
|
|
* Wrapper for calling Lua function state.
|
|
|
|
*
|
|
|
|
* The Lua function name (f) to run should have already been checked by
|
|
|
|
* frrscript_load. So this wrapper will:
|
|
|
|
* 1) Find the Lua function state, which contains the Lua state
|
|
|
|
* 2) Clear the Lua state (there may be leftovers items from previous call)
|
|
|
|
* 3) Push the Lua function (f)
|
|
|
|
* 4) Map frrscript_call arguments onto their encoder and decoders, push those
|
|
|
|
* 5) Call _frrscript_call_lua (Lua execution takes place)
|
|
|
|
* 6) Write back to frrscript_call arguments using their decoders
|
|
|
|
*
|
|
|
|
* This wrapper can be called multiple times (after one frrscript_load).
|
2021-06-24 18:05:37 +02:00
|
|
|
*
|
|
|
|
* fs
|
2021-07-18 00:20:20 +02:00
|
|
|
* The struct frrscript in which the Lua fuction was loaded into
|
|
|
|
* f
|
|
|
|
* Name of the Lua function.
|
2021-06-24 18:05:37 +02:00
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* 0 if the script ran successfully, nonzero otherwise.
|
|
|
|
*/
|
2021-07-18 00:25:54 +02:00
|
|
|
#define frrscript_call(fs, f, ...) \
|
|
|
|
({ \
|
2021-07-23 11:15:38 +02:00
|
|
|
struct lua_function_state lookup = {.name = (f)}; \
|
2021-07-18 00:25:54 +02:00
|
|
|
struct lua_function_state *lfs; \
|
2021-07-23 11:15:38 +02:00
|
|
|
lfs = hash_lookup((fs)->lua_function_hash, &lookup); \
|
2021-07-18 00:25:54 +02:00
|
|
|
lfs == NULL ? ({ \
|
|
|
|
zlog_err( \
|
|
|
|
"frrscript: '%s.lua': '%s': tried to call this function but it was not loaded", \
|
2021-07-23 11:15:38 +02:00
|
|
|
(fs)->name, (f)); \
|
2021-07-18 00:25:54 +02:00
|
|
|
1; \
|
|
|
|
}) \
|
|
|
|
: ({ \
|
2021-08-10 01:07:06 +02:00
|
|
|
lua_settop(lfs->L, 0); \
|
|
|
|
lua_getglobal(lfs->L, f); \
|
2021-07-18 00:25:54 +02:00
|
|
|
MAP_LISTS(ENCODE_ARGS, ##__VA_ARGS__); \
|
|
|
|
_frrscript_call_lua( \
|
|
|
|
lfs, PP_NARG(__VA_ARGS__)); \
|
|
|
|
}) != 0 \
|
|
|
|
? ({ \
|
|
|
|
zlog_err( \
|
|
|
|
"frrscript: '%s.lua': '%s': this function called but returned non-zero exit code. No variables modified.", \
|
2021-07-23 11:15:38 +02:00
|
|
|
(fs)->name, (f)); \
|
2021-07-18 00:25:54 +02:00
|
|
|
1; \
|
|
|
|
}) \
|
|
|
|
: ({ \
|
|
|
|
MAP_LISTS(DECODE_ARGS, \
|
|
|
|
##__VA_ARGS__); \
|
|
|
|
0; \
|
|
|
|
}); \
|
2021-06-14 08:54:58 +02:00
|
|
|
})
|
2020-11-29 08:00:26 +01:00
|
|
|
|
|
|
|
/*
|
2021-07-18 00:20:20 +02:00
|
|
|
* Get result from finished function
|
2020-11-29 08:00:26 +01:00
|
|
|
*
|
lib: add ability to decode from lua scripts
This implements the ability to get results out from lua scripts after
they've run.
For each C type we support passing to Lua, there is a corresponding
`struct frrscript_codec`. This struct contains a typename field - just a
string identifying the type - and two function pointers. The first
function pointer, encode, takes a lua_State and a pointer to the C value
and pushes some corresponding Lua representation onto the stack. The
second, decode, assumes there is some Lua value on the stack and decodes
it into the corresponding C value.
Each supported type's `struct frrscript_codec` is registered with the
scripting stuff in the library, which creates a mapping between the type
name (string) and the `struct frrscript_codec`. When calling a script,
you specify arguments by passing an array of `struct frrscript_env`.
Each of these structs has a void *, a type name, and a desired binding
name. The type names are used to look up the appropriate function to
encode the pointed-at value onto the Lua stack, then bind the pushed
value to the provided binding name, so that the converted value is
accessible by that name within the script.
Results work in a similar way. After a script runs, call
frrscript_get_result() with the script and a `struct frrscript_env`.
The typename and name fields are used to fetch the Lua value from the
script's environment and use the registered decoder for the typename to
convert the Lua value back into a C value, which is returned from the
function. The caller is responsible for freeing these.
frrscript_call()'s macro foo has been stripped, as the underlying
function now takes fixed arrays. varargs have awful performance
characteristics, they're hard to read, and structs are more defined than
an order sensitive list.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 04:09:58 +01:00
|
|
|
* fs
|
|
|
|
* The script. This script must have been run already.
|
2021-07-18 00:20:20 +02:00
|
|
|
* function_name
|
|
|
|
* Name of the Lua function.
|
|
|
|
* name
|
|
|
|
* Name of the result.
|
|
|
|
* This will be used as a string key to retrieve from the table that the
|
|
|
|
* Lua function returns.
|
|
|
|
* The name here should *not* appear in frrscript_call.
|
|
|
|
* lua_to
|
|
|
|
* Function pointer to a lua_to decoder function.
|
|
|
|
* This function should allocate and decode a value from the Lua state.
|
2020-11-29 08:00:26 +01:00
|
|
|
*
|
lib: add ability to decode from lua scripts
This implements the ability to get results out from lua scripts after
they've run.
For each C type we support passing to Lua, there is a corresponding
`struct frrscript_codec`. This struct contains a typename field - just a
string identifying the type - and two function pointers. The first
function pointer, encode, takes a lua_State and a pointer to the C value
and pushes some corresponding Lua representation onto the stack. The
second, decode, assumes there is some Lua value on the stack and decodes
it into the corresponding C value.
Each supported type's `struct frrscript_codec` is registered with the
scripting stuff in the library, which creates a mapping between the type
name (string) and the `struct frrscript_codec`. When calling a script,
you specify arguments by passing an array of `struct frrscript_env`.
Each of these structs has a void *, a type name, and a desired binding
name. The type names are used to look up the appropriate function to
encode the pointed-at value onto the Lua stack, then bind the pushed
value to the provided binding name, so that the converted value is
accessible by that name within the script.
Results work in a similar way. After a script runs, call
frrscript_get_result() with the script and a `struct frrscript_env`.
The typename and name fields are used to fetch the Lua value from the
script's environment and use the registered decoder for the typename to
convert the Lua value back into a C value, which is returned from the
function. The caller is responsible for freeing these.
frrscript_call()'s macro foo has been stripped, as the underlying
function now takes fixed arrays. varargs have awful performance
characteristics, they're hard to read, and structs are more defined than
an order sensitive list.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 04:09:58 +01:00
|
|
|
* Returns:
|
2021-07-18 00:20:20 +02:00
|
|
|
* A pointer to the decoded value from the Lua state, or NULL if no such
|
|
|
|
* value.
|
2020-11-29 08:00:26 +01:00
|
|
|
*/
|
2021-07-07 15:53:38 +02:00
|
|
|
void *frrscript_get_result(struct frrscript *fs, const char *function_name,
|
|
|
|
const char *name,
|
|
|
|
void *(*lua_to)(lua_State *L, int idx));
|
2020-11-29 08:00:26 +01:00
|
|
|
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif /* __cplusplus */
|
|
|
|
|
2020-11-30 23:01:03 +01:00
|
|
|
#endif /* HAVE_SCRIPTING */
|
|
|
|
|
lib: start adding generic scripting stuff
Rather than let Luaisms propagate from the start, this is some generic
wrapper stuff that defines some semantics for interacting with scripts
that aren't specific to the underlying language.
The concept I have in mind for FRR's idea of a script is:
- has a name
- has some inputs, which have types
- has some outputs, which have types
I don't want to even say they have to be files; maybe we can embed
scripts in frr.conf, for example. Similarly the types of inputs and
outputs are probably going to end up being some language-specific setup.
For now, we will stick to this simple model, but the plan is to add full
object support (ie calling back into C).
This shouldn't be misconstrued as prepping for multilingual scripting
support, which is a bad idea for the following reasons:
- Each language would require different FFI methods, and specifically
different object encoders; a lot of code
- Languages have different capabilities that would have to be brought to
parity with each other; a lot of work
- Languages have *vastly* different performance characteristics; bad
impressions, lots of issues we can't do anything about
- Each language would need a dedicated maintainer for the above reasons;
pragmatically difficult
- Supporting multiple languages fractures the community and limits the
audience with which a given script can be shared
The only pro for multilingual support would be ease of use for users not
familiar with Lua but familiar with one of the other supported
languages. This is not enough to outweigh the cons.
In order to get rich scripting capabilities, we need to be able to pass
representations of internal objects to the scripts. For example, a
script that performs some computation based on information about a peer
needs access to some equivalent of `struct peer` for the peer in
question. To transfer these objects from C-space into Lua-space we need
to encode them onto the Lua stack. This patch adds a mapping from
arbitrary type names to the functions that encode objects of that type.
For example, the function that encodes `struct peer` into a Lua table
could be registered with:
bgp_peer_encoder_func(struct frrscript *fs, struct peer *peer)
{
// encode peer to Lua table, push to stack in fs->scriptinfo->L
}
frrscript_register_type_encoder("peer", bgp_peer_encoder_func);
Later on when calling a script that wants a peer, the plan is to be able
to specify the type name like so:
frrscript_call(script, "peer", peer);
Using C-style types for the type names would have been nice, it might be
possible to do this with preprocessor magic or possibly python
preprocessing later on.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
mergeme no stdlib
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 01:02:39 +01:00
|
|
|
#endif /* __FRRSCRIPT_H__ */
|