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

[Luigi Rizzo]

On Fri, Feb 27, 2004 at 02:36:30PM +0600, Alexey Dokuchaev wrote:
...
> > 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 believe this (convert the entire networking stack to netgraph
nodes) is completely unfeasible.
There are interactions among subsystems all over the place.
The routing subsystem is used by all protocols at different
layers (arp, ipv4 and ipv6, probably more). TCP knows it runs
on top of IP and pokes into its data structures below. It also
plays with the socket buffers on the layer above.

netgraph is nice when you have to deal with packets, but when
interactions become more complex the packet API supplied
by netgraph is not suitable anymore.

	cheers
	luigi

> That idea was attracting my attention for quite some time, probably
> since when emax' bluetooth stuff hit the tree.  It seems the most
> generic and coherent approach; especially provided that all core
> functionality is already implemented and well-tested, and there are lots
> of real-life NG-based solutions already available that come with both
> stock FreeBSD and from third parties.  I'm also wondering how far is it
> possible to push NG usage into the kernel; e.g. can USB stack be
> converted to it (seeing analogy with bluetooth here)?
> 
> ./danfe