gnrc/sixlowpan: add deprecation note for GNRC_SIXLOWPAN_FRAG_RBUF_AGGRESSIVE_OVERRIDE#13129
Conversation
Both possible configurations should be checked, I would say. However, I don't get why we need to invert the logic here and moreover remove support already for it (the title says "deprecate", but you remove the |
|
(and adhere to our established deprecation process) |
|
Something like /**
* ...
*/
#ifndef GNRC_SIXLOWPAN_FRAG_RBUF_KEEP_ENTRIES
#define GNRC_SIXLOWPAN_FRAG_RBUF_KEEP_ENTRIES (0)
#endif
/**
* @brief ...
* @deprecated Use inverse `GNRC_SIXLOWPAN_FRAG_RBUF_KEEP_ENTRIES` with instead.
* Will be removed after 2020.10 release.
*/
#ifndef GNRC_SIXLOWPAN_FRAG_RBUF_AGGRESSIVE_OVERRIDE
#ifdef GNRC_SIXLOWPAN_FRAG_RBUF_KEEP_ENTRIES
#define GNRC_SIXLOWPAN_FRAG_RBUF_AGGRESSIVE_OVERRIDE (!GNRC_SIXLOWPAN_FRAG_RBUF_KEEP_ENTRIES)
#else /* GNRC_SIXLOWPAN_FRAG_RBUF_KEEP_ENTRIES */
#define GNRC_SIXLOWPAN_FRAG_RBUF_AGGRESSIVE_OVERRIDE (1)
#endif /* GNRC_SIXLOWPAN_FRAG_RBUF_KEEP_ENTRIES */
#endif |
|
Also |
9e6026e to
f57ced3
Compare
|
@miri64 like that? I rebuild the doc and executed the above ping command running examples/gnrc_networking on the iotlab testbed with |
|
Yepp. Still don't like the name of the new macro though (and still don't have a better name :-() |
|
|
|
f57ced3 to
46325ca
Compare
|
@miri64 thanks for the immediate feedback. I changed the name accordingly and squashed right away. |
|
@miri64 is the status OK for you? |
| * | ||
| * When not set, it will cause the reassembly buffer to | ||
| * override the oldest entry no matter what. When set, only the oldest | ||
| * entry that is older than @ref GNRC_SIXLOWPAN_FRAG_RBUF_TIMEOUT_US will be |
There was a problem hiding this comment.
No... "When set, only incomplete entries that are older than ...TIMEOUT_US will be removed from the reassembly buffer." If and only if you want to keep the information that lingering entries are also removed, you can add something like "On creation of a new entry the timeout period of older entries is also checked."
|
Also, please adapt the PR title for this PR to the current state for future reference. |
|
@miri64, @leandrolanzieri please look at my latest changes |
| * overwritten (they will still timeout normally if reassembly buffer is not | ||
| * full). | ||
| * | ||
| * @deprecated Use inverse `GNRC_SIXLOWPAN_FRAG_RBUF_DO_NOT_OVERRIDE` with instead. |
There was a problem hiding this comment.
| * @deprecated Use inverse `GNRC_SIXLOWPAN_FRAG_RBUF_DO_NOT_OVERRIDE` with instead. | |
| * @deprecated Use inverse of `GNRC_SIXLOWPAN_FRAG_RBUF_DO_NOT_OVERRIDE` instead. |
?
There was a problem hiding this comment.
Also @ref GNRC_SIXLOWPAN_FRAG_RBUF_DO_NOT_OVERRIDE is safer, as this way Doxygen checks if the variable exists (and also creates a link).
|
@leandrolanzieri, @miri64 I addressed your comments. Can I squash? |
miri64
left a comment
There was a problem hiding this comment.
For my part you can squash (including the fixes for the comments below).
f59d24c to
688c5f6
Compare
|
Applied @miri64's suggested changes and squashed |
|
You can remove the multiple 'Co-Authored-By:' definitions from the commit message. I don't really need the attribution :D (if you insist, please use my FU mail address). |
leandrolanzieri
left a comment
There was a problem hiding this comment.
Documentation looks good and GNRC_SIXLOWPAN_FRAG_RBUF_AGGRESSIVE_OVERRIDE has the expected values with and without defining GNRC_SIXLOWPAN_FRAG_RBUF_DO_NOT_OVERRIDE. ACK.
688c5f6 to
c7b6dc5
Compare
|
I saw green lights for a short moment now lets see if removing the co-authorship changes something |
|
And go. |
Contribution description
When migrating configurations to Kconfig in #13123 we found that
GNRC_SIXLOWPAN_FRAG_RBUF_AGGRESSIVE_OVERRIDEis a simple on/off switch which should be represented as a boolean. In Kconfig, a symbol is defined when enabled and it is not generated at all when disabled. In the latter case, the value would be set anyway in the config file :Offline we agreed with @jia200x and @leandrolanzieri that inverting the logic of the macro is the cleanest solution to this problem. As the semantics change, we changed the macro name and added a compile time error in case someone tries to use the old macro and we added a deprecation note to the documentation.
Testing procedure
make docand check if documentation looks alright.ping6 -c 10 -i 1000 -s 1000 <IPv6 dst addr>.CFLAGS=-DGNRC_SIXLOWPAN_FRAG_RBUF_KEEP_ENTRIES=1and re-run 2. on nodes.Issues/PRs references
#12888, #13123