implement IntoIterator for SliceCache #11
Conversation
|
First, I've cherry-picked fabcbd9 and 380bfd5, thanks. Regarding IntoIterator, I'm not sure I see the point over implementing that trait instead of an Regarding non-unicast addresses in the ARP cache, yes, that's troublesome. I think it warrants an assert in the ARP cache, and a branch in EthernetInterface. Regarding the iterator itself, sure, that's reasonable. But you'll encounter a problem, namely that you don't have the concrete SliceArpCache type in EthernetInterface. I think you'll have to make the iterator an associated type of ArpCache trait and SliceArpCache. |
|
See also 4e364d8. |
|
See also 15cf0cc. |
whitequark
force-pushed
the
master
branch
2 times, most recently
from
a7da851 to
1746702
Compare
|
I'm going to closing this PR because it seems like everything except the actual ARP cache iteration is already done, and iteration itself is something I would like to do quite differently. Feel free to open an issue requesting that. |
I'd like to have the ability to dump the arp cache. One way to do this is to iterate over the cache, which is what this PR implement. If you are ok with this change, I'd like to add an
iter_arp_cachemethod onEthernetInterface.While implementing this, I noticed that the ARP cache could have entries with non unicast ip addresses (like
0.0.0.0,0.0.0.1or255.255.255.255). Is this intentional? Shouldn't the insert fail when trying to insert such entries? If that's intentional, I'll remove 26b78ae and makeSliceCacheIteratorwork for these entries. Otherwise, I can work on a fix.I also noticed that the
lrucounter was not incremented on insert. I took the liberty to add this but I can revert if that was intentional.