On Tue, Jul 24, 2001 at 08:26:57AM +0200, Yoann Vandoorselaere wrote:
> Sure, it will behave differently, but should work without problem on
> all architectures...
With your patch, attempts to call "pcap_set_alloc_func()" on OSes other
than Linux will fail, because that function doesn't exist. I consider
that a problem for applications that want the packet data supplied to
the callback to persist after the callback routine returns.
So "pcap_set_alloc_func()" has to be written for the other OSes as well.
The question then is "if the application has called
'pcap_set_alloc_func()', what should libpcap do on platforms where more
than one packet is read into the buffer in a system call?"
Should it just allocate a buffer for each packet, and copy from the
buffer into the packet? That's the easiest solution, but it does mean
you have to copy the packet.
Or should it allocate a buffer for each read? That'd avoid the copy,
but it'd mean that libpcap would have to keep track of the buffers, and
provide a routine to free them, as the pointers handed to the callback
routine will be pointers into the middle of that buffer, not pointers to
independently allocated buffers.
A further question is raised by the memory-mapped capture mechanism in
Linux - if we add support for that, then, if the application has called
'pcap_set_alloc_func()', should libpcap allocate a buffer and copy from
the memory-mapped buffer into the allocated buffer?
I suspect "allocate a buffer for the packet and copy into it" is the
right answer, but I'd like to see whether anybody else has any
suggestions first.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
