[riot-devel] Plans for switching over to a new network infrastructure in GNRC

Martine Lenders m.lenders at fu-berlin.de
Wed Nov 1 16:26:22 CET 2017


FYI there is a re-integration PR now:


2017-10-27 17:56 GMT+02:00 Martine Lenders <m.lenders at fu-berlin.de>:

> 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_t` and 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 `nib`
> command 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20171101/2f991f07/attachment.html>

More information about the devel mailing list