Date: Tue, 14 Feb 2012 11:31:20 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Paul Schenkeveld <freebsd@psconsult.nl> Cc: freebsd-stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel Message-ID: <20120214113120.Horde.7fNzdpjmRSRPOjf4S1XjmXA@webmail.leidinger.net> In-Reply-To: <20120210144449.GA2358@psconsult.nl> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210144449.GA2358@psconsult.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Paul Schenkeveld <freebsd@psconsult.nl> (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=F6rn 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 =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120214113120.Horde.7fNzdpjmRSRPOjf4S1XjmXA>