Date: Thu, 1 Mar 2012 12:27:02 +0200 From: Nikolay Denev <ndenev@gmail.com> To: Alexander Leidinger <Alexander@leidinger.net> Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: [CFT] modular kernel config Message-ID: <2F3C6FA2-4045-4022-A317-42CF616A84A8@gmail.com> In-Reply-To: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net> References: <20120221143537.Horde.deyFDZjmRSRPQ52pxBIpnLA@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 21, 2012, at 3:35 PM, Alexander Leidinger wrote: > Hi, >=20 > I created a kernel config for i386/amd64 (should work on -current and = 9.x) and a suitable loader.conf which: > - tries to provide as much features as GENERIC (I lost one or two disk > controllers, they are not available as a module... or I didn't find > them) > - incorporates some more features based upon a poll on stable@ > (see below) > - loads as much as possible as a module >=20 > I've compile-tested them on i386 and amd64, but I didn't had time yet = to give it a try on a spare machine. I may get some time next week to = test (i386 only). It would be nice if someone could help testing: > - compile the kernel > - make _sure_ you have a way to recover the system in case > the new kernel+loader.conf fails > - verify that the example loader.conf contains all devices > which are important for you > - copy the example loader.conf to /boot/loader.conf > - give it a try >=20 > You can download from > http://www.Leidinger.net/FreeBSD/current-patches/ > The files are > - i386_SMALL > - i386_SMALL_loader.conf > - amd64_SMALL > - amd64_SMALL_loader.conf > I didn't provide direct links for eqch one on purpose. If you do not = know how to recover a system with an unsuitable loader.conf, don't give = this a try (you could check a diff between GENERIC and SMALL, and make = sure all removed devices which are imporant for you are in the = loader.conf). They should work on -current and on 9.x, for 8.x I'm not = sure if it woll work without removing some stuff (GENERIC on 8.x comes = without some more debugging options, make sure you don't get surprised = by them, but those may not be the only differences). >=20 > I didn't use the name MODULAR on purpose, I've chosen a name where the = first letter does not yet exist in the kernel config directory, to make = tab-completion more easy. If you are not happy with the name, keep your = opinion for yourself please, until after you tested this on a (maybe = virtual) system. >=20 > The loader.conf was generated with a script from a diff between = GENERIC and SMALL, if there's a name mismatch between the config-name = and the module-name, the script may have missed the module (I added some = missing sound modules, but I may have overlooked something). You better = double-check before giving it a try. The loader.conf is also supposed to = disable some features (at the end of the file) which are new compared to = what is in GENERIC, if the particular feature could cause a change in = behavior. >=20 > The new stuff in the kernel config compared to GENERIC is (in order of = number of requests from users): > - IPSEC (+ device enc + IPSEC_NAT_T) > - ALTQ > - SW_WATCHDOG > - QUOTA > - IPSTEALTH (disabled in loader.conf) > - IPFIREWALL_FORWARD (touches every packet, power users which need > a bigger PPS but not this feature can recompile the kernel, > discussed with julian@) > - FLOWTABLE (disabled in loader.conf) > - BPF_JITTER >=20 > In the poll there where some more options requested, but most of them = can be handled via the loader or sysctl (e.g. the firewalls can be = loaded as modules). For some of them I added some comments at the end of = the SMALL config to make it more easy to find the correct way of = configuring them. Doc-committers may want to have a look, maybe there's = an opportunity to improve existing documentation. >=20 > I'm interested in success reports, failure reports, and reports about = missing stuff in loader.conf (mainly compared to the devices available = in GENERIC, but missing stuff which could help getting a system = installed and booted is welcome even if what you propose is not in = GENERIC). >=20 > Bye, > Alexander. >=20 > --=20 >=20 > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D = 72077137 >=20 Just an idea : Ship FreeBSD with all the kernel object files (even compile different versions of them, let's say networking with = IPFORWARD and networking without), and then let the user relink the kernel with some shell script. This way freebsd-update can binary update the object files,=20 and then relink the users's kernel. This of course will probably need some infrastructure work to make it = possible. P.S.: As I said, just an idea off the top of my head :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2F3C6FA2-4045-4022-A317-42CF616A84A8>