I like the idea of the pkt type. I would actually strongly opt for removing the (redundant) hlist data-structue and also remove the hlist from the functions naming -> keep it as simple as possible!

But headers are no packets. As someone not familiar with this I would be very confused if I see packets get stuffed into packets. Furthermore, the semantics become very different in the packet buffer (only pkt_t can created, pkt_hlist_ts can only be prepended/removed from pkt_t.

Think of the pkt_t as head type of the of a list with pkt_hlist_t nodes and pktbuf as its factory.

TL;DR while removing pkt_list_t would reduce complexity in terms of LOC, I would find the API less understandable.

Afterthought: You commented on the wrong PR. Please discuss introduction of pkt_t and pkt_hlist_t in #2158 ;-)

Rebased to make changes apparent here, too. ;-)

I thought about this a bit more: I would actually vote for renaming the thing completely to something like chunk_t, getting away from packets/headers all together. So all you do in the network stack is allocating chunks of memory in the chunkbuf. Or maybe we can call it crumb_t / crumbstore or something...

Anyway, as I see it the buffer can be used for more than just packet/header buffering, why not use it also to store addresses or whatever?

Regarding the API: I don't think we need a dedicated API for headers, by just working on a generic data structure we simplify/shorten code with the same results - in the end it's not the genuine user that is working inside the network stack - but people who know at least to some extend what they are doing...

oh, just noticed: this comment should have probably been posted for #2158, sorry

@authmillenon please rebase

Rebased to #2285 and added it as dependency in description + ported nomac to the api change.

Closed in favor for #2400