Skip to content

Conversation

miri64
Copy link
Member

@miri64 miri64 commented Oct 23, 2018

Contribution description

This moves all implementation specific parts of the ipv6_ext_rh module to gnrc_ipv6_ext_rh.

It also removes a module that isn't used after this change and doesn't contain any code (but isn't a pseudo-module for some reason).

Testing procedure

Try to compile gnrc_networking with USEMODULE = gnrc_rpl_srh. It should still work.

Also (at least when run without DEBUG) tests/gnrc_ipv6_ext should still work without crashing (I will rework them once the integration process progressed).

Issues/PRs references

Addresses parts of #10133

PR dependencies

@miri64 miri64 added Area: network Area: Networking Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation Process: API change Integration Process: PR contains or issue proposes an API change. Should be handled with care. labels Oct 23, 2018
@miri64 miri64 requested a review from cgundogan October 23, 2018 18:03
@miri64 miri64 force-pushed the gnrc_ipv6_ext/enh/move-rh-to-gnrc branch 2 times, most recently from 56fdbf7 to 97784fe Compare October 23, 2018 18:08
miri64 added a commit to miri64/RIOT that referenced this pull request Oct 23, 2018
miri64 added a commit to miri64/RIOT that referenced this pull request Oct 23, 2018
miri64 added a commit to miri64/RIOT that referenced this pull request Oct 24, 2018
@miri64
Copy link
Member Author

miri64 commented Oct 24, 2018

@bergzand could you maybe have a look (if doesn't intervene with the current release cycle)? @cgundogan is currently on vacation and this PR is giving me a really hard time, when I try to rebase #10238 on top of it and #10234 (which I do for testing).

@miri64 miri64 force-pushed the gnrc_ipv6_ext/enh/move-rh-to-gnrc branch from f251de6 to 5683c4e Compare October 24, 2018 19:08
@miri64
Copy link
Member Author

miri64 commented Oct 24, 2018

Rebased and squashed current state, so tracking during the review is easier.

@miri64 miri64 force-pushed the gnrc_ipv6_ext/enh/move-rh-to-gnrc branch from 5683c4e to 90607e3 Compare October 24, 2018 19:22
@miri64
Copy link
Member Author

miri64 commented Oct 24, 2018

I also made my train of thought a little clearer by splitting out one commit (the second one, 692eaa0 while I was writing this) of another.

miri64 added a commit to miri64/RIOT that referenced this pull request Oct 24, 2018
@bergzand bergzand self-assigned this Oct 25, 2018
@bergzand bergzand self-requested a review October 25, 2018 08:06
@bergzand
Copy link
Member

The motivation for this change is to have these functions inside GNRC so that the structs/arguments can be kept GNRC-specific?

Copy link
Member

@bergzand bergzand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First review iteration here.

@miri64
Copy link
Member Author

miri64 commented Oct 25, 2018

The motivation for this change is to have these functions inside GNRC so that the structs/arguments can be kept GNRC-specific?

Yes, and also that ipv6_ext_rh_process() should have never been outside of GNRC (the non-GNRC modules are just thought to be used for header parsing), as it straight jumps back into GNRC (for RPL SRH processing). Also there is a "GNRC-version" of this function which just adds another indirection that isn't necessary (see #10238).

Copy link
Member

@bergzand bergzand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few more nits.

GNRC_IPV6_EXT_RH_OK = 0,
/**
* @brief The routing header was successfully processed and the packet
* was forwarded or should be forwarded by the central RH handler.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something that "was forwarded" could have this node as destionation right? Does the GNRC_IPV6_EXT_RH_OK have priority over this result?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you rephrase this? I'm not sure I understand.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I get it now

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'm interpreting the "was forwarded" here not correct. To me it sounds as if a frame was forwarded by another node to this node. Where at that point both the conditions from this documentation and the option currently renamed to GNRC_IPV6_EXT_RH_AT_DST match the frame.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it was both forwarded to this node and at the destination.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the documentation update clarifies it better.

* @brief The routing header was successfully processed and this node
* is the destination
*/
GNRC_IPV6_EXT_RH_OK = 0,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to change the name here to something that indicates that the current node is the destination such as GNRC_IPV6_EXT_RH_DEST (Feel free to change to something that makes more sense to you, my lack of coffee prevents me from thinking of a sensible name)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GNRC_IPV6_EXT_RH_AT_DST?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(since this enum values are providing the most headache when rebasing, this will be fun to rename ;-D, but I think you are right regarding the naming)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry :(

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@miri64
Copy link
Member Author

miri64 commented Oct 25, 2018

I changed the order of the enum, as it makes more sense when = 0 is the error and > 0 one of the two success cases.

@miri64
Copy link
Member Author

miri64 commented Oct 25, 2018

I just noticed, that I did a terrible mistake with my fixup commits. May I squash?

@bergzand
Copy link
Member

May I squash?

Ack

@miri64 miri64 force-pushed the gnrc_ipv6_ext/enh/move-rh-to-gnrc branch from eab20ad to e9fa72e Compare October 25, 2018 09:06
@miri64
Copy link
Member Author

miri64 commented Oct 25, 2018

Squashed

Those return values are internal anyway, and they have the same intent
as the one provided by `gnrc_ipv6_ext_rh`.
@miri64 miri64 force-pushed the gnrc_ipv6_ext/enh/move-rh-to-gnrc branch from e9fa72e to ad183db Compare October 25, 2018 09:12
@miri64
Copy link
Member Author

miri64 commented Oct 25, 2018

I put the rename of _OK to _AT_DST to its own commit for clarity in case someone reviews the git history later ;-).

@bergzand bergzand added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Oct 25, 2018
Copy link
Member

@bergzand bergzand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested, ACK

@miri64
Copy link
Member Author

miri64 commented Oct 25, 2018

@jia200x since this is an API change (and thus high-impact IMHO) I would merge this right after feature freeze (i.e. when you forked the release branch). Are you alright with that?

@jia200x
Copy link
Member

jia200x commented Oct 25, 2018

@jia200x since this is an API change (and thus high-impact IMHO) I would merge this right after feature freeze (i.e. when you forked the release branch). Are you alright with that?

Yes, I'm alright ;)

@miri64
Copy link
Member Author

miri64 commented Oct 25, 2018

Adapted the unittests for the value name changes as well.

@miri64
Copy link
Member Author

miri64 commented Oct 25, 2018

Release is feature frozen, so I'm merging this now.

@miri64 miri64 merged commit 466bc34 into RIOT-OS:master Oct 25, 2018
@miri64 miri64 deleted the gnrc_ipv6_ext/enh/move-rh-to-gnrc branch October 25, 2018 20:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: network Area: Networking CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Process: API change Integration Process: PR contains or issue proposes an API change. Should be handled with care. Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants