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

[Julian Elischer]

On Fri, 27 Feb 2004, Sam Leffler wrote:

> On Friday 27 February 2004 12:28 am, Dag-Erling Sm=F8rgrav 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")=
=2E
> >
> > 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.
>=20
> I consider netgraph a fine prototyping system.  I think that using it for=
 this=20
> purpose would be a mistake.


for the record, I agree.
Netgraph is good for 3 things:

1/ general prototyping

2/ production of "strange" configurations that
probably don't deserve massive development time.
Kindof "one off" setups.

3/ It is actually very good at Link level stuff and is used in
production for that.

What it would not be good at would be handling something like the
socket layer.. you can not realistically make a netgraph hook for every=20
socket in the system, and as Van jacobson points out, layer collapsing
in the final production product is probably a good idea.
(i.e. expediency over academic purity).



Having said all that I'm sure that you COULD make a netgraph based
IP stack and that it might even be useful as a second string for=20
finding bugs and prototyping stuff.

=20
> =09Sam
>=20
>=20