On Jul 8, 2025, at 7:36 AM, Denis Ovsienko <de...@ovsienko.info> wrote:
> The need to have a pcap_t at all times is very similar to using file > descriptors or sockets: first you obtain a descriptor, then you > initialise it in various ways as necessary, then you have a very small > number of methods to read and to write, and by that time the only > things you need to specify are the descriptor and details of this > particular read/write (how many bytes, location, blocking/non-blocking). Yes, but is there a notion of a file descriptor for an "object" whose sole purpose is to, for example, fill in a stat structure when you call stat() on it, and supports no other operations? A "dead" pcap_t's only purpose is to supply a link-layer type and snapshot length - and, potentially, compiler target type - to APIs that, for whatever reason, weren't designed to take those values as arguments. > libcurl and other libraries implement a very similar approach using > contexts and options, and quite often a new option is a much better > solution than a new API function. That's a question of options vs. API functions, with generic "add an option of this type" calls rather than adding a new API for each new setting. Michael Richardson's pcap_options API in the main branch should be expanded to 1) provide options as alternatives for the current APIs, 2) allow querying which options are available for a given pcap_t, and 3) allow a particular pcap module to provide its own private options for cases where it's medium-specific or mechanism-specific. The generated-code type flags are specific to pcap_open_dead() - savefiles would just use "generate normal cBPF" (unless we add a BSD-licensed eBPF interpreter and use *that* for savefiles), capture devices would use whatever is appropriate for the device, and only "generate code for something that's neither a savefile nor a capture device", i.e. something opened with pcap_open_dead(), should support that option. The pcap_options API supports an option set, so an alternative would be to pass an option set to a new "compile this filter expression" API without having to have a pcap_t to open and close. _______________________________________________ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
