Date: Sun, 12 Feb 2012 18:52:37 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: stable@freebsd.org, ipfw@freebsd.org, Panagiotis Christias <p.christias@noc.ntua.gr> Subject: Re: Reducing the need to compile a custom kernel Message-ID: <20120212173339.G93710@sola.nimnet.asn.au> In-Reply-To: <B23C8B04-DBEF-45A3-8AC7-D57F591BC8B1@lists.zabbadoz.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <4F353E4A.6030903@noc.ntua.gr> <B23C8B04-DBEF-45A3-8AC7-D57F591BC8B1@lists.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 10 Feb 2012 16:12:00 +0000, Bjoern A. Zeeb wrote: > 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 Copying this to ipfw@ on finding that net.inet.ip.fw.default_to_accept tunable is not mentioned in any of ipfw(8), loader(8) nor tuning(7). > > IPFIREWALL_FORWARD Unless something's changed, julian@ has pointed out (paraphrasing) that this adds bits of code to various parts of the stack and was thought to impact performance too much when unused to conditionalise each instance. I'm unsure if this is the only case ipfw still needs building in kernel? cheers, Ian > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120212173339.G93710>