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.
/* 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
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_tnorgnrc_netif_t. The (optional) stringnamein the functiongnrc_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