Date: Mon, 23 Dec 1996 01:07:38 +0100 (MET) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-current@FreeBSD.org (FreeBSD-current users) Cc: toor@dyson.iquest.net (John S. Dyson) Subject: Making an option `supported' Message-ID: <199612230007.BAA20781@uriah.heep.sax.de> In-Reply-To: <199612222341.SAA00651@dyson.iquest.net> from "John S. Dyson" at "Dec 22, 96 06:41:37 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
(I dare to send this in public, since i don't assume i'd violate any privacy... but think there's public demand for it.) As John S. Dyson wrote: (regarding how to make a kernel option `supported') > Thanks, I didn't even know what was necessary to do it. Well, fairly simple: First, edit sys/conf/options (or sys/i386/conf/options.i386), and select an opt_foo.h file where your new option would best go into. If there's already something that comes close to the purpose of the new option, pick this. As for the MAXDSIZ option, i felt that opt_rlimit.h was a good choice (the OPEN_MAX and CHILD_MAX options already went there). If there's no opt_foo.h already available for the intended new option, invent a new name. Make it meaningful, and comment the new section in the options[.i386] file. config(8) will automagically pick up the change, and create that file next time it is run. Packing too many options into a single opt_foo.h will cause too many kernel files to be rebuilt when one of the options has been changed in the config file, while creating too many opt_foo.h's does apparently no good either. Finally, find out which kernel files depend on the new option. find /sys -name type f | xargs fgrep NEW_OPTION is your friend in finding them. Go and edit all those files, and add #include "opt_foo.h" _on top_, before all the #include <xxx.h> stuff. The sequence is most important in case the options will override some defaults from the regular include files, where the defaults are protected by #ifndef NEW_OPTION #define NEW_OPTION (something) #endif in the regular header. The purpose of all this procedure is that we can eventually kill the ugly removal of the compile directory again in the next release, since changing any supported option in the config file will be automatically picked up again during the compilation by all the dependencies. Of course: "Don't forget to do a ``make depend''." :-) (Right now, the options UFS etc. are the worst offenders.) p.s.: Where in the docs would this notice go best into? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612230007.BAA20781>