Date: Fri, 10 Feb 2012 17:56:58 +0200 From: Panagiotis Christias <p.christias@noc.ntua.gr> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel Message-ID: <4F353E4A.6030903@noc.ntua.gr> In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/2/2012 15:56, 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 which 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? Hello, we are currently using on every server (in order to maintain a single custom kernel) the following options: IPFIREWALL IPFIREWALL_DEFAULT_TO_ACCEPT IPFIREWALL_FORWARD ROUTETABLES=n Soon, we will also add: IPSEC IPSEC_FILTERTUNNEL IPSEC_NAT_T crypto enc Finally, once we upgrade our jail setup VIMAGE will be also a must. Regards, Panagiotis -- Panagiotis J. Christias Network Management Center p.christias@noc.ntua.gr National Technical Univ. of Athens, GREECE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F353E4A.6030903>