Re: [CFT] modular kernel config

On Feb 21, 2012, at 3:35 PM, Alexander Leidinger wrote:

> Hi,
> 
> 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_at_
>   (see below)
> - loads as much as possible as a module
> 
> 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
> 
> 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).
> 
> 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.
> 
> 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.
> 
> 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_at_)
> - FLOWTABLE (disabled in loader.conf)
> - BPF_JITTER
> 
> 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.
> 
> 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).
> 
> Bye,
> Alexander.
> 
> -- 
> 
> http://www.Leidinger.net    Alexander _at_ Leidinger.net: PGP ID = B0063FE7
> http://www.FreeBSD.org       netchild _at_ FreeBSD.org  : PGP ID = 72077137
> 


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, 
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 :)