eloop: Allow eloop to process all fds returned from poll(2) We do this by ensuring the events list or pollfd struct storage is not modified during the revent processing. An event with a fd of -1 means it's been deleted and one without a pollfd struct reference has been newly added. This also allows us to count down the number of fd's that returned a revent so we can break the loop early if possible. This is a really minor optimisation that at best only applies if more than one revent is returned via poll(2). In the case on dhcpcd on NetBSD with privsep, the number of fd's is really low. And on other platforms or without privsep it's low also (just not as low). It's only when you run dhcpcd per interface that the number of fd's starts to creep upwards as you then need one per address dhcpcd is monitoring (as well as the ARP listener per IPv4 address for non NetBSD). However, I use eloop in other code where this could be a good saving and dhcpcd is where the master version of this lives!

# This space left intentionally blank

DHCPCD_SRCS+=	dhcpcd-embedded.c