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
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
