Re: supporting extend 'open live capture'

[Guy Harris <guy () alum mit edu>]

Paolo Abeni wrote:

> On Mon, 2008-02-11 at 01:20 -0800, Guy Harris wrote:
> > What's the advantage of requiring that 
> > pcap_get_monitor_mode_availability() be called after pcap_activate()?
>
> This way all the platform/device dependent code can be placed into
> pcap_activate(), elsewhere we have to split/duplicated some of it in
> pcap_activate() and pcap_create() [or
> pcap_get_monitor_mode_availability()].

Little, if any, code would be duplicated:

	pcap_create() would determine whether, for example, the DAG, Septel, 
Bluetooth, USB, or socket code would be used to capture traffic, and 
would set some pointers - including the activate_op pointer - in the 
pcap_t appropriately;

	pcap_activate would just call handle->activate_op, and, for example, on 
Linux, that would be dag_activate(), septel_activate(), bt_activate(), 
usb_activate(), or pcap_activate_linux();

	the activate op would change some of the function pointers from 
pointing to the appropriate handlers for unactivated pcap_t's 
(pcap_create() would set them to point to those handlers) to the 
appropriate ones for activated pcap_t's - for example, some of them 
would have been set to routines returning PCAP_ERROR_NOT_ACTIVATED, and 
the activate op would set them to the appropriate routines for an 
activated pcap_t (for example, we could have a set_snaplen_op, which 
would be set to pcap_set_snaplen() by pcap_create(), and to a routine 
that returns PCAP_ERROR_ACTIVATED by the activate op);

	one of those function pointers would be for the "get monitor mode 
availability" op, and that would be set by pcap_create() to point to the 
platform-and-mechanism-specific check routine, and would either be left 
alone by the activate op or set to a routine that returns 
PCAP_ERROR_ACTIVATED by the activate op.

> > In addition, if you specify a device name to pcap_create(), it means 
> > that, for example, we could conceivably have the handle returned by 
> > pcap_create() point to a structure that begins with a pcap_t and has 
> > device-dependent information at the end - this would mean that the 
> > pcap_t structure wouldn't have to include all possible forms of 
> > device-dependent information; the device-dependent information could, in 
> > most if not all cases, be defined in the pcap-XXX.c routine.
>
> I suppose that this can be achieved also adding a 'private' field
> (perhaps a pointer) in the pcap_t structure, which should be
> managed/used by the platform dependent code.

True - you get a little extra overhead from that (second allocation, 
private structure not necessarily being right after the pcap_t structure 
and thus possibly not having parts of it share a cache line with parts 
of the pcap_t structure, extra pointer dereference), but you do get 
portability (unless I've missed something in the C spec), and it might 
have a better cache footprint (if, for example, a memory allocation is 
more likely to be on a cache line boundary, so that you don't drag in 
possibly-uninteresting information before the private structure - i.e., 
I don't think I'd necessarily trust my intuition on this).

> Currently this sort of trick is used by at least the gtk library, but I
> don't know if they explicitly require a compiler complying with more
> recent standards.

Or perhaps they just require a compiler that does the "obvious" right 
thing, which I suspect that, in practice, most compilers do - but I'd 
prefer not to depend on that.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.