Reducing the need to compile a custom kernel

[Paul Schenkeveld]

On Fri, Feb 10, 2012 at 02:56:04PM +0100, 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 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?

 - INET without INET6
 - SOFTUPDATES, UFS_ACL, AUDIT, SCTP (left out for embedded devices)
 - Björn may add INET6 without INET
 - SCHED_ULE vs. SCHED_4BSD
 - No vga console/atkbd/psm for embedded devices
 - CPU_SOEKRIS, CPU_GEODE, CPU_ELAN, NO_SWAPPING for embedded devices
 - IPSTEALTH, IPSEC, IPSEC_FILTERTUNNEL, IPFILTER, ALTQ for firewalls
 - probably more

I also always specify exactly one CPU type (on i386), know it made a
difference in the 386/486/586 era but am not sure how much difference
it makes nowadays.

HTH

Paul Schenkeveld