@haukepetersen and I today talked a little bit about the problems with netdev_t and how to dynamically add features independent from a specific device. Examples for this are

• common link-layer specific operations (e.g. IEEE 802.15.4 options (currently implemented in netdev_ieee802154_t or deduplication of received packets (currently implemented in gnrc_netif_ieee802154: drop duplicate broadcast packets (optionally) #7577))
• link-layer address filtering (currently implemented in the link-layer specific sub-layer)
• packet-counting / collecting network statistics (currently implemented on a per-device basis)
• device-independent retransmissions (see gnrc_netdev2: link-layer retransmissions outside the transceiver driver #4795)

This is what we came up with:

In addition to actual device drivers there are additional netdev_driver_ts available who also have another netdev_driver_t associated to themselves (I called this construction netdev_layered_t here but I'm not stuck on the name). This allows a network stack to use those features as though they were a normal network device and the whole thing would be very transparent to the network stack (so I wouldn't count this as a major API change ;-)). The benefit of this should be clear:

• no code duplication for link-layer specific operations (like packet counting, link-layer address filtering, option setting/getting)
• simplification of the netdev_ieee802154_set()/netdev_ieee802154_get() situation that seem to confuse people

The questions that are still open are:

• Where to store netdev_layered_t instances?
• How initialize such a "netdev_layered_t" stack while also having it configurable?