cvs commit: src/sys/contrib/pf/net if_pflog.c if_pflog.h if_pfsync.c if_pfsync.h pf.c pf_ioctl.c pf_norm.c pf_osfp.c pf_table.c pfvar.h src/sys/contrib/pf/netinet in4_cksum.c

[juli mallett]

* Alexey Dokuchaev <danfe at nsu.ru> [ Date: 2004-02-27 ]
	[ w.r.t. Re: cvs commit: src/sys/contrib/pf/net if_pflog.c if_pflog.h if_pfsync.c if_pfsync.h pf.c pf_ioctl.c pf_norm.c pf_osfp.c pf_table.c pfvar.h src/sys/contrib/pf/netinet in4_cksum.c ]
> On Fri, Feb 27, 2004 at 08:18:12AM -0800, Sam Leffler wrote:
> > On Friday 27 February 2004 12:28 am, Dag-Erling Sm?rgrav wrote:
> > > Sam Leffler <sam at errno.com> writes:
> > > > I made two attempts to eliminate all the ipfw-, dummmynet-, and
> > > > bridge-specific code in the ip protocols but never got stuff to the
> > > > point where I was willing to commit it.  My main motivation for doing
> > > > this was to eliminate much of the incestuous behaviour so that you
> > > > could reason about locking requirements but there were other benefits
> > > > (e.g. I was also trying to make the ip code more "firewall agnostic").
> > >
> > > The ideal solution would be to convert the entire networking stack to
> > > netgraph nodes; we could then insert filter nodes at any point in the
> > > graph.
> > 
> > I consider netgraph a fine prototyping system.  I think that using it for this 
> > purpose would be a mistake.
> 
> Hmm, may I ask what do you mean by "prototyping system" in this context?

You can tie things together without much effort and with great
modularity and with the ability to promiscuously pass through, etc.,
to begin to develop an application, but eventually, the overhead of
a pipe/stream alike message-passing system which is not highly
parallel or fast is not very attractive.
-- 
juli mallett. email: jmallett at freebsd.org; efnet: juli;
o/~ sweet talk like candy rots teeth o/~