Reducing the need to compile a custom kernel

Nenhum_de_Nos matheus at
Tue Feb 14 13:09:45 UTC 2012

On Tue, February 14, 2012 08:31, Alexander Leidinger wrote:
> Quoting Paul Schenkeveld <freebsd at> (from Fri, 10 Feb 2012
> 15:44:50 +0100):
>> 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
>>  - 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
> config).

I'm really curious why, if they are the piece of hardware that usually are worse to compile things
on, for access issues to poor hardware (great to compile kernel+world on i7, pain to do so in my

its a bummer to hear this :(


> Request noted.
>> 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.
> Bye,
> Alexander.
> --
> Smuggling... It's not just a job, it's an adventure!
> 		-- paid for by your local Colombian recruiting office
>    Alexander @ PGP ID = B0063FE7
>       netchild @  : PGP ID = 72077137
> _______________________________________________
> freebsd-stable at mailing list
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at"

We will call you Cygnus,
The God of balance you shall be

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

More information about the freebsd-stable mailing list