Harald Welte writes: > On Fri, Apr 26, 2002 at 09:52:46AM -0700, Don Cohen wrote: > > Harald Welte writes: > So you want to have a big case statement _after_ enqueuing of the packet > happens [ i.e. in the network TX softirq], calling NF_HOOK for the > respective protocol family?
Actually, after dequeuing. I did suggest an alternative to the big case statement, which was a new hook. You'd loop through the registered functions. Perhaps these functions should be able to return something to drop the packet. > > ... I think in general it would be > > worth while to save more of this data for use in later hooks. > > So I think that nat should save the original data just for use in > > later hooks. > > well, but it's added overhead and none of the existing functions within > the framework need it. If there is any chance for adding such overhead, > then if at the same time we actually have some code which uses it. > > Just providing features because they are nice for some > not-included-in-kernel code is not our philosophy. Netfilter itself seems to be a counterexample to that statement. Its whole purpose is to enhance the range of things that can be done by not-included-in-kernel code(*). Certainly it's worth saving a little more data in order to increase that range further. For any particular data this is a cost benefit question. The cost of saving the data is to be compared with the benefit of what can be done with that data. (*) Now that I reread this, it occurs to me that in-kernel could mean two different things. The code in modules (or code that could have been in modules) could be considered in or out. I meant to include it as part of what netfilter is meant to support. The other code is stuff like iptables rules, which I think is clearly out. In both cases it's useful to make something like input device available.
