James Carlson wrote:
Darren Reed writes:
"However, during the discussions it became clear that there were
potential problems making the Hooks Framework generic at this time
so we will implement our own specific hooks in ip."
Yeah, that's not pleasant. From an ARC point of view, there are
several issues to contend with:
- You're right that we don't want to see multiple implementations of
the same thing. However, it's also true that we don't want to
hold a project hostage to unsolved areas elsewhere in the system.
It's a bit of a tightrope walk to make that sort of judgement
call.
- If this project is right, and the Hooks Framework is not general
enough to solve this problem, then it's certainly fair to ask why
that should be so. It seems, at least at first blush, that
anything that can filter packets ought to be also functional
enough to simply _observe_ them. If that's not true, it'd be nice
to know why. This would likely end up as advice to management.
Reading the documentation, the hooks framework is intended to be
used but they feel there is a need to add another, different hook
than those being proposed for the purpose of filtering packets.
So my quandry is should something be done to address this?
The biggest problem I can see with combining the two is that as a
result of discussion over the design, I abandoned trying to resolve
the problem of multiple consumers for the same hook. The result
here would be not being able to use /dev/ipnet/* at the same time
as IPFilter if both used the same hook rather than their own.
The root of that decision is trying to answer the question of
"if both are enabled, who should see a packet first and how does
one specify that preference or its inverse?"
...for which no good answer could be found :(
...
Again from the ARC perspective, I don't think I'd ask such a thing.
PEF doesn't exist.
ick :(
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
