Date: Fri, 10 Feb 2012 16:12:00 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Panagiotis Christias <p.christias@noc.ntua.gr> Cc: stable@freebsd.org Subject: Re: Reducing the need to compile a custom kernel Message-ID: <B23C8B04-DBEF-45A3-8AC7-D57F591BC8B1@lists.zabbadoz.net> In-Reply-To: <4F353E4A.6030903@noc.ntua.gr> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <4F353E4A.6030903@noc.ntua.gr>
index | next in thread | previous in thread | raw e-mail
On 10. Feb 2012, at 15:56 , Panagiotis Christias wrote: > 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 loadable, tunable there for this > IPFIREWALL_FORWARD > ROUTETABLES=n melifaro and I are working on this; he'll fix the netgraph netflow part and I'll fix the #ifdefs and the tunable will be enough. > Soon, we will also add: > > IPSEC IPSEC_FILTERTUNNEL IPSEC_NAT_T crypto enc IPSEC_FILTERTUNNEL has long been obsolete. > Finally, once we upgrade our jail setup VIMAGE will be also a must. I have read that multiple times already and I'd love to but that's a looong way. The plan might be to one day provide a 2nd kernel to install from and that freebsd-update can handle but we'll see. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B23C8B04-DBEF-45A3-8AC7-D57F591BC8B1>