Show pageOld revisionsBacklinksBack to top This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong. ====== New kernel configuration system ====== //Wojciech A. Koszek// \\ ''%%wkoszek@FreeBSD.org%%'' \\ Current kernel configuration system has its roots in old BSD days. It's similar to ''%%sysinstall%%'' -- it does the job, but the %%FreeBSD%% world would be a bit better with having different/better ''%%config(8)%%''. The goal of the page is to list config(8) limitations and problems hitting us in %%FreeBSD%%-9 times. This may be a root of "config(8) suck less" project. <code> This page contains some ideas about config(8) in random order. Some are outdated, but later ones are relatively new. Keep that in mind while studying this page. </code> ===== New version of config(8): requirements ===== Current implementation of kernel configuration tool has a lot of problems and shortcomings that make a life of typical %%FreeBSD%% user much hard. Below I try to address them: * build all .c files just once, and use object files to create the kernel and modules * right now we actually compile kernel twice--for the %%%%kernel //and %%%%modules// separately * support dependencies -- right now when some option is missing, you'll get link time error * try to keep nice structure of ''%%conf/files%%'', since it's relatively easy to insert file there * this is stricly related with entry above * **do NOT block advanced users from providing their own .o (custom) files if they want it** (Peter) * support out-of-tree module build * or at least be smart enough to let us to remove (or limit) src/sys/modules; stay away from empty ''%%opt_*.h%%'' recreation. * support "kernel will accept this KLD for sure and won't panic": * compile the kernel against particular kernel -- if the kernel has INVARIANTS, KLD should be compiled with INVARIANTS as well. * DSL implemented: * instead of ''%%nooption nosomething%%'' or ''%%enable disable%%'' I want "if (something) { static mydriver; }". Not 1st priority requirement, but would be nice to have. * be able to configure cross-arch kernels * include whole ''%%src/sys%%'' stuff :-) (''%%imp@%%'') * include only .c files, from which kernel has been built (''%%des@%%'') * ''%%INCLUDE_CONFIG_FILE%%'' should include comments in the generated output ---- Proposed syntax for the new kernel configurator a.k.a config2: ==== src/sys/conf/files ==== <code> component kernel { files { kern_main.c, kern_exec.c, [...] }; }; component md { files { md.c }; }; component mii { files { mii.c }; }; component acphy { files { dev/mii/acphy.c }; depends { mii }; }; component amphy { files { dev/mii/amphy.c }; depends { mii }; }; component miibus { embed { mii, amphy, acphy }; }; component em { compile_with "${NORMAL_C} -I$S/dev/e1000"; // compile_with can take block or a string files { dev/e1000/if_em.c dev/e1000/if_lem.c dev/e1000/if_igb.c dev/e1000/e1000_80003es2lan.c dev/e1000/e1000_82540.c [...] }; }; component ipwibssfw { compile_with { // compile_with as a block + possibility of line breaking ${AWK} -f $S/tools/fw_stub.awk ipw_ibss.fw:ipw_ibss:130 -lintel_ipw -mipw_ibss -c${.TARGET} }; clean "ipwibssfw.c"; // I think we could either accept {} block or a string for single statements no_implicit_rule; before_depend; local }; </code> %%=%%=== Seriously ponder ===== Lua's syntax is almost perfect for explaining this datastructure. (it looks almost the same)... ---- Keyword **component** would define what functionality is provided. Keyword **files** would be used to start a block with //c// files enlisted. Keyword **embed** just picks the content of previous blocks and merges them in a current block. Keyword **compile_with** sets the generation command Keywords **no_implicit_rule**, **before_depend**, **local** stay as they were. ==== src/sys/<arch>/conf/GENERIC ==== <code> static kernel; // This could eventually be implicit // From DEFAULTS we would be picking architecture name. // So for 'i386' there would be component i386 { ...} // also included as either 'static i386' (easiest, the best for me) // or we could just make 'machine' keyword be an implicit 'static i386' static md; // Instead of 'device md' you'd just device if it's staticly in the kernel makeoptions "DEBUG=-g" // This stays. Not much harm. options SCHED_ULE # Some options would stay. I want my 1st work *NOT* address options PREEMPTION # the eventual problems with '''options'''; but the suggestions options INET # are always welcome. options INET6 # options NFSCL # Some options COULD probably be just options NFSD # included as "static nfscl" options NFSLOCKD # Why would NFS be included as an "options?" </code> With "components" and dependencies, //src/sys/modules// could go away, so modules would be built 'for free'. And kernel configuration would only enlist things necessary for components that we want to link staticly. ==== Parsing ==== In my view, we should use the same parsing for //src/sys/conf/files' and// src/sys/%%<%%arch>/conf/KERNCONF//, so that// <code> cat src/sys/conf/files src/sys/amd64/conf/KERNCONF > kconf config2 -f kconf </code> is possible. The reason is that for development, I'd like to have kern_something.c included from my KERNCONF and the whole case with parsing would just be simplified. The idea which Peter prototyped already in the past was to use //config(8)// to dump configuration data in the form of easily parseable tables, which would later get consumed by scripts. It would be scripts that generate Makefiles and other metadata files necessary by a boot process. ---- Study once again conversations from 2007-05-16- newconfig.txt Last modified: 2015/09/23 05:01by WojciechKoszek