Gleb Smirnoff wrote: > > On Tue, Dec 14, 2004 at 01:47:35PM +0100, Andre Oppermann wrote: > A> > Implementationwise, the kernel side is evidently trivial as the > A> > original code already supports the idea of multiple chains. All > A> > you need is to extend the struct ifnet with a pointer to the chain, > A> > or use some other trick (e.g. going through ifindex) to quickly > A> > associate a chain to the input (and possibly output) interface. > A> > A> Nonononononononononononononononononononononono. > A> > A> There MUST NOT be any firewall specific pointers or other information > A> in struct ifnet or any other non-firewall private part of the kernel. > A> Otherwise the entire independence we've gained with the nice and clean > A> PFIL_HOOKS API goes down the drain. This MUST NOT happen again. > A> > A> The whole idea of the PFIL_HOOKS is to have independend and loadable > A> firewall modules with different approaches, internal designs and so > A> on. > > The whole idea of PFIL_HOOKS is to have independend and loadable firewall > modules, which can be attached to different parts of kernel! There is no > such requirement that, pfil hooks MUST be sticked to a single entry point > in ip_input() and ip_output().
PFIL_HOOKS is meant to be once on input and output per protocol and not per interface. That is the reason why there is the interface pointer in the argument list. > Pfils attached to interface belong to interface, and thus should be stored > in struct ifnet. This is the way it is done in per-interface filters. Again, you are changing the way PFIL_HOOKS are called. > A> For example a way Gleb can get his way without any bickering from us > A> is by creating his own gleb-firewall module using the PFIL_HOOKS API > A> and put it into the ports tree for easy access, provided he doesn't > A> modify the PFIL_HOOKS API (which he doesn't have to). > > I am not going to create a new firewall or change PFIL_HOOKS. I'm going > to attach *the existing* pfil_hooks to a different place, to perform > filtering with *existing* firewalls. The existing firewalls need to be modified anyway to be able to deal with per-interface hooks. They are not made for it. This makes your argument moot. But please hold on, I'm writing an email with a different proposed approach. Let's continue the discussion when all have read it. Give me a few minutes. -- Andre _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
