Reducing the need to compile a custom kernel

Volodymyr Kostyrko c.kworr at gmail.com
Fri Feb 10 16:01:45 UTC 2012


Alexander Leidinger wrote:
> 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?

The list would be too long for  me, that's a sample what I add to my 
MINIMAL after stripping GENERIC:

option DEVICE_POLLING
option BPF_JITTER
option DIRECTIO

option SC_ALT_MOUSE_IMAGE
option SC_MOUSE_CHAR=0x3

option ZERO_COPY_SOCKETS

option SW_WATCHDOG

option ALTQ
option ALTQ_CBQ
option ALTQ_RED
option ALTQ_RIO
option ALTQ_HFSC
option ALTQ_CDNR
option ALTQ_PRIQ
option ALTQ_NOPCC

device atpic
device mptable

I even don't use them on most machines however I prefer to build all 
machines from one kernel config however even this is impossible because 
for example I can't select scheduler by modules.

Some point can be superseded in future for example current work on ULE 
seems promising.

For example, why there are no modules for atpic and mptable? I don't 
need them on most machines but I can't load them at boot time.

-- 
Sphinx of black quartz judge my vow.


More information about the freebsd-stable mailing list