If a default is specified then the option is always defined in the
corresponding .h file.
Particularly useful for parameters where the default action isn't the
same a defining the value zero, given that the current use of #if defined(opt)
is open to problems wehere the relevant .h file isn't actually included, so
requiring an option to always have a value makes sense.
Also included (but commented out) is code that adds a global symbol to
the object file to stop objects compiled with different values for the
same option being linked together - I'm not quite happy with it yet!
obsolete defflag <option> [, <option> [, ...]]
obsolete defparam <option> [, <option> [, ...]]
The two statements actually do the same thing (there could be only one),
but it makes things less cryptic that way. The optional ": deps" part of
a 'defflag' or 'defparam' still has to be dropped when it gets obsoleted.
When the user has 'options OBSOLETE_OPTION' in his configuration file, it
is ignored (that is, opt_*.h files are generated as if it wasn't there),
and the user gets a warning about it.
Bump version to 20060525.
When someone first uses that syntax in the tree, a "version 20060525"
statement should be added before its occurrence, preferably at the top
of sys/conf/files.
Suggested by Matt Thomas a few months ago.
error out in a bit more friendly way when the user is trying to use
config(1) on a too old or too recent source tree.
To achieve that, introduce the "version NUMBER" statement which can be use
about anywhere in the config files. Also, use two defines, CONFIG_VERSION
(which is the actual version of binary), and CONFIG_MINVERSION, which is
the minimum version the binary supports.
Allowing a range of versions serves several purposes: first it allows me
to introduce the versioning without requiring it to be used right away in
the kernel tree, which means it will be possible to introduce new features
of config(1) rather progressively in the future. E.g., using 'no pci' in
a config file could only require the new version in that config file, so
that the rest remains compatible.
In the end, an actual bump of the main config system (i.e., in conf/files)
will only be required when e.g., ioconf.c semantics change.
(Mostly-)silently accepted on tech-kern. Error messages turned into
correct and meaningful English thanks to Tracy and Perry.
no device at <attachment>
<attachment> can take two forms: either numbered/wildcarded, in which
case only exactly matching instances will be removed, or plain (with
no number or wildcard), in which case all matching instances will be
removed.
When <attachment> is a plain interface attribute, all instances using
that attribute (either directly or through an explicit device) will be
removed.
E.g.:
auich* at pci? dev ? function ?
audio0 at audiobus?
audio1 at auich?
audio* at auich0
no device at auich0 -> removes audio*
no device at auich? -> removes audio1
no device at auich -> removes audio1 _and_ audio*
no device at audiobus? -> removes audio0
no device at audiobus -> removes audio0, audio1 and audio*
no <device>
As in the previous case, <device> can either be numbered/starred, in
which case all exactly matching instances are removed, or plain, in
which case all instances of the device are removed.
E.g.: (continuing previous example)
no audio* -> removes 'audio* at auich0'
no audio -> removes all audio instances
dsl