Patch for RAdv documentation for a new custom option.
I was also thinking about the new bytestring type. I needed tho change
BYTESTRING -> BYTETEXT to avoid collision. But probably the better
variant would be to name the new type for example "binary", it might
sound better. What do you think? As far as I see, the name
"bytestring" has not been used yet outside of the code.
Also found a small issue with my patches in "conf/confbase.Y" when
compiling with relatively old gcc. It complains on the value
definitions inside the switch statement:
case T_STRING:
int len = strlen(val.val.s);
struct bytestring *bs = cfg_allocz(sizeof(*bs) + len);
I can prepare a new set of patches or you can fix it ad-hoc.
On Thu, Jun 29, 2023 at 1:59 PM Alexander Zubkov <gr...@qrator.net> wrote:
>
> On Tue, Jun 27, 2023 at 2:13 AM Alexander Zubkov <gr...@qrator.net> wrote:
> >
> > On Mon, Jun 26, 2023 at 5:54 PM Alexander Zubkov <gr...@qrator.net> wrote:
> > >
> > > On Mon, Jun 26, 2023 at 5:43 PM Ondrej Zajicek <santi...@crfreenet.org>
> > > wrote:
> > > >
> > > > On Mon, Jun 26, 2023 at 03:24:47AM +0200, Alexander Zubkov wrote:
> > > > > On Sat, Jun 24, 2023 at 3:16 PM Ondrej Zajicek
> > > > > <santi...@crfreenet.org> wrote:
> > > > > >
> > > > > > On Sat, Jun 24, 2023 at 02:20:03AM +0200, Alexander Zubkov wrote:
> > > > > > > > Yes, the original idea there was to add bytestring as a data
> > > > > > > > type, make
> > > > > > > > hex() a regular (filter) function instead of special
> > > > > > > > function-like
> > > > > > > > syntax, and add equivalent of 'expr' grammar term for other
> > > > > > > > data types.
> > > > > > > >
> > > > > > >
> > > > > > > I see. I think I can look into preparing a patch for that too.
> > > > > > > But for such variant I would suggest using function names like
> > > > > > > "from_hex/base64" instead of "hex/base64", or something including
> > > > > > > bytestring reference: "bs_hex". Because the simple variants could
> > > > > > > be
> > > > > > > misleading when used not only in the limited set of scopes.
> > > > > > > they can be thought of converting to hex/base64 representation
> > > > > > > too. Or they
> > > > > > > could collide with "hex" function to convert from string to int,
> > > > > > > which
> > > > > > > someone would need to implement in the future.
> > > > > >
> > > > > > Yes, that is true.
> > > > > >
> > > > > > You can try it if you are brave enough to add new f_val type.
> > > > >
> > > > > Take a look at the patch, please. Waiting for the critics and
> > > > > improvement suggestions.
> > > >
> > > > Hi
> > > >
> > > > It looks pretty good. First, could you split it to at least four
> > > > patches?
> > >
> > > Sure. I'll provide split patches later.
> > >
> > > >
> > > > 1) unrelated changes, like the newline-in-string-constant
> > > > 2) preparatory changes (functions in lib/bytestring.c, change to
> > > > BYTESTRING lexer)
> > > > 3) adding bytestring type to filter code (including FI_FROM_HEX inst)
> >
> > Added patches up to this point. There are also some fixes and
> > modification. For example, I noted that 'bytestring' symbol for the
> > type name conflicts with lexer's BYTESTRING id. So I had to rename
> > lexer's BYTESTRING to BYTETEXT (like it is done for strings).
> > For the following patches it is better to decide the structure of the
> > new *eval* functions.
> >
> > > > 4) change to parser related to f_eval_val(), bytestring nonterminal and
> > > > so on.
>
> Final patches to modify current f_eval_int() to generic approach. And
> for nonterminal bytestring.
> Again, waiting for comments/suggestions. Also feel free, of course, to
> fix naming/etc when applying.
> Next, I will be able to move forward with patches to the documentation.
>
> > > >
> > > > Some more comments:
> > > >
> > > > > It was needed to add another function like f_eval_int(), so I decided
> > > > > to do some more generic approach and replaced all occurences of
> > > > > f_eval_int() with it.
> > > >
> > > > That is good approach, although it would be probably better to call this
> > > > function like cf_eval(), associated macro as cf_eval_val, and keep some
> > > > inline functions like cf_eval_int(), cf_eval_bs() and so on.
> > > >
> > > > Or perhaps cf_eval() could return f_val as return value, and have
> > > > shorthand functions like:
> > > >
> > > > static inline cf_eval_int(..) { return cf_eval(.., T_INT).i; }
> >
> > I actually tried first to return the struct instead of modifying it by
> > a reference. But for that we need to have "struct f_val" known in
> > filter/filter.h, which is defined in filter/data.h. But that causes
> > some circular dependencies problem. I didn't dig deep into it, but
> > maybe it is possible to solve the conflict in a clean way.
>
> Looked at it again. It seems safe to include filter/data.h into
> filter/filter.h. I probably had problems when trying to incude it
> somewhere else, until it all finalized into filter.h
>
> >
> > > >
> > > > I will give more comments later.
> > > >
> > > > --
> > > > Elen sila lumenn' omentielvo
> > > >
> > > > Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
> > > > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> > > > "To err is human -- to blame it on a computer is even more so."
From 70aaade32e4f32f08e2b6c297b9bf4d3b7f862d2 Mon Sep 17 00:00:00 2001
From: Alexander Zubkov <gr...@qrator.net>
Date: Fri, 30 Jun 2023 01:03:05 +0200
Subject: [PATCH] Doc: document RAdv "custom option" configuration definition
---
doc/bird.sgml | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/doc/bird.sgml b/doc/bird.sgml
index 8041faa9..81568b95 100644
--- a/doc/bird.sgml
+++ b/doc/bird.sgml
@@ -4549,6 +4549,21 @@ definitions, prefix definitions and DNS definitions:
options and there is a short variant <cf>dnssl <m/domain/</cf> that just
specifies one DNS search domain.
+ <tag><label id="radv-custom">custom option type <m/number/ value <m/binary/</tag>
+ Custom option definitions allow to define an arbitrary option
+ to advertise. You need to specify the option type number and the binary
+ payload of the option. The length field is calculated automatically.
+ Like <cf/rdnss/ above, multiple definitions are cumulative, they can be
+ used also as interface-specific options.
+
+ The following example advertises PREF64 option (<rfc id="8781">) with
+ prefix <cf>2001:db8:a:b::/96</cf> and the lifetime of <cf/1 hour/:
+
+ <label id="radv-custom-exam">
+<p><code>
+custom option type 38 value hex:0e10:2001:0db8:000a:000b:0000:0000
+</code>
+
<tag><label id="radv-trigger">trigger <m/prefix/</tag>
RAdv protocol could be configured to change its behavior based on
availability of routes. When this option is used, the protocol waits in
@@ -4678,6 +4693,10 @@ definitions, prefix definitions and DNS definitions:
<tag><label id="radv-iface-dnssl-local">dnssl local <m/switch/</tag>
Use only local DNSSL definitions for this interface. See <cf/rdnss local/
option above. Default: no.
+
+ <tag><label id="radv-iface-custom-local">custom option local <m/switch/</tag>
+ Use only local custom option definitions for this interface. See <cf/rdnss local/
+ option above. Default: no.
</descrip>
<p>Prefix specific options
--
2.41.0
