Mirror/frr
0
0
Fork 1
mirror of https://github.com/FRRouting/frr.git synced 2025-04-30 21:47:15 +02:00
Code Issues Actions 4 Packages Projects Releases Wiki Activity
frr/lib/frrscript.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

332 lines
7.7 KiB
C
Raw Normal View History

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
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the Free
* Software Foundation; either version 2 of the License, or (at your option)
* any later version.
*
* This program is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
* more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; see the file COPYING; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
#include <zebra.h>
build: HAVE_LUA -> HAVE_SCRIPTING And also guard all scripting-related stuff with HAVE_SCRIPTING. Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 23:01:03 +01:00
#ifdef HAVE_SCRIPTING
lib: allow passing arguments to scripts - Add ability to pass arguments when calling a script - Add macros to define arguments and results Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:00:26 +01:00
#include <stdarg.h>
lib: use appropriate MTYPE for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 05:21:31 +01:00
#include <lua.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 "frrscript.h"
lib: use appropriate MTYPE for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 05:21:31 +01:00
#include "frrlua.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 "memory.h"
#include "hash.h"
#include "log.h"
build: HAVE_LUA -> HAVE_SCRIPTING And also guard all scripting-related stuff with HAVE_SCRIPTING. Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 23:01:03 +01:00
lib: use appropriate MTYPE for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 05:21:31 +01:00
DEFINE_MTYPE_STATIC(LIB, SCRIPT, "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
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
/* Codecs */
struct frrscript_codec frrscript_codecs_lib[] = {
{.typename = "integer",
.encoder = (encoder_func)lua_pushintegerp,
.decoder = lua_tointegerp},
{.typename = "string",
lib: Wrapper a function to make gcc-10 happy gcc-10 is complaining: lib/frrscript.c:42:14: error: cast between incompatible function types from ‘const char * (*)(lua_State *, const char *)’ to ‘void (*)(lua_State *, const void *)’ [-Werror=cast-function-type] 42 | .encoder = (encoder_func)lua_pushstring, | ^ Wrapper it to make it happy. Not sure what else to do. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-01-24 14:00:43 +01:00
.encoder = (encoder_func)lua_pushstring_wrapper,
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
.decoder = lua_tostringp},
{.typename = "prefix",
.encoder = (encoder_func)lua_pushprefix,
.decoder = lua_toprefix},
{.typename = "interface",
.encoder = (encoder_func)lua_pushinterface,
.decoder = lua_tointerface},
{.typename = "in_addr",
.encoder = (encoder_func)lua_pushinaddr,
.decoder = lua_toinaddr},
{.typename = "in6_addr",
.encoder = (encoder_func)lua_pushin6addr,
.decoder = lua_toin6addr},
{.typename = "sockunion",
.encoder = (encoder_func)lua_pushsockunion,
.decoder = lua_tosockunion},
{.typename = "time_t",
.encoder = (encoder_func)lua_pushtimet,
.decoder = lua_totimet},
{}};
/* Type codecs */
struct hash *codec_hash;
lib: add support for scripts directory Specify default via --with-scriptdir at compile time, override default with --scriptdir at runtime. If unspecified, it's {sysconfdir}/scripts (usually /etc/frr/scripts) Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 23:37:18 +01:00
char scriptdir[MAXPATHLEN];
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
static unsigned int codec_hash_key(const void *data)
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
const struct frrscript_codec *c = data;
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
return string_hash_make(c->typename);
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
static bool codec_hash_cmp(const void *d1, const void *d2)
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
const struct frrscript_codec *e1 = d1;
const struct frrscript_codec *e2 = d2;
lib: fix hash issues in scripting foo Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 07:59:02 +01:00
return strmatch(e1->typename, e2->typename);
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
static void *codec_alloc(void *arg)
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
struct frrscript_codec *tmp = arg;
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
struct frrscript_codec *e =
lib: use appropriate MTYPE for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 05:21:31 +01:00
XCALLOC(MTYPE_SCRIPT, sizeof(struct frrscript_codec));
e->typename = XSTRDUP(MTYPE_SCRIPT, tmp->typename);
lib: fix hash issues in scripting foo Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 07:59:02 +01:00
e->encoder = tmp->encoder;
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
e->decoder = tmp->decoder;
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
return e;
}
#if 0
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
static void codec_free(struct codec *c)
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
XFREE(MTYPE_TMP, c->typename);
XFREE(MTYPE_TMP, c);
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
lib: Change frrscript to hold many Lua states Instead of 1 frrscript : 1 lua state, it is changed to 1 : N. The states are hashed with their function names. Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 16:58:21 +02:00
unsigned int lua_function_hash_key(const void *data)
{
const struct lua_function_state *lfs = data;
return string_hash_make(lfs->name);
}
bool lua_function_hash_cmp(const void *d1, const void *d2)
{
const struct lua_function_state *lfs1 = d1;
const struct lua_function_state *lfs2 = d2;
return strmatch(lfs1->name, lfs2->name);
}
void *lua_function_alloc(void *arg)
{
struct lua_function_state *tmp = arg;
struct lua_function_state *lfs =
XCALLOC(MTYPE_SCRIPT, sizeof(struct lua_function_state));
lfs->name = tmp->name;
lfs->L = tmp->L;
return lfs;
}
static void lua_function_free(struct lua_function_state *lfs)
{
XFREE(MTYPE_TMP, lfs->name);
lua_close(lfs->L);
XFREE(MTYPE_TMP, lfs);
}
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
/* Generic script APIs */
lib: Change frrscript_call to call function instead There is some rather heavy error checking logic in frrscript_call. Normally I'd put this in the _frrscript_call function, but the error checking needs to happen before the encoders/decoders in the macro are called. The error checking looks messy but its really just nested ternary expressions insite a larger statement expression. Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:08:18 +02:00
int _frrscript_call_lua(struct lua_function_state *lfs, int nargs)
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: allow passing arguments to scripts - Add ability to pass arguments when calling a script - Add macros to define arguments and results Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:00:26 +01:00
lib: Change frrscript_call to call function instead There is some rather heavy error checking logic in frrscript_call. Normally I'd put this in the _frrscript_call function, but the error checking needs to happen before the encoders/decoders in the macro are called. The error checking looks messy but its really just nested ternary expressions insite a larger statement expression. Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:08:18 +02:00
int ret;
ret = lua_pcall(lfs->L, nargs, 1, 0);
lib: allow passing arguments to scripts - Add ability to pass arguments when calling a script - Add macros to define arguments and results Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:00:26 +01:00
switch (ret) {
lib: add better script error handling Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:33:07 +01:00
case LUA_OK:
break;
lib: allow passing arguments to scripts - Add ability to pass arguments when calling a script - Add macros to define arguments and results Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:00:26 +01:00
case LUA_ERRRUN:
lib: Change frrscript_call to call function instead There is some rather heavy error checking logic in frrscript_call. Normally I'd put this in the _frrscript_call function, but the error checking needs to happen before the encoders/decoders in the macro are called. The error checking looks messy but its really just nested ternary expressions insite a larger statement expression. Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:08:18 +02:00
zlog_err("Lua hook call '%s' : runtime error: %s", lfs->name,
lua_tostring(lfs->L, -1));
lib: allow passing arguments to scripts - Add ability to pass arguments when calling a script - Add macros to define arguments and results Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:00:26 +01:00
break;
case LUA_ERRMEM:
lib: Change frrscript_call to call function instead There is some rather heavy error checking logic in frrscript_call. Normally I'd put this in the _frrscript_call function, but the error checking needs to happen before the encoders/decoders in the macro are called. The error checking looks messy but its really just nested ternary expressions insite a larger statement expression. Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:08:18 +02:00
zlog_err("Lua hook call '%s' : memory error: %s", lfs->name,
lua_tostring(lfs->L, -1));
lib: allow passing arguments to scripts - Add ability to pass arguments when calling a script - Add macros to define arguments and results Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:00:26 +01:00
break;
case LUA_ERRERR:
lib: Change frrscript_call to call function instead There is some rather heavy error checking logic in frrscript_call. Normally I'd put this in the _frrscript_call function, but the error checking needs to happen before the encoders/decoders in the macro are called. The error checking looks messy but its really just nested ternary expressions insite a larger statement expression. Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:08:18 +02:00
zlog_err("Lua hook call '%s' : error handler error: %s",
lfs->name, lua_tostring(lfs->L, -1));
lib: allow passing arguments to scripts - Add ability to pass arguments when calling a script - Add macros to define arguments and results Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:00:26 +01:00
break;
case LUA_ERRGCMM:
lib: Change frrscript_call to call function instead There is some rather heavy error checking logic in frrscript_call. Normally I'd put this in the _frrscript_call function, but the error checking needs to happen before the encoders/decoders in the macro are called. The error checking looks messy but its really just nested ternary expressions insite a larger statement expression. Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:08:18 +02:00
zlog_err("Lua hook call '%s' : garbage collector error: %s",
lfs->name, lua_tostring(lfs->L, -1));
lib: allow passing arguments to scripts - Add ability to pass arguments when calling a script - Add macros to define arguments and results Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:00:26 +01:00
break;
default:
lib: Change frrscript_call to call function instead There is some rather heavy error checking logic in frrscript_call. Normally I'd put this in the _frrscript_call function, but the error checking needs to happen before the encoders/decoders in the macro are called. The error checking looks messy but its really just nested ternary expressions insite a larger statement expression. Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:08:18 +02:00
zlog_err("Lua hook call '%s' : unknown error: %s", lfs->name,
lua_tostring(lfs->L, -1));
lib: allow passing arguments to scripts - Add ability to pass arguments when calling a script - Add macros to define arguments and results Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:00:26 +01:00
break;
}
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
if (ret != LUA_OK) {
lib: Change frrscript_call to call function instead There is some rather heavy error checking logic in frrscript_call. Normally I'd put this in the _frrscript_call function, but the error checking needs to happen before the encoders/decoders in the macro are called. The error checking looks messy but its really just nested ternary expressions insite a larger statement expression. Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:08:18 +02:00
lua_pop(lfs->L, 1);
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
goto done;
lib: allow passing arguments to scripts - Add ability to pass arguments when calling a script - Add macros to define arguments and results Signed-off-by: Quentin Young <qlyoung@nvidia.com>
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
lib: Change frrscript_call to call function instead There is some rather heavy error checking logic in frrscript_call. Normally I'd put this in the _frrscript_call function, but the error checking needs to happen before the encoders/decoders in the macro are called. The error checking looks messy but its really just nested ternary expressions insite a larger statement expression. Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:08:18 +02:00
if (lua_gettop(lfs->L) != 1) {
zlog_err(
"Lua hook call '%s': Lua function should return only 1 result",
lfs->name);
ret = 1;
goto done;
}
if (lua_istable(lfs->L, 1) != 1) {
zlog_err(
"Lua hook call '%s': Lua function should return a Lua table",
lfs->name);
ret = 1;
}
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
done:
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
/* LUA_OK is 0, so we can just return lua_pcall's result directly */
return ret;
}
lib: Add frrscript_get_result Signed-off-by: Donald Lee <dlqs@gmx.com>
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))
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 frrscript_get_result Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-07 15:53:38 +02:00
void *p;
struct lua_function_state *lfs;
struct lua_function_state lookup = {.name = function_name};
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
lib: Add frrscript_get_result Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-07 15:53:38 +02:00
lfs = hash_lookup(fs->lua_function_hash, &lookup);
lib: use appropriate MTYPE for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 05:21:31 +01:00
lib: Add frrscript_get_result Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-07 15:53:38 +02:00
if (lfs == NULL) {
lib: use appropriate MTYPE for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 05:21:31 +01:00
return NULL;
}
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
lib: Add frrscript_get_result Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-07 15:53:38 +02:00
/* results table is idx 1 on the stack, getfield pushes our item to idx
* 2*/
lua_getfield(lfs->L, 1, name);
if (lua_isnil(lfs->L, -1)) {
lua_pop(lfs->L, 1);
zlog_err("No result in results table with that name %s", name);
return NULL;
}
p = lua_to(lfs->L, 2);
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
lib: Add frrscript_get_result Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-07 15:53:38 +02:00
return p;
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
}
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)
{
struct frrscript_codec c = *codec;
if (hash_lookup(codec_hash, &c)) {
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
zlog_backtrace(LOG_ERR);
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
assert(!"Type codec double-registered.");
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
assert(hash_get(codec_hash, &c, codec_alloc));
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_codecs(struct frrscript_codec *codecs)
{
for (int i = 0; codecs[i].typename != NULL; i++)
frrscript_register_type_codec(&codecs[i]);
}
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: create new frrscript_new frrscript_new now creates a new frrscript frrscript_load now loads a function (by allocating a new lua stack) Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:05:37 +02:00
struct frrscript *frrscript_new(const char *name)
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: use appropriate MTYPE for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 05:21:31 +01:00
struct frrscript *fs = XCALLOC(MTYPE_SCRIPT, sizeof(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
lib: use appropriate MTYPE for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 05:21:31 +01:00
fs->name = XSTRDUP(MTYPE_SCRIPT, name);
lib: create new frrscript_new frrscript_new now creates a new frrscript frrscript_load now loads a function (by allocating a new lua stack) Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:05:37 +02:00
fs->lua_function_hash =
hash_create(lua_function_hash_key, lua_function_hash_cmp,
"Lua function state hash");
return fs;
}
int frrscript_load(struct frrscript *fs, const char *function_name,
int (*load_cb)(struct frrscript *))
{
/* Set up the Lua script */
lua_State *L = luaL_newstate();
frrlua_export_logging(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
lib: Prevent possible memory overwrite fname is MAXPATHLEN and scriptdir and fs->name are less then MAXPATHLEN but the combination of those two + the `.lua` are greater than the MAXPATHLEN. Just give us more room to prevent a coding boo boo. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2021-01-24 13:52:55 +01:00
char fname[MAXPATHLEN * 2];
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: create new frrscript_new frrscript_new now creates a new frrscript frrscript_load now loads a function (by allocating a new lua stack) Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:05:37 +02:00
snprintf(fname, sizeof(fname), "%s/%s.lua", scriptdir, fs->name);
int ret = luaL_dofile(L, fname);
lib: add better script error handling Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:33:07 +01:00
switch (ret) {
case LUA_OK:
break;
case LUA_ERRSYNTAX:
lib: better load-time error handling for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 19:21:50 +01:00
zlog_err("Failed loading script '%s': syntax error: %s", fname,
lib: create new frrscript_new frrscript_new now creates a new frrscript frrscript_load now loads a function (by allocating a new lua stack) Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:05:37 +02:00
lua_tostring(L, -1));
lib: add better script error handling Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:33:07 +01:00
break;
case LUA_ERRMEM:
lib: better load-time error handling for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 19:21:50 +01:00
zlog_err("Failed loading script '%s': out-of-memory error: %s",
lib: create new frrscript_new frrscript_new now creates a new frrscript frrscript_load now loads a function (by allocating a new lua stack) Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:05:37 +02:00
fname, lua_tostring(L, -1));
lib: add better script error handling Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:33:07 +01:00
break;
case LUA_ERRGCMM:
lib: better load-time error handling for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 19:21:50 +01:00
zlog_err(
"Failed loading script '%s': garbage collector error: %s",
lib: create new frrscript_new frrscript_new now creates a new frrscript frrscript_load now loads a function (by allocating a new lua stack) Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:05:37 +02:00
fname, lua_tostring(L, -1));
lib: add better script error handling Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:33:07 +01:00
break;
case LUA_ERRFILE:
lib: better load-time error handling for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 19:21:50 +01:00
zlog_err("Failed loading script '%s': file read error: %s",
lib: create new frrscript_new frrscript_new now creates a new frrscript frrscript_load now loads a function (by allocating a new lua stack) Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:05:37 +02:00
fname, lua_tostring(L, -1));
lib: add better script error handling Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:33:07 +01:00
break;
default:
lib: better load-time error handling for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 19:21:50 +01:00
zlog_err("Failed loading script '%s': unknown error: %s", fname,
lib: create new frrscript_new frrscript_new now creates a new frrscript frrscript_load now loads a function (by allocating a new lua stack) Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:05:37 +02:00
lua_tostring(L, -1));
lib: add better script error handling Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:33:07 +01:00
break;
}
if (ret != LUA_OK)
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
goto fail;
lib: create new frrscript_new frrscript_new now creates a new frrscript frrscript_load now loads a function (by allocating a new lua stack) Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:05:37 +02:00
/* Push the Lua function we want */
lua_getglobal(L, function_name);
if (lua_isfunction(L, lua_gettop(L)) == 0)
goto fail;
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
if (load_cb && (*load_cb)(fs) != 0)
goto fail;
lib: create new frrscript_new frrscript_new now creates a new frrscript frrscript_load now loads a function (by allocating a new lua stack) Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:05:37 +02:00
/* Add the Lua function state to frrscript */
struct lua_function_state key = {.name = function_name, .L = L};
hash_get(fs->lua_function_hash, &key, lua_function_alloc);
return 0;
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
fail:
lib: create new frrscript_new frrscript_new now creates a new frrscript frrscript_load now loads a function (by allocating a new lua stack) Signed-off-by: Donald Lee <dlqs@gmx.com>
2021-07-04 17:05:37 +02:00
lua_close(L);
return 1;
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
}
void frrscript_unload(struct frrscript *fs)
{
lib: use appropriate MTYPE for scripts Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 05:21:31 +01:00
XFREE(MTYPE_SCRIPT, fs->name);
XFREE(MTYPE_SCRIPT, 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 support for scripts directory Specify default via --with-scriptdir at compile time, override default with --scriptdir at runtime. If unspecified, it's {sysconfdir}/scripts (usually /etc/frr/scripts) Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 23:37:18 +01:00
void frrscript_init(const char *sd)
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
codec_hash = hash_create(codec_hash_key, codec_hash_cmp,
"Lua type encoders");
lib: allow passing arguments to scripts - Add ability to pass arguments when calling a script - Add macros to define arguments and results Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:00:26 +01:00
lib: add support for scripts directory Specify default via --with-scriptdir at compile time, override default with --scriptdir at runtime. If unspecified, it's {sysconfdir}/scripts (usually /etc/frr/scripts) Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 23:37:18 +01:00
strlcpy(scriptdir, sd, sizeof(scriptdir));
lib: allow passing arguments to scripts - Add ability to pass arguments when calling a script - Add macros to define arguments and results Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-29 08:00:26 +01:00
/* Register core library types */
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
frrscript_register_type_codecs(frrscript_codecs_lib);
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
}
build: HAVE_LUA -> HAVE_SCRIPTING And also guard all scripting-related stuff with HAVE_SCRIPTING. Signed-off-by: Quentin Young <qlyoung@nvidia.com>
2020-11-30 23:01:03 +01:00
#endif /* HAVE_SCRIPTING */
Reference in a new issue Copy permalink