On Fri, Sep 12, 2003 at 07:07:39AM +0900, Jun-ichiro itojun Hagino wrote:
> bad things:
> BSDi BPF changed interpretation of some additional BPF insn
> (and new interpretation like 128bit register) without having
> any version identification.
Which instructions' interpretation did they change (rather than adding
new interpretations)?
> there's no way to identify
> what version of BPF engine is installed in the kernel,
True, unfortunately, for BSD/OS.
However, if other BSDs adopt that engine, they should change the version
from the 1.1 that's in the top-of-tree {Free,Net,Open}BSD to 1.2 or 2.0
(1.2 if new instructions are added, 2.0 if existing supported
instructions are changed incompatibly), so that libpcap can do a
BIOCVERSION to determine whether the kernel's BPF interpreter supports
the new stuff or not. (I don't know offhand whether Darwin uses 1.1,
but I can check it at work tomorrow - I suspect we do.)
For BSD/OS, we might be able to use "uname()" as a workaround, if we can
find out the first release that had the new BPF interpreter.
Linux, unfortunately, doesn't appear to have any "getsockopt()" option
to get the version number of the BPF engine. I don't see any
*technical* reason why it couldn't have one (just add it to
"sock_getsockopt()", and have it call some routine in
net/core/filter.c), although I don't know whether somebody would try to
argue that this was somehow a Bad Idea, requiring them to be
re-educated. We'd assume that any Linux kernel that didn't support that
"getsockopt()" option had the old BPF engine.
> so we
> can't make libpcap compiler to work on pre-BSDi and BSDi BPF
> engine.
As long as the BSD/OS-based engines supply a different version number,
we can make that work. BSD/OS, as far as I can tell, is the only
problem.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
