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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10. Feb 2012, at 15:56 , Panagiotis Christias wrote: > On 10/2/2012 15:56, Alexander Leidinger wrote: >> Hi, >>=20 >> 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. >>=20 >> 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). >>=20 >> 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). >>=20 >> 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? >=20 > Hello, >=20 > we are currently using on every server (in order to maintain a single = custom kernel) the following options: >=20 > IPFIREWALL IPFIREWALL_DEFAULT_TO_ACCEPT loadable, tunable there for this > IPFIREWALL_FORWARD > ROUTETABLES=3Dn 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: >=20 > 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 --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B23C8B04-DBEF-45A3-8AC7-D57F591BC8B1>