Skip to content

gnrc_netif_t: A dynamic approach to ~~GNRC_NETIF_NUMOF~~. #9903

@miri64

Description

@miri64

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.

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)

Metadata

Metadata

Labels

Area: networkArea: NetworkingProcess: API changeIntegration Process: PR contains or issue proposes an API change. Should be handled with care.Type: enhancementThe issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions