config syntax for modules

[David Holland <dholland-tech%netbsd.org@localhost>]

As has been previously suggested, I am planning to add module syntax
to config(1); namely "module options FOO" and "module dev* at bus?"
and so forth, to indicate that the element so named should be built as
a module.

At first this will have no effect in config vs. not listing the
element at all, but it will allow writing the off-the-shelf kernel
configs in a clearer way. That is, if something is going to be built
as a module, adding "module" to its config line will prevent it from
being compiled in, while making it clear what the situation is.

In the longer run I expect this syntax should be linked to (1) only
allowing autoload of an element from a module if it was configured as
a module, and probably also (2) selecting what modules should be built
at all. (I'm aware the latter point has been contentious. I fail to
see why people with slow machines should be obliged to compile
bazillions of modules they know they'll never use.) Also probably it
should be possible to wire down a particular attachment but still
build the driver as a module.

The question at hand (using "options DDB" as an example kernel element
because it's short) is whether "no module options DDB" should be legal
syntax and what it should mean.

Alternative 1:

   options DDB          means ddb should be compiled into the kernel
   module options DDB   means ddb should be available as a module
   no options DDB       means ddb should not be available

   In this alternative, each of these reflects one of three possible
   states; the directives may appear in any order and the last one to
   appear selects the configured behavior.

Alternative 2:

   options DDB          means ddb should be compiled into the kernel
   no options DDB       means ddb should not be compiled into the kernel
   module options DDB   means ddb should be available as a module
   no module options DDB means ddb should not be available as a module

   In this alternative, "no" cancels a previous statement of the same
   kind without "no". Canceling a statement that has not been made is
   an error; and since having "options DDB" and "module options DDB"
   in effect at once is meaningless, one must be cancelled before the
   other can be applied.

Alternative 3:

   Same as alternative 2, except that if "module options DDB" and
   "options DDB" are both in effect at once, ddb is compiled in.

(Others?)

My thoughts so far are that while alternatives 2 and 3 are a more
obvious generalization of the existing config logic, alternative 1
may ultimately make more sense.

-- 
David A. Holland
dholland%netbsd.org@localhost