The original algorithm assumed principles not consistent with the RFC
and could have lead to false invalids.
Also added filter tests showing also how the ASPA literals are used in
the static protocol.
Add route attribute gw_mpls_stack to make MPLS stack of route nexthop
accessible from filters. Its type is T_CLIST, which is really not correct
(as it is a list, while T_CLIST is a set). Therefore, we keep this
attribute *undocumented* and it will be *changed* without further notice.
Based on a patch from Trisha Biswas <tbiswas@fastly.com>, thanks!
This merge was particularly difficult. I finally resorted to delete the
symbol scope active flag altogether and replace its usage by other
means.
Also I had to update custom route attribute registration to fit
both the scope updates in v2 and the data model in v3.
Add a new protocol offering route aggregation.
User can specify list of route attributes in the configuration file and
run route aggregation on the export side of the pipe protocol. Routes are
sorted and for every group of equivalent routes new route is created and
exported to the routing table. It is also possible to specify filter
which will run for every route before aggregation.
Furthermore, it will be possible to set attributes of new routes
according to attributes of the aggregated routes.
This is a work in progress.
Original work by Igor Putovny, subsequent cleanups and finalization by
Maria Matejka.
Undefined paths and clists should use typed f_val with empty adata
instead of just void f_val. Use common initializer to handle both
variables and eattrs.
- Extend method descriptors with type signature
- Daisy chain method descriptors for the same symbol
- Dispatch methods for same symbol based on type signature
- Split add/delete/filter operations to multiple methods
- Replace ad-hoc dispatch of old-style syntax with scope-based dispatch
- Also change method->arg_num to count initial arg
It still needs some improvements, like better handling of untyped
expressions and better error reporting when no dispatch can be done.
The multiple dispatch could also be extended to dispatch regular
function-like expressions in a uniform way.
Methods can now be called as x.m(y), as long as x can have its type
inferred in config time. If used as a command, it modifies the object,
if used as a value, it keeps the original object intact.
Also functions add(x,y), delete(x,y), filter(x,y) and prepend(x,y) now
spit a warning and are considered deprecated.
It's also possible to call a method on a constant, see filter/test.conf
for examples like bgp_path = +empty+.prepend(1).
Inside instruction definitions (filter/f-inst.c), a METHOD_CONSTRUCTOR()
call is added, which registers the instruction as a method for the type
of its first argument. Each type has its own method symbol table and
filter parser switches between them based on the inferred type of the
object calling the method.
Also FI_CLIST_(ADD|DELETE|FILTER) instructions have been split to allow
for this method dispatch. With type inference, it's now possible.
The previous approach (use VOID constant for variable initialization)
failed due to dynamic type check failure.
Thanks to Alexander Zubkov <green@qrator.net> for the bugreport.
- Rename BYTESTRING lexem to BYTETEXT, not to collide with 'bytestring' type name
- Add bytestring type with id T_BYTESTRING (0x2c)
- Add from_hex() filter function to create bytestring from hex string
- Add filter test cases for bytestring type
Minor changes by committer.
