James Carlson wrote:
The things that need to be explained to the ARC members are why all of
the previous claims to generic hook features are unusable and why
generic hooks aren't even considered feasible. That's something I'd
hoped to do back when we were writing the filtering document, but that
essentially go no consensus and went nowhere.
Jim and Darren,
If there is a place where I can help to clarify this (in a meeting, some
slides, some text in a document), please let me know and I'll contribute.
Darren Reed writes:
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.
Is it a problem, though, that actually needs to be solved? I think
that's the unclear part for both projects.
If we have some targeted hook somewhere which can do queuing and/or
rewriting of the headers, then I think that the order matters.
But I think this can be addressed by explicitly making such hooks single
consumer - not allowing multiple parties to register.
Should there be hooks that are for observability only, or even those
that can do pass/drop, then there isn't much of an issue with the order.
Thus such targeted hooks can potentially allow multiple registrants.
Erik
_______________________________________________
networking-discuss mailing list
[email protected]
