-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Description
While there are compile-time benefits to cap the number of interfaces, recent questions by users and contributors opened the question if a statically defined GNRC_NETIF_NUMOF
(and thus a predefined array) isn't to intransparent and really the most sensible approach. IMHO it could actually be pretty easy with minor API changes to go to a linked-list-based approach by just adding a next
member above ops
.
RIOT/sys/include/net/gnrc/netif.h
Lines 62 to 64 in 8d1d509
typedef struct { | |
const gnrc_netif_ops_t *ops; /**< Operations of the network interface */ | |
netdev_t *dev; /**< Network device of the network interface */ |
would become
typedef struct gnrc_netif gnrc_netif_t;
/* […] */
struct gnrc_netif {
gnrc_netif_t *next; /**< The next interface */
const gnrc_netif_ops_t *ops; /**< Operations of the network interface */
netdev_t *dev; /**< Network device of the network interface */
For allocation it could just be allocated on the stack of the network interface's thread.
Of course, gnrc_netif_iter()
could be simplified a lot then as well ;-).
The biggest disadvantage I see is that we loose some #ifdef GNRC_NETIF_NUMOF == 1
optimizations through-out the code (which also would require changing, which is why this rework could become quite major though the change to the API is as I said pretty minor).
Let me know what you think.
(@gschorcht this might also be of interest to you as well)