From owner-freebsd-stable@FreeBSD.ORG Fri Feb 10 15:56:58 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A56A6106566B for ; Fri, 10 Feb 2012 15:56:58 +0000 (UTC) (envelope-from p.christias@noc.ntua.gr) Received: from ulysses.noc.ntua.gr (ulysses.noc.ntua.gr [IPv6:2001:648:2000:de::230]) by mx1.freebsd.org (Postfix) with ESMTP id 208228FC17 for ; Fri, 10 Feb 2012 15:56:57 +0000 (UTC) Received: from [147.102.224.69] (ovpn-69.noc.ntua.gr [147.102.224.69]) (authenticated bits=0) by ulysses.noc.ntua.gr (8.14.5/8.14.5) with ESMTP id q1AFutQ4009248 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 10 Feb 2012 17:56:55 +0200 (EET) (envelope-from p.christias@noc.ntua.gr) Message-ID: <4F353E4A.6030903@noc.ntua.gr> Date: Fri, 10 Feb 2012 17:56:58 +0200 From: Panagiotis Christias Organization: NTUA NOC User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120202 Thunderbird/11.0 MIME-Version: 1.0 To: Alexander Leidinger References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> In-Reply-To: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ulysses.noc.ntua.gr [147.102.222.230]); Fri, 10 Feb 2012 17:56:55 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97.3 at ulysses.noc.ntua.gr X-Virus-Status: Clean Cc: stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 15:56:58 -0000 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