Centralizing code is a good idea in general, but why put a hostname parser (more of an application layer thing) into gnrc_netif (network interfaces i.e. link layer)?

tbh I didn't know where else to put it - maybe create a gnrc/util folder, I also have a gnrc_netif_wait_for_prefix() that could go in there.

tbh I didn't know where else to put it - maybe create a gnrc/util folder, I also have a gnrc_netif_wait_for_prefix() that could go in there.

Does it have to be part of GNRC even? From what I can tell, the only GNRC-specific thing is gnrc_netif_t which inherits from netif_t nowadays.

Does it have to be part of GNRC even? From what I can tell, the only GNRC-specific thing is gnrc_netif_t which inherits from netif_t nowadays.

I have the same concern. The whole snippet in gnrc_netif_parse_hostname is stack independent and there can be replaced by netif_xxx functions.

I'm also think this is more a kind of "netutils" rather than netif specific. But I could live with the later.

The "auto-detect interface if there is only one interface and address is link-local" part is GNRC specific though

The "auto-detect interface if there is only one interface and address is link-local" part is GNRC specific though

But what prevents to make it stack independent? And why it wouldn't be possible to still implement it in a generic way?

There's on-going work for using the netif interface as the OS entry point of an interface, instead of using gnrc_netif. We are already able to use e.g LWM2M with LWIP through #16563 and it will become more important to have these "generic" API (not GNRC, but rather OS entry points) when other stacks fully support netif_xxx (there's ongoing work for OpenThread).

It's true that it's not possible to write apps fully stack independent yet unfortunately, but removing gcoap and sock dependencies to GNRC will definitely help to move forward on this direction.

~~Is there a stack intependent alternative for gnrc_netif_iter()? ~~

nvm netif_iter() does exist.

Is there a stack intependent alternative for gnrc_netif_iter()

Yes. Fetching interfaces, registering and setting/getting options is already implemented for GNRC and there's on-going work for LWIP. Same for OpenThread

nvm netif_iter() does exist.

Just remember, that the part after the % is the name, not the ID of the interface ;-).

All the tests using ping now don't have ping anymore ;-) that's why I proposed to make precursor PR instead ;-)

And the fuzzing applications might also need that, but not sure. I guess all apps that include shell_commands and gnrc_icpmv6_echo require this module now.

I removed the changes to the ping command from this PR.

It's only a dependency if also shell_commands is used.

It's only a dependency if also shell_commands is used.

Exactly, so this should be reflected in the dependency resolution ;-) (same goes for xtimer/ztimer but that can be done as a follow-up).

(And it can then be removed from the example Makefiles btw. not sure why you try both in this PR then...)

so this should be reflected in the dependency resolution

What's wrong with

ifneq (,$(filter shell_commands,$(USEMODULE)))

  …

  ifneq (,$(filter gnrc_icmpv6_echo,$(USEMODULE)))
    USEMODULE += netutils
  endif

  …

endif

And it can then be removed from the example Makefiles btw.

Well the examples also use netutils_get_ipv6() in udp.c/gcoap_cli.c so I thought the proper thing to do would be not to rely on transient dependencies.

Well the examples also use netutils_get_ipv6() in udp.c/gcoap_cli.c so I thought the proper thing to do would be not to rely on transient dependencies.

👍

so this should be reflected in the dependency resolution

What's wrong with

ifneq (,$(filter shell_commands,$(USEMODULE)))

  …

  ifneq (,$(filter gnrc_icmpv6_echo,$(USEMODULE)))
    USEMODULE += netutils
  endif

  …

endif

Ah, sorry, did not see this was in the dependency resolution of shell_commands. Then this is fine.

However, please address the other concerns in my review as well.

(also, a Makefile.ci is required for the new test).

[tests/riotboot_flashwrite: add nucleo-g07xrb to Makefile.ci](/RIOT-OS/RIOT/pull/16634/commits/e2a8c2506f509b392e20bbeb8236d52fc6b3e51a)

How is that one growing?

[tests/riotboot_flashwrite: add nucleo-g07xrb to Makefile.ci](/RIOT-OS/RIOT/pull/16634/commits/e2a8c2506f509b392e20bbeb8236d52fc6b3e51a)

How is that one growing?

Ah, because it is using said new module and abstraction always has cost ;-).