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@ > (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@) > - 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 @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ 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 :) _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
