Date: Mon, 23 Dec 1996 21:19:37 +1100 From: Bruce Evans <bde@zeta.org.au> To: freebsd-current@FreeBSD.org, j@uriah.heep.sax.de Cc: toor@dyson.iquest.net Subject: Re: Making an option `supported' Message-ID: <199612231019.VAA18449@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>(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. Most options should go in a header file by themself. Then the option file is automatically given a name related to the option if the file name is not given explicitly: option BAR -> file name opt_bar.h. >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, Right. opt_rlimit.h isn't all that good a choice for the new options. This header now has to be included in lots of places that have nothing to do with the OPEN_MAX and CHILD_MAX options. This defeats the point of defining the options in separate files. >while creating too many opt_foo.h's does apparently >no good either. It just increases the compilation overheads a little. It may force you to edit more files when you add a related option. This is an advantage :-). >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" You forgot the most important point :-): if a system header needs to be edited, then don't add the option. E.g., the CHILD_MAX and OPEN_MAX options should never have existed, because they break <limits.h>. The MAXDSIZ and DFLDSIZ options should not exist, since they break <machine/vmparam.h>. "opt_foo.h" can't be included since it would break the headers more seriously, but if it isn't included, then places that include it may get an inconsistent value for the option. Bugs in config related to this: when an option is removed from conf/options [.machine], the option isn't removed from the opt_foo.h file. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612231019.VAA18449>