Comment # 9
on bug 8462
from Evan Huus
(In reply to comment #7)
> We might offer the option off not dumping NRB:s and settle for this less
> elegant "solution".
Until somebody wants to dump the NRBs, just not the ones they don't need.
Agreed that an option to not dump NRBs at all is probably a good place to start
though.
> > It seems to me that the correct way to handle all cases is to associated
> > name resolution data with each frame (in the frame_data perhaps) in addition
> > to the global hash table. Then base the data in the NRBs according to the
> > what is linked from each frame being written (as opposed to just writing
> > everything in the hash table).
>
> That might be costly in memory usage, on the other hand the fdata entry
> could perhaps be used in the packet list and could be a pointer to the
> string in the hastable. For tshark ther would be no gain.
Yes, just a pointer into the hash-table. I think eventually the hash-table
shouldn't be accessible outside of addr_resolve.c - external code should only
ever be interested in name resolutions for a particular set of packets (names
for all packets could be a subset of all names).
(In reply to comment #8)
> Created attachment 11539 [details]
> Initial patch to get rid of addrinfo_list
>
> I think one step along the way is to get rid of the addrinfo_list, this patch
> removes some users of the list.
This looks good to me. Eventually we may want the hosts taps to register a
packet callback function that accumulates the names from each packet (so that
unused entries from a particular file don't get output unnecessarily) but this
is a good first step.
You are receiving this mail because:
- You are watching all bug changes.