Custom kernel poll summary

[Julian Elischer]

On 2/14/12 7:43 AM, Ian Smith wrote:
> 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)

well it's not that big but you will be running extra code for every 
packet unless you want it.
when I made it an option but I was mainly trying to placate the "just 
say no" crowd.
I perswonally wouldn't  mind having it on by default in GENERIC, as 
long as we still make it an option
so people who want every last drop of cpu can remove it.
> 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
>