net/gnrc_netif: opt of _ipv6_get_iid()

[haukepetersen]

Contribution description

While integrating NimBLE into GNRC, I am working my way through gnrc_netif, trying to implement it for NimBLE. Looking at the gnrc_netif code, there is quite some room for optimization...

I could not find anything about this on a quick search - so if I am addressing something that is already addressed somewhere else, simply ignore my renting and close this PR :-)

This PR focuses on the gnrc_netif_ipv6_get_iid() function: why are we duplicating all the generating code here, even on multiple layers? Event inside this one function there is a whole code block of 8 lines duplicated...

So to row back: as far as I can see, almost all(?) netdev implementations are actually allowing to get the IID through the NETOPT_IPV6_IID option. So why don't we just use that here?

This PR takes a first step, by using the NETOPT_IPV6_IID option to get the IID from the netdev device. If successful, we are done. If not, we proceed with the existing code.

As a follow up I would imagine, we should be able to get rid of the whole else part by only depending on getting NETOPT_IPV6_IID, right?! This would save quite some unnecessary link layer dependencies into netif. And not to mention some saved ROM :-)

Testing procedure

Run some tests using the gnrc_networking example for different link layer devices, checking the generated link local addresses carefully.

Issues/PRs references

none

[miri64]

The idea behind gnrc_netif_ipv6_get_iid() is to remove that code out of the netdev layer, as IMHO it doesn't belong there but in the interface layer.

[miri64]

I mean, why do device drivers need to implement an IPv6-interface-specific function?

[haukepetersen]

hm, I do disagree! Of course one can argue if it belongs into the link layer code / device driver or better somewhere higher as in netif.

But I see some good reasons to leave it in the netdev implementations:

• netif is not used by all network stacks, leading to potential code duplication (again)
• getting the IID via netdev is code-wise the much cleaner approach, just look at the ifdef-hell in the current gnrc_netif code...
• having this function in the netdev implementations does not mean each driver has to implement it -> see netdev_ieee802154...

[haukepetersen]

I mean, why do device drivers need to implement an IPv6-interface-specific function?

Academically speaking this might be true, but in practical software design, especially looking at our architecture, it makes much sense to put it somewhere inside the netdev implementations.

[miri64]

I've thought about it and I think you are right in the long term :-/.

[miri64]

ACK. Tested if auto address configuration for samr21-xpro and native still works.

[miri64]

Unrelated change, but ok.

[miri64]

Note: I think I'm going to revert this change after all, once #10524 is merged for two reasons:

• short term: it collides somewhat with @bergzand's refactoring efforts of netdev (though there are other solutions to those problems, *edit: see netdev_ieee802154: fix IID getter #10537 *).
• long term: we need a device type specific IID conversion function in gnrc_netif anyway to allow for gnrc_sixlowpan_iphc: allow address compression for non-IEEE802.15.4 #10521, so we would have (minimal) code duplication anyway, so let's rather move it to gnrc_netif completely.