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.
I'm not sure how many others than the hooks for ip_policy() there
are, as I didn't see any obvious ones in reading through the code,
but I can say that this set of "hooks" were (a) badly placed and
(b) too complex/overweight. I'm not even sure how they believed
they were in any position to come even close to accurately metering
traffic as it definately does not see packets as they go to or appear
on the wire (and not even all.) I could go on a lot more but I think
it's just a waste of time, unless someone really wants me to disect
it in detail. I think more than an appropriate amount of time has
already been spent on it.
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 you're just a consumer of "observability" events (all the data
passed through is 'read-only') then the order doesn't really matter,
except for local timestamping.
When the data can change, it becomes a problem...and so just because
two hooks are in the same place does not imply they can be collapsed
into one if there isn't any understanding of who sees what first if one
of the hooks allows for data to be modified.
Maybe allowing multiple callbacks for those that will change the packet
does make it overly complex and needlessly so. Linux requires this
because they have NAT and filtering split into seperate modules, rather
than all part of the one.
As the Solaris TCP/IP gradually moves from STREAMS to something
else, whatever is surplanting the module stacking needs to allow for
ordering to be defined and observed. That said, there are few cases
when this is done and the only one I'm aware of is when people want
to use IPFilter with Sun Cluster (unsupported config) and have the
autopush file with both pfil and the Sun cluster module listed.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
