Reducing the need to compile a custom kernel

Bjoern A. Zeeb bzeeb-lists at lists.zabbadoz.net
Fri Feb 10 16:12:07 UTC 2012


On 10. Feb 2012, at 15:56 , Panagiotis Christias wrote:

> On 10/2/2012 15:56, Alexander Leidinger wrote:
>> Hi,
>> 
>> during some big discussions in the last monts on various lists, one of
>> the problems was that some people would like to use freebsd-update but
>> can't as they are using a custom kernel. With all the kernel modules we
>> provide, the need for a custom kernel should be small, but on the other
>> hand, we do not provide a small kernel-skeleton where you can load just
>> the modules you need.
>> 
>> This should be easy to change. As a first step I took the generic kernel
>> and removed all devices which are available as modules, e.g. the USB
>> section consists now only of the USB_DEBUG option (so that the module is
>> build like with the current generic kernel). I also removed some storage
>> drivers which are not available as a module. The rationale is, that I
>> can not remove CAM from the kernel config if I let those drivers inside
>> (if those drivers are important enough, someone will probably fix the
>> problem and add the missing pieces to generate a module).
>> 
>> 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 which 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?
> 
> Hello,
> 
> we are currently using on every server (in order to maintain a single custom kernel) the following options:
> 
> IPFIREWALL IPFIREWALL_DEFAULT_TO_ACCEPT

loadable, tunable there for this

> IPFIREWALL_FORWARD



> ROUTETABLES=n

melifaro and I are working on this; he'll fix the netgraph netflow part and I'll fix the #ifdefs and the tunable will be enough.


> Soon, we will also add:
> 
> IPSEC IPSEC_FILTERTUNNEL IPSEC_NAT_T crypto enc

IPSEC_FILTERTUNNEL has long been obsolete.


> Finally, once we upgrade our jail setup VIMAGE will be also a must.

I have read that multiple times already and I'd love to but that's a looong way.
The plan might be to one day provide a 2nd kernel to install from and that freebsd-update can handle but we'll see.

/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
   It does not matter how good you are. It matters what good you do!



More information about the freebsd-stable mailing list