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>

1 files changed, 2 insertions, 0 deletions

diff --git a/lib/subdir.am b/lib/subdir.am
index 038282a99b..c5e32a56d9 100644
--- a/lib/subdir.am
+++ b/lib/subdir.am
@@ -26,6 +26,7 @@ lib_libfrr_la_SOURCES = \
 	lib/filter_nb.c \
 	lib/frrcu.c \
 	lib/frrlua.c \
+	lib/frrscript.c \
 	lib/frr_pthread.c \
 	lib/frrstr.c \
 	lib/getopt.c \
@@ -184,6 +185,7 @@ pkginclude_HEADERS += \
 	lib/filter.h \
 	lib/freebsd-queue.h \
 	lib/frrlua.h \
+	lib/frrscript.h \
 	lib/frr_pthread.h \
 	lib/frratomic.h \
 	lib/frrcu.h \