SunOS 4.x users will love you. :-)
Adrian On 1 March 2012 02:27, Nikolay Denev <nde...@gmail.com> wrote: > 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-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
