Quoting Paul Schenkeveld <[email protected]> (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
- 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
config).
- IPSTEALTH, IPSEC, IPSEC_FILTERTUNNEL, IPFILTER, ALTQ for firewalls
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
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
