New kernel configuration system

Wojciech A. Koszek
wkoszek@FreeBSD.org
http://FreeBSD.czest.pl/~wkoszek/

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.

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.

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:


Proposed syntax for the new kernel configurator a.k.a config2:

src/sys/conf/files

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
        
};

==== 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

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?"

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

               cat src/sys/conf/files src/sys/amd64/conf/KERNCONF > kconf
               config2 -f kconf

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 (last edited 2011-08-26 00:59:01 by WojciechKoszek)