Custom kernel poll summary (was: Re: Reducing the need to compile a
Alexander at Leidinger.net
Tue Feb 14 11:38:16 UTC 2012
Quoting Alexander Leidinger <Alexander at 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
2 VIMAGE -> not production ready (bz)
2 IPSEC_FILTERTUNNEL -> obsolete according to bz
2 IPFIREWALL_DEFAULT_TO_ACCEPT -> loader.conf:
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 ZERO_COPY_SOCKETS -> has known problems? can't find the
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 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 IPFIREWALL_FORWARD -> performance impact too big if
1 IPFILTER -> 2/3 firewalls can be loaded... and this one
is not really maintained anymore
1 IPDIVERT -> loader.conf: ipdivert_load='YES'
1 DUMMYNET -> loader.conf: dummynet_load='YES'
1 BREAK_TO_DEBUGGER -> loader.conf: debug.kdb.break_to_debugger
1 ALT_BREAK_TO_DEBUGGER -> loader.conf:
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?
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
2 SW_WATCHDOG -> should not hurt if not enabled
1 enc -> together with IPSEC
1 IPSTEALTH -> changes ipfw module only?
1 IPFIREWALL_VERBOSE_LIMIT=5 -> changes ipfw module only?
1 IPFIREWALL_VERBOSE -> changes ipfw module only?
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
More information about the freebsd-stable