GNRC Iface name

Hello

Working to understand GNRC, I found that netif thread pid is used as interface name instead of the name used for netif thread. Why is that so?

It’s pretty easy to define descriptive names (like “peth0” for peripheral ethernet number 0) in device_params.h and add a name member to netif_t that holds it

But the question remains to why it is this way

TIA

Grr

Hi Grr!

On Sat, Feb 05, 2022 at 01:59:43PM +0000, Grr via RIOT wrote:

Working to understand GNRC, I found that netif thread pid is used as interface name instead of the name used for netif thread. Why is that so?

Well, you certainly need the thread ID of a network device driver in order to communicate with it from the upper layers. Hence, just using the thread ID as an identifier appears logical and minimizes memory usage by not introducing an additional identifier.

It’s pretty easy to define descriptive names (like “peth0” for peripheral ethernet number 0) in device_params.h and add a name member to netif_t that holds it

What would be the advantage of a human readable name except for debugging? Remember that a typical RIOT driven device will hardly interact with any user during its production lifetime. A string consumes more memory than a numeric identifier and requires more computational resources for comparison.

The only thing I could imagine would be an optional string member in the data struct that is only enabled for debugging purposes (e.g., when building with DEVELHELP enabled or the like).

However, as long as you do not switch the board or completely re-arrange the code your interface ID will stay the same during the development process anyway, so you will know any interface ID by heart very soon in any case. So the benefits of a string remain limited in my opinion.

Cheers Oleg

– The bad thing with jokes around EOF

Thanks for your response

The point is name is already there. There’s no memory usage increase except for a pointer to the already existing name in the right place, which as I said probably is netif_t struct

If there is not advantage in human readable info, then why does ifconfig exist? In fact, I got to this question examining ifconfig code. So if there’s enough reason to have ifconfig, then there is also for having iface names

Getting a list of ifaces with device names (which are already there) is far clearer and helpful than getting it with thread numbers: prevent mental errors, is softer with newbies and gets closer to unix, all that at the cost of one pointer

That’s the reason of my question. Maybe it’s just historical reason but I couldn’t find any mention on this

TIA

Grr

Followup:

Implementing the ideas to get iface names, I found something I don’t understand

In sys/net/gnrc/netif/_netif.c there are reveral sentences of the type

gnrc_netif_t *netif = (gnrc_netif_t *) iface;

where iface is of type netif_t. Problem is if type netif_t is modified (like putting a pointer at the beginning, before member ‘node’), all this breaks and causes a kernel panic. So the question is twofold:

1- How can it work? I can’t grasp how can pid member of gnrc_netif_t can be obtained from netif_t pointer with a simple cast

2-Why not use container_of() to avoid breaking it with struct changes?

TIA

Grr

Hi Grr,

On Sun, Feb 06, 2022 at 02:20:30PM +0000, Grr via RIOT wrote:

The point is name is already there. There’s no memory usage increase except for a pointer to the already existing name in the right place, which as I said probably is netif_t struct

I just looked it up and as far as I can see there is no member in neither netif_t nor gnrc_netif_t. The (optional) string name in the function gnrc_netif_create() is used as the identifier of the thread if compiled with DEVELHELP.

If there is not advantage in human readable info, then why does ifconfig exist? In fact, I got to this question examining ifconfig code. So if there’s enough reason to have ifconfig, then there is also for having iface names

Touché! The optional name of a thread and the whole shell (including the ifconfig command) exist for the sole purpose of facilitate debugging and developing. They are not meant for production code. Hence, yes, I agree it could be nice to display the thread names of the corresponding interface in ifconfig. Whether you want to use this name also for accessing the interface, e.g., when calling ifconfig to modify the interface configuration, is probably up for discussion.

Getting a list of ifaces with device names (which are already there) is far clearer and helpful than getting it with thread numbers: prevent mental errors, is softer with newbies and gets closer to unix, all that at the cost of one pointer

Point made, no objections from my side.

Cheers Oleg

/* We are root, all done! */ RIOT/sys/net/rpl/rpl.c

Hi Grr,

On Sun, Feb 06, 2022 at 05:08:59PM +0000, Grr via RIOT wrote:

2-Why not use container_of() to avoid breaking it with struct changes?

I guess in this case the answer is simple: just take a look at [1] or [2] (or the latest release).

Cheers Oleg

[1] https://github.com/RIOT-OS/RIOT/commit/b1114b0674fa616811e472c8ac7b9021556f8c6c [2] https://github.com/RIOT-OS/RIOT/pull/14955

panic(“Yeee, unsupported cache architecture.”); linux-2.6.6/arch/mips/mm/cache.c

Thanks for your response

I just looked it up and as far as I can see there is no member in neither netif_t nor gnrc_netif_t. The (optional) string name in the function gnrc_netif_create() is used as the identifier of the thread if compiled with DEVELHELP.

I didn’t mean the name is in xnetif_t. In that case, the pointer I mention as solution wouldn’t be needed. What I mean is the name is already somewhere in memory, it just needs a pointer to be used

The additional benefit is netif_get_name() is no longer needed. So this change saves memory instead of wasting memory

just take a look at [1] or [2] (or the latest release)

Thanks for the notice

Grr