Reducing the need to compile a custom kernel
Alexander at Leidinger.net
Tue Feb 14 10:31:56 UTC 2012
Quoting Paul Schenkeveld <freebsd at psconsult.nl> (from Fri, 10 Feb 2012
> On Fri, Feb 10, 2012 at 02:56:04PM +0100, 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?
> - 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
Embedded devices are out of the scope of this, normally you do a lot
of other modifictions to such systems anyway, so a custom kernel
should be not a big problem.
I will also not touch the dual-stack part of the kernel config (it
shall still allow the generic purpose computing like the GERNERIC
> - IPSTEALTH, IPSEC, IPSEC_FILTERTUNNEL, IPFILTER, ALTQ for firewalls
> 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.
The 386 part (which we do not have anymore in GENERIC) made a
difference, the rest doesn't hurt in the kernel.
Smuggling... It's not just a job, it's an adventure!
-- paid for by your local Colombian recruiting office
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
More information about the freebsd-stable