We are on the sock layer here so we can't use network stack native list representations anyway.
I don't see how lists or arrays differ in stack usage (in fact the list will store an additional pointer, so 4 more bytes per element) but lists are more awkward to use:

• Both GNRC and LWIP expect the last element to be written first. This would either mean that the user has to supply the list in an 'unnatural' order, use double-linked lists or we reverse the list inside the network stack
• Array can be statically initialized (and be compile time const)

I agree that lists provide additional flexibility in case someone wants to add multiple layers on top of sock though.

I don't see how lists or arrays differ in stack usage (in fact the list will store an additional pointer, so 4 more bytes per element)

Think of an application writing some content using protocol X. This is a potential call stack using iolists:

proto_X_send(..., buf, len) {
  iolist_t entry = { .iol_data=buf, iol_len=len }

 proto_X_udp_send(..., &entry);
}

proto_X_udp_send(..., iolist_t entry) {
 buf, len = proto_X_create_hdr(...);
 iolist_t proto_x = {.iol_data = buf, .iol_len=len, iol_next=entry };
udp_sendv(..., &proto_x);
}

udp_sendv(..., &proto_x) {
buf, len = udp_build_hdr(...);
 iolist_t udp = {.iol_data = buf, .iol_len=len, iol_next=proto_x };
ip_send(..., &udp);
}

...

Using arrays, each layer would probably get an array as parameter. to add data, that array either needs to be in reverse order and large enough (who knows how large?), or, be recreated on each layer, but again, how big? variable length?.

IMO, lists save a lot here.

How about this? I'm not entirely happy with having to reverse the list depending on which network stack is used, but then again this is neatly hidden from the user and the list based interface does indeed provide more flexibility to the application.

I still don't understand why the iolist has to be reversed. just to be clear, iolists are in-order, meaning, first entry (list head) contains bytes 0-x, second contains x+1 . ..., and so on, right?

That's how it is passed from the application, and that's how the good old netdev expects (or expected) it.

In the PR, you're reversing that for lwip and openwsn, but not gnrc? Even though lwip writes in-order using netcon_write_partly() and openwsn also copies in-order? does gnrc_pktbuf_add prepend?

It seems to me something is turned around. if gnrc_pktbuf_add prepends, we need something that appends. There's gnrc_pkt_append, that sounds like it could be used (but might need allocation of a pktsnip, even though the data could be just pointed to?

but, are we clear on the supposed order of the iolists?

(You really don't want to re-use iolist.h?)

Sometimes one does not see the forest due to all the trees 😄
I've added gnrc_pktbuf_add_tail() and reworked the buffer chaining in lwip_sock_sendv() so now we can always use the buffer list in the right order.

I'll split up the commits and force push shortly.

3. instead of one type (iolist_t), there's now three (iolist_t, sock_tx_snip_t, sock_rx_snip_t)

There's also the point that if having distinct rx/tx snips is actually the preferred choice, we should have that for iolist_t.
But, while I don't think that posix is a good example for API design, they get away with only one iovec_t type. It does reduce complexity.

Fine, I still maintain that the iolist_t API is fugly, but if you prefer it that way so be it.

Fine, I still maintain that the iolist_t API is fugly

you mean because of the member names, or because of the const?

From my perspective you can squash this!

you mean because of the member names, or because of the const?

both really, e.g.

Thank you for the review!