I'm not sure I'd do it in that way. I'm thinking if BPF provided
stateful
inspection is would be
more useful.
Asking for stateful inspection in bpf(4) is like wanting a carburettor
for a pushbike. You might be able to shoehorn it in there, but it
won't
be pretty, will ruin its simplicity and probably won't be much use.
Yeah this would be something in addition to BPF and not to alter BPF.
I like the simple
functionary but I think it would be hard to management complex rule
(s). The language is
a little clunky. Just think is doing something when you have to check
protocol #, source and dst address
and TCP flags. I guess the fact that BPF branches only forward does
both simplify and limit its scope.
FFPF is a different approach, and they (rightly) didn't use bpf(4) as
their base implementation. Some of their ideas look pretty good, but
if you are interested in pursuing them the you had probably best do it
in parallel to the existing bpf(4) infrastructure.
-d
I'm at the survey stage. I know about a number of efforts which apply
BPF-like
technology to lots of applications. As you say, FFPF has some neat
ideas, and it is
efficient (context switching, number of copies) , more scalability
(BPF is a little clunky no
loops) and able to handle more complex situations. Its even has
backward compatibility of BPF.
However, It doesn't support BSD that as far as I know, I hadn't
looked that closely for that reason.
Might in interesting if its no overly dependent some linux kernel
feature.
Respectfully,
Tony Sterrett
[EMAIL PROTECTED]
Consultant in Open Source Software, featuring OpenBSD and Linux.
www.sterrett.net
(858) 433-1467 San Diego
(408) 705-2135 San Jose
