aboutsummaryrefslogtreecommitdiffstats
path: root/oui.h
diff options
context:
space:
mode:
authorGuy Harris <guy@alum.mit.edu>2000-01-12 06:56:32 +0000
committerGuy Harris <guy@alum.mit.edu>2000-01-12 06:56:32 +0000
commitbd7c6bda88272183dfbbf5fe146ccc638a864cd9 (patch)
treef83f83a6e406a98f2c64a40764fcb7b0ecdbb3a5 /oui.h
parent0a9f2233b86d305887f5ca6e55e13f57dd180120 (diff)
downloadwireshark-bd7c6bda88272183dfbbf5fe146ccc638a864cd9.tar.gz
wireshark-bd7c6bda88272183dfbbf5fe146ccc638a864cd9.tar.bz2
wireshark-bd7c6bda88272183dfbbf5fe146ccc638a864cd9.zip
Enough is enough. Requiring anybody who uses Ethereal on Linux to
update their libpcap probably isn't going to scale - the increasing frequency with which "Ethereal hangs when I try to capture packets" shows up on "ethereal-dev" suggests that, unless and until a libpcap with the "select()" in it becomes ubiquitous on Linux, that'll be the source of a constant support burden - so we'll just put the "select()" in Ethereal if it's being built for Linux. (Putting it in for platforms where the read timeout argument to "pcap_open_live()" works adds an extra useless system call at best and, at worst, could make Ethereal not work - "select()" doesn't work on "/dev/bpf" devices on FreeBSD 3.3, at least, unless you're in "immediate mode", and, whilst "immediate mode" would make Ethereal respond more quickly when packets arrive, it might cause Ethereal to respond too quickly, doing reads for every new packet rather than waiting for multiple packets to arrive and reading them all with one "read()", which appears to be at least part of the intent of the read timeout on "/dev/bpf" devices in BSD.) svn path=/trunk/; revision=1451
Diffstat (limited to 'oui.h')
0 files changed, 0 insertions, 0 deletions