Hi all,
after the release is before the release, so let’s use the drive to continue the good work.
Some of you might have noticed, that we are currently working on a big switch-over for GNRC-internal APIs, so if you are not involved in any direct GNRC programming or need access to the network interfaces this won’t most likely only affect you a little bit (the calls how to get an interface ID will change – actually simplify ;-)) to not at all.
This is quite a massive step, since basically most of the files that are doing operations on, or related to network interfaces (i.e. IPv6, 6LoWPAN, MAC and routing protocols) need to be touched. In addition we decided to integrate this network interface layer directly with the new, shiny and fixed neighbor discovery which saves us a lot of integration work into old stuff, but doesn’t make things easier. Some of that work is already done and in master, but most of it will take some time to adapt.
This is why we (the RIOT maintainers) decided to go a slightly different route than usual: we made a feature branch where all the integration work (and testing) for the new components will happen [1] and made a 1-2 week plan to get this branch re-merged into master as fast as possible. In that time this feature branch exist merging new changes to GNRC into master is highly discouraged to not risk merge conflicts in the gnrc_netif2_integration/master branch. We will notify you again when this embargo is lifted.
So what changes after all this is done (I call the new interface API gnrc_netif2 here, but in the final result it will be called just gnrc_netif):
- Network interfaces:
- Simplification of GNRC’s network interface architecture: currently there are 4 APIs (gnrc_netdev, gnrc_netif, gnrc_ipv6_netif, and gnrc_sixlowpan_netif) that represent network interfaces in some kind or form. This makes things complicated if you need e.g. in NDP information that is both device dependent (e.g. link-layer address) and IPv6 dependent (e.g. IPv6 address). This is why gnrc_netif2 merges all these APIs into one single API.
- Tighter integration into GNRC’s principles: For most device related options interfaces worked like any other GNRC module and used NETAPI, but when it came to other stuff, like IPv6 addresses or 6LoWPAN configuration, other APIs were used. With gnrc_netif2 all options can be set via NETAPI.
- Better thread synchronization: apart from the the fact that GNRC-externally the options are now set over NETOPT (i.e. in the thread context of the interface) we also use recursive mutexes GNRC-internally now to better synchronize the access to the interface. In the previous implementation normal mutexes were used (requiring some dangerous unlocking in the middle of an operation) or no mutexes were used at all.
- Easier to extend: If you want to provide a new MAC protocol to GNRC you don’t have to copy all the thread-handler stuff anymore. Just implement the operations provided in
gnrc_netif2_ops_tand let gnrc_netif2 do the rest ;-).
- new neighbor discovery:
- In comparison to the old neighbor discovery the new was designed more thoughtfully so it easier to maintain.
- Most issues with the old neighbor discovery were fixed (because with the new design we actually were able to pinpoint issues within minutes, not within days as with the old NDP)
- For the end-user the shell commands will change slightly: manipulations of the neighbor cache and FIB now are done using the
nibcommand instead of a wide variety of commands.
I hope that’s all.
If you have further questions, don’t be afraid to ask.
Cheers, Martine
[1] https://github.com/RIOT-OS/RIOT/tree/gnrc_netif2_integration/master