![]() 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> |
||
---|---|---|
.github | ||
alpine | ||
babeld | ||
bfdd | ||
bgpd | ||
debian | ||
doc | ||
docker | ||
eigrpd | ||
fpm | ||
gdb | ||
grpc | ||
include | ||
isisd | ||
ldpd | ||
lib | ||
m4 | ||
mlag | ||
nhrpd | ||
ospf6d | ||
ospfclient | ||
ospfd | ||
pbrd | ||
pimd | ||
pkgsrc | ||
python | ||
qpb | ||
redhat | ||
ripd | ||
ripngd | ||
sharpd | ||
snapcraft | ||
staticd | ||
tests | ||
tools | ||
vrrpd | ||
vtysh | ||
watchfrr | ||
yang | ||
zebra | ||
.clang-format | ||
.dir-locals.el | ||
.dockerignore | ||
.git-blame-ignore-revs | ||
.gitignore | ||
bootstrap.sh | ||
buildtest.sh | ||
changelog-auto.in | ||
config.version.in | ||
configure.ac | ||
COPYING | ||
COPYING-LGPLv2.1 | ||
Makefile.am | ||
README.md | ||
stamp-h.in |
FRRouting
FRR is free software that implements and manages various IPv4 and IPv6 routing protocols. It runs on nearly all distributions of Linux and BSD and supports all modern CPU architectures.
FRR currently supports the following protocols:
- BGP
- OSPFv2
- OSPFv3
- RIPv1
- RIPv2
- RIPng
- IS-IS
- PIM-SM/MSDP
- LDP
- BFD
- Babel
- PBR
- OpenFabric
- VRRP
- EIGRP (alpha)
- NHRP (alpha)
Installation & Use
For source tarballs, see the releases page.
For Debian and its derivatives, use the APT repository at https://deb.frrouting.org/.
Instructions on building and installing from source for supported platforms may be found in the developer docs.
Once installed, please refer to the user guide for instructions on use.
Community
The FRRouting email list server is located here and offers the following public lists:
Topic | List |
---|---|
Development | dev@lists.frrouting.org |
Users & Operators | frog@lists.frrouting.org |
Announcements | announce@lists.frrouting.org |
For chat, we currently use Slack. You can join by clicking the "Slack" link under the Participate section of our website.
Contributing
FRR maintains developer's documentation which contains the project workflow and expectations for contributors. Some technical documentation on project internals is also available.
We welcome and appreciate all contributions, no matter how small!
Security
To report security issues, please use our security mailing list:
security [at] lists.frrouting.org