sys/net: Move netif addr<->string functions from gnrc_netif to netif

[yarrick]

Contribution description

Rename gnrc_netif_addr_(to|from)_str to netif_addr_(to|from)_str and move to the more generic netif module.
They are inline functions just calling l2util anyway.

This is a step in having the ifconfig shell command being stack independent.

Testing procedure

• tests/gnrc_netif should still build and pass.
• ifconfig shell command with gnrc still working

Issues/PRs references

[miri64]

By now, the gnrc_netif_addr_*_str functions are just wrappers around l2util_addr_*_str so why not just use l2util_addr_*_str and not change the API of gnrc_netif? Alternatively, we can add a gnrc_netif_addr_*_str wrapper around netif_addr_*_str, but then we have a wrapper of a wrapper, and I don't think that makes sense if non-GNRC stacks can just use l2util_addr_*_str ;-).

[miri64]

So NACK from me. Either we do the convoluted wrapper thing or we don't go forward with this, as this seems to be a bigger API change than necessary.

[yarrick]

Do you mean only switching to directly calling l2util_addr_*_str in what is now sys/shell/commands/sc_gnrc_netif.c ? (It would probably be called something else once it supports more stacks)

If it is used directly there but via the gnrc_netif name inside the gnrc stack that feels odd to me.
Does the gnrc_ prefix add much currently? I did not think so since there is nothing gnrc-specific about it.

[yarrick]

Since the gnrc_netif_addr_*_str functions are declared only in the headers it seems this isn't needed for it to work in lwiP (as long as l2util module is included). Skipping for now.

[miri64]

Do you mean only switching to directly calling l2util_addr_*_str in what is now sys/shell/commands/sc_gnrc_netif.c ? (It would probably be called something else once it supports more stacks)

Yes, that's what I meant. Sorry for the late reply!

[miri64]

If it is used directly there but via the gnrc_netif name inside the gnrc stack that feels odd to me.
Does the gnrc_ prefix add much currently? I did not think so since there is nothing gnrc-specific about it.

The reason for the wrapper is mostly historical. First, it only existed in GNRC, then it was needed elsewhere, which is where l2util_addr_*_str entered the scene.