Hi,
And the final patch for the bytestring documentation. Also slightly
modified radv documentation patch - added a semicolon in the end of
the example.
I actually would prefer the "binary" name for the type more than
"bytestring". Or maybe you have something else on your mind. So if you
would also like not to name it "bytestring", I can alter the pathes
for it.
On Fri, Jun 30, 2023 at 1:21 AM Alexander Zubkov <gr...@qrator.net> wrote:
>
> 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."
commit 67bde727bdf883dd2dc4b03354b846bab7ef1fdb
Author: Alexander Zubkov <gr...@qrator.net>
Date: Fri Jun 30 01:03:05 2023 +0200
Doc: document RAdv "custom option" configuration definition
diff --git a/doc/bird.sgml b/doc/bird.sgml
index 8041faa9..8aacaf68 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
commit 32f5b89d8fed093f475bd283b745a19b9ed9924a
Author: Alexander Zubkov <gr...@qrator.net>
Date: Fri Jul 7 00:45:13 2023 +0200
Doc: document bytestring type
diff --git a/doc/bird.sgml b/doc/bird.sgml
index 8aacaf68..c7b37160 100644
--- a/doc/bird.sgml
+++ b/doc/bird.sgml
@@ -838,7 +838,7 @@ agreement").
protocol packets are processed in the local TX queues. This option is
Linux specific. Default value is 7 (highest priority, privileged traffic).
- <tag><label id="proto-pass">password "<m/password/" | <m/hex_key/ [ { <m>password options</m> } ] </tag>
+ <tag><label id="proto-pass">password "<m/password/" | <m/bytestring/ [ { <m>password options</m> } ] </tag>
Specifies a password that can be used by the protocol as a shared secret
key. Password option can be used more times to specify more passwords.
If more passwords are specified, it is a protocol-dependent decision
@@ -846,10 +846,8 @@ agreement").
authentication is enabled, authentication can be enabled by separate,
protocol-dependent <cf/authentication/ option.
- A password can also be specified as a hexadecimal key. <m/hex_key/ is a
- sequence of hexadecimal digit pairs, optionally colon-separated. A key
- specified this way must be at least 16 bytes (32 digits) long (although
- specific algorithms can impose other restrictions).
+ A password can be specified as a string or as a sequence of bytes
+ (<cf/bytestring/).
This option is allowed in BFD, OSPF, RIP, and Babel protocols. BGP has
also <cf/password/ option, but it is slightly different and described
@@ -1387,6 +1385,28 @@ in the foot).
!˜/) operators could be used to match a string value against
a shell pattern (represented also as a string).
+ <tag><label id="type-bytestring">bytestring</tag>
+ This is a sequences of arbitrary bytes. There are no ways to modify
+ bytestrings in filters. You can pass them between function, assign
+ them to variables of type <cf/bytestring/, print such values,
+ compare bytestings (<cf/=, !=/). Bytestring literals are written
+ in several ways:
+
+ A sequence of hexadecimal digit pairs, optionally colon-separated.
+ A bytestring specified this way must be at least 16 bytes (32 digits)
+ long: <cf/01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef/ or
+ <cf/0123456789abcdef0123456789abcdef/.
+
+ A sequence of hexadecimal digit pairs of any lengh (including zero)
+ with the <cf/hex:/ prefix. Colon separators can be inserted
+ arbitrarily between any bytes: <cf/hex:/, <cf/hex:1234/,
+ <cf/hex:1234:56:78/.
+
+ A bytestring can be made from a hex string using <cf/from_hex()/
+ function. Source strings can contain multiple lines, use any
+ whitespaces or symbols as byte separators:
+ <cf/from_hex(" 1234 56:78 ab-cd-ef ")/.
+
<tag><label id="type-ip">ip</tag>
This type can hold a single IP address. The IPv4 addresses are stored as
IPv4-Mapped IPv6 addresses so one data type for both of them is used.
@@ -4549,7 +4569,7 @@ 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>
+ <tag><label id="radv-custom">custom option type <m/number/ value <m/bytestring/</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.
