src/sys/modules/pf, branch release/8.1.0FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=release%2F8.1.02009-10-14T15:32:46ZFix typo which has survived amazingly long!2009-10-14T15:32:46ZErmal Luçieri@FreeBSD.org2009-10-14T15:32:46Zurn:sha1:d8e86c4a5d9ce7f0aab10d3d13b6c78ce5c6fca5
Reviewed by: mlaier(mentor)
Approved by: re(kib)
After r193232 rt_tables in vnet.h are no longer indirectly dependent on2009-06-08T19:57:35ZBjoern A. Zeebbz@FreeBSD.org2009-06-08T19:57:35Zurn:sha1:8d8bc0182ea6f8f85409e76e53053487c7d23a84
the ROUTETABLES kernel option thus there is no need to include opt_route.h
anymore in all consumers of vnet.h and no longer depend on it for module
builds.
Remove the hidden include in flowtable.h as well and leave the two
explicit #includes in ip_input.c and ip_output.c.
Remove opt_mac.h generation for various kernel modules that no longer2009-06-06T17:01:44ZRobert Watsonrwatson@FreeBSD.org2009-06-06T17:01:44Zurn:sha1:d5fc25e5d6c52b306312784663ccad85923a9c76
require it.
Submitted by: pjd
Rather than using hidden includes (with cicular dependencies),2008-12-02T21:37:28ZBjoern A. Zeebbz@FreeBSD.org2008-12-02T21:37:28Zurn:sha1:4b79449e2fb67cb37c4c9f46d31791893a39ddd8
directly include only the header files needed. This reduces the
unneeded spamming of various headers into lots of files.
For now, this leaves us with very few modules including vnet.h
and thus needing to depend on opt_route.h.
Reviewed by: brooks, gnn, des, zec, imp
Sponsored by: The FreeBSD Foundation
Per email to arch@ a little while ago (that was greeted with silence),2008-09-01T23:59:00ZWarner Loshimp@FreeBSD.org2008-09-01T23:59:00Zurn:sha1:9e51595ce660d915899019d03075d8c17f3732d3
prefer the more common > ${.TARGET} over > opt_foo.h in modules
makefiles.
Link pf 4.1 to the build:2007-07-03T12:46:08ZMax Laiermlaier@FreeBSD.org2007-07-03T12:46:08Zurn:sha1:60ee384760646565a24320d92c5219bc052ce947
- move ftp-proxy from libexec to usr.sbin
- add tftp-proxy
- new altq mtag link
Approved by: re (kensmith)
Introduce a new entry point, mac_create_mbuf_from_firewall. This entry point2006-09-12T04:25:13ZChristian S.J. Peroncsjp@FreeBSD.org2006-09-12T04:25:13Zurn:sha1:d94f2a68f8c39a5abc9ba9c58e959f31bc90194d
exists to allow the mandatory access control policy to properly initialize
mbufs generated by the firewall. An example where this might happen is keep
alive packets, or ICMP error packets in response to other packets.
This takes care of kernel panics associated with un-initialize mbuf labels
when the firewall generates packets.
[1] I modified this patch from it's original version, the initial patch
introduced a number of entry points which were programmatically
equivalent. So I introduced only one. Instead, we should leverage
mac_create_mbuf_netlayer() which is used for similar situations,
an example being icmp_error()
This will minimize the impact associated with the MFC
Submitted by: mlaier [1]
MFC after: 1 week
This is a RELENG_6 candidate
Reimplementation of world/kernel build options. For details, see:2006-03-17T18:54:44ZRuslan Ermilovru@FreeBSD.org2006-03-17T18:54:44Zurn:sha1:e1fe3dba5ce2826061f6489765be9b4a341736a9
http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html
The src.conf(5) manpage is to follow in a few days.
Brought to you by: imp, jhb, kris, phk, ru (all bugs are mine)
The `pf' and `pflog' sources do not depend on DEV_PF or DEV_PFLOG,2006-03-09T15:48:45ZYaroslav Tykhiyytykhiy@gmail.com2006-03-09T15:48:45Zurn:sha1:10dbb44a9f290c3557840dc72cdeb6e72477c1fa
which is normal for own files of a device driver.
DEV_FOO should be used if an unrelated kernel file needs to know of
the `foo' driver's static presence. Obviously, module source files
should never use DEV_*.
Make pflog a seperate module. As a result pflog_packet() becomes a function2006-02-05T17:17:32ZMax Laiermlaier@FreeBSD.org2006-02-05T17:17:32Zurn:sha1:5bba2114d0aeb3adc36f08ea8c5a0712f29c2e76
pointer that is declared in pf_ioctl.c
Requested by: yar (as part of the module build reorg)
MFC after: 1 week
X-MFC with: yar's module reorg