Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel)

[Ian Smith]

On Tue, 14 Feb 2012 2:37:55 +0100, Alexander Leidinger wrote:
 > 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---

[..]

 > 1 IPFIREWALL_FORWARD            -> performance impact too big if unused (julian)

I expect Julian will object if I've mis-paraphrased or over-simplified 
something I recall him saying at least a couple of years ago :)

[..]

 > 4 ALTQ*                          -> does add code to the pf module
 >                                    other impact?

ipfw(8) can also apply ALTQ tags, but relies on pfctl(8) to setup the 
queues - or so I read; I've not used it here.  From altq(4):

     ALTQ        Enable ALTQ.
     ALTQ_CBQ    Build the ``Class Based Queuing'' discipline.
     ALTQ_RED    Build the ``Random Early Detection'' extension.
     ALTQ_RIO    Build ``Random Early Drop'' for input and output.
     ALTQ_HFSC   Build the ``Hierarchical Packet Scheduler'' discipline.
     ALTQ_CDNR   Build the traffic conditioner.  This option is meaningless at
                 the moment as the conditioner is not used by any of the
                 available disciplines or consumers.
     ALTQ_PRIQ   Build the ``Priority Queuing'' discipline.
     ALTQ_NOPCC  Required if the TSC is unusable.
     ALTQ_DEBUG  Enable additional debugging facilities.

     Note that ALTQ-disciplines cannot be loaded as kernel modules.  In order
     to use a certain discipline you have to build it into a custom kernel.
     The pf(4) interface, that is required for the configuration process of
     ALTQ can be loaded as a module.

So which disciplines would one choose?  Seeming an unlikely candidate?

 > 1 IPSTEALTH                      -> changes ipfw module only?

I don't think this is specific to ipfw.  From /sys/conf/NOTES:

# IPSTEALTH enables code to support stealth forwarding (i.e., forwarding
# packets without touching the TTL).  This can be useful to hide firewalls
# from traceroute and similar tools.

But can it be disabled once added to kernel?  It's no good as a default.

 > 1 IPFIREWALL_VERBOSE_LIMIT=5     -> changes ipfw module only?
 >                                    loader tunable?
 > 1 IPFIREWALL_VERBOSE             -> changes ipfw module only?
 >                                    loader tunable?

sysctl.conf: net.inet.ip.fw.verbose and net.inet.ip.fw.verbose_limit

cheers, Ian