On Sun, 2004-01-04 at 12:55, Gisle Vanem wrote: > "Yoann Vandoorselaere" <[EMAIL PROTECTED]> said: > > > here is a patch I made to libpcap, permitting zero copy by allowing the > > calling application to specify it's own allocation/freeing function for > > the packet buffer, and the pcap header. > > I didn't see any patch for pcap-win32.c, but not sure it's possible with > a zero-copy here. Except maybe using shared memory or overlapped > I/O.
Well, I didn't investiguated this one because it was of no interest to me. However, if it is stated that this patch is the good way to do things, then I'll happily look into porting other pcap backend. > > This patch was done in a way that it won't break the existing libpcap > > API (except for the pcap_next function, but I could simply remove the > > I agree that many args should be 'const'ed, but your patch will break e.g. > Ethereal that binds to libpcap functions via dynamic lib-loading and function- > pointers. Huu, could you detail a little more here ? Don't see how it could break anything... BTW if the const part of the patch is causing problem; it can simply be removed as I just added it for the matter of sanitizing the code. > Not all compilers support zero-sized arrays. I can easily work around that... Just need to know if the patch is the good way to do thing (ie, will it ever be included with theses correction?). -- Yoann Vandoorselaere <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
