Quoting Alexander Leidinger <alexan...@leidinger.net> (from Fri, 10
Feb 2012 14:56:04 +0100):
Such a kernel would cover situations where people compile their own
kernel because they want to get rid of some unused kernel code (and
maybe even need the memory this frees up).
The question is, is this enough? Or asked differently, why are you
compiling a custom kernel in a production environment (so I rule out
debug options zhich are not enabled in GENERIC)? Are there options
which you add which you can not add as a module (SW_WATCHDOG comes
to my mind)? If yes, which ones and how important are they for you?
Here is what I got, the first column is the number of requests, the
second what is requested, and the 3rd my comments (basically it means,
if there is a comment, it is not needed/possible to include in a
modular kernel):
---snip---
5 IPSEC
4 ALTQ
2 VIMAGE -> not production ready (bz)
2 SW_WATCHDOG
2 IPSEC_FILTERTUNNEL -> obsolete according to bz
2 IPFIREWALL_DEFAULT_TO_ACCEPT -> loader.conf:
net.inet.ip.fw.default_to_accept
2 IPFIREWALL -> loader.conf: ipfw_load='YES'
2 HZ=1000 -> loader.conf: kern.hz
2 DEVICE_POLLING -> ifconfig in 9.0 handles this at runtime?
1 enc
1 ZERO_COPY_SOCKETS -> has known problems? can't find the
reference,
but I removed it from my kernels
1 SC_* options -> not a generic setting, will not include
1 ROUTETABLES=n -> bz is working on this
1 QUOTA
1 PF -> loader.conf: pf_load='YES'
1 MROUTING -> loader.conf: ip_mroute='YES'?
1 KTR -> rare use case, kernel recompile is OK
1 KDTRACE_HOOKS -> legal review needed
1 KDB_UNATTENDED -> re@ wants this, but has reservations
1 KDB_TRACE -> re@ wants this, but has reservations
1 KDB -> re@ wants this, but has reservations
1 IPSTEALTH
1 IPSEC_NAT_T
1 IPFIREWALL_VERBOSE_LIMIT=5
1 IPFIREWALL_VERBOSE
1 IPFIREWALL_FORWARD -> performance impact too big if
unused (julian)
1 IPFILTER -> 2/3 firewalls can be loaded... and this one
is not really maintained anymore
1 IPDIVERT -> loader.conf: ipdivert_load='YES'
1 GDB
1 FLOWTABLE
1 DUMMYNET -> loader.conf: dummynet_load='YES'
1 DIRECTIO
1 DDB_NUMSYM
1 DDB
1 BREAK_TO_DEBUGGER -> loader.conf: debug.kdb.break_to_debugger
1 BPF_JITTER
1 ALT_BREAK_TO_DEBUGGER -> loader.conf:
debug.kdb.alt_break_to_debugger
---snip---
Yes, this poll is not representative...
So... what's the impact of including the following options into a
kernel which is intended to be modular, respectively are there reasons
to _not_ include one of the following?
---snip---
5 IPSEC -> we do not have a separate cryto
dist, so it should be possible
to include in a kernel now...
legal advise needed
4 ALTQ* -> does add code to the pf module
other impact?
2 SW_WATCHDOG -> should not hurt if not enabled
in rc.conf
1 enc -> together with IPSEC
1 IPSTEALTH -> changes ipfw module only?
1 IPSEC_NAT_T
1 IPFIREWALL_VERBOSE_LIMIT=5 -> changes ipfw module only?
loader tunable?
1 IPFIREWALL_VERBOSE -> changes ipfw module only?
loader tunable?
1 FLOWTABLE
1 DIRECTIO
1 BPF_JITTER
---snip---
Bye,
Alexander.
--
Q: What is purple and concord the world?
A: Alexander the Grape.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
