gnrc_networking: run as host per default#21119
gnrc_networking: run as host per default#21119OlegHahm wants to merge 2 commits intoRIOT-OS:masterfrom
Conversation
| USEMODULE += gnrc_rpl | ||
| USEMODULE += auto_init_gnrc_rpl |
There was a problem hiding this comment.
It still might be worth to have hosts in there as RPL leafs.
There was a problem hiding this comment.
Do you have any particular use case in mind?
There was a problem hiding this comment.
Well if you have a gnrc_networking router you might want it to also see the hosts (so they need to be a RPL leaf, i.e, keep the gnrc_rpl modules in regardless ;-))
There was a problem hiding this comment.
Also: IIRC this is currently our only real RPL example, so why remove it?
There was a problem hiding this comment.
Ah, locally I have examples/gnrc_networking_rpl but that's not upstream (anymore?).
Anyhow, I made it optional now.
There was a problem hiding this comment.
That was never upstream, it was part of #14623
But yea a dedicated RPL example would be better IMHO
| # Specify the mandatory networking module for a IPv6 routing node | ||
| USEMODULE += gnrc_ipv6_router_default | ||
| # Add a routing protocol | ||
| USEMODULE += gnrc_rpl | ||
| USEMODULE += auto_init_gnrc_rpl | ||
| # Specify the mandatory networking module for a IPv6 host node | ||
| USEMODULE += gnrc_ipv6_default |
There was a problem hiding this comment.
Why remove the router “feature” altogether? I would prefer a
ROUTER ?= 0switch
There was a problem hiding this comment.
Sounds like a good idea. 👍
Introduce a Makefile variable for enabling RPL and/or routing functionality.
OlegHahm
force-pushed
the
pr/gnrc_networking_host_only
branch
from
af004ee to
fb2c5c3
Compare
|
|
||
| # Optionally include the RPL routing protocol (particular useful if not all | ||
| # nodes are within radio transmission range to the border router) | ||
| USE_RPL ?= 0 |
There was a problem hiding this comment.
| USE_RPL ?= 0 | |
| USE_RPL ?= 1 |
I see no reason (except that the border router is not automatically initialized as RPL root) to make this opt-in.
There was a problem hiding this comment.
Hm, how often have you (or anyone else) used RPL with this example?
The biggest arguments for disabling RPL here for meare reduced complexity and reduced code size.
gnrc_coap and gnrc_networking_mac (for some reason) do include RPL.
There was a problem hiding this comment.
Hm, how often have you (or anyone else) used RPL with this example?
That's exactly my point. Everyone who uses this example currently uses RPL to a degree. Without it, the user base would shrink significantly, which would increase bit rot.
There was a problem hiding this comment.
Not sure to which degree RPL is used in these scenarios (apart from trickle timers and the like). But I sense that we need a more general discussion with a broader range of the community about the purpose of this (and the other example applications) first. Currently, I would prefer this application as a simple host application and rather introduce a dedicated RPL example application.
4 participants
Contribution description
The assumption: typically a user wants to deploy the
gnrc_networkingapplications on terminal nodes.Configuring the node as a router makes the application more complex and requires more memory. Problems may arise, for instance, because the node will start to send out RAs. For RPL we have separate example applications.
Hence, this PR changes the IPv6 role of the
gnrc_networkingapplication from a router to a host and disables RPL.As a bonus this saves about 16k ROM and 2k RAM - which may be used to enable DNS resolution instead.
Testing procedure
Run
gnrc_networkingon native or real hardware like you have always done and check if everything works as usual.