requires that some ordering requirements are checked by the
back-end C code instead of the parser (dirspecs, maxpart).
* Be more careful to require newline tokens in the grammer where
they are expected, and deal with blank lines, etc. This allows
elimination of a trailing context on newline in the scanner.
* Let the parser set values for "needs-count" and "needs-flag"
instead of making those special cases in the scanner.
* Get rid of '= ' preceeding actions (obsolete yacc syntax)
* Make the scanner not insert an extra newline after includes.
(It was just an accidental side-effect of the ENDFILE stuff.)
on tech-kern. (See man page.) Implementation by Greg Hudson.
Also, remove special case for i386 in vector handling, although this code isn't
actually used any more.
in XXX-marked comments in the recent attachment changes), this was a
long-standing bug in config.
The problem: If a device is attached to a device via an attribute exported
by that device (i.e. foo* at bar0, where 'bar' exports an attribute that
'foo' attaches to), but the device attached to is not present in the
kernel configuration file, AND another device which exports an attribute
that 'foo' attaches to _is_ present (e.g. a device baz0, if one could
specify 'foo0 at baz0'), then: the configuration file will (incorrectly)
be accepted by config, and the resulting ioconf.c will include a bogus
cfdata entry for the device (in the example, 'foo*'). This typically
causes the resulting kernel to crash during autoconfiguration.
The solution: Be much more careful about keeping track of where a device
was attached, and, in particular, if a device was attached to another device,
_always_ keep track of what device it was attached to. Then, when
cross-checking, if the attached-to device isn't present, give up and do not
check attributes. Also, document the process much more thoroughly.
used for checking device attachment names as are used for device name
checking, because device names can be used as attachment names. (Actually,
less strict rules could be used, but there's little point in that.) This
was not a mistake of design, this was just a mistake; i misunderstood
the devbase name checking code.
right/consistent. If you had something like:
file file.c foo bar baz needs-flag
and any one of foo, bar, or baz caused it to be brought into the compile,
in the header you'd end up with:
#define NFOO 1
#define NBAR 1
#define NBAZ 1
even if only one of them were selected. Other headers might have had a
different (inconsistent) set of definitions, depending on whether any of
their components were included, and any files necessary for the unspecified
options would not actually be present in the Makefile files list. The
correct behaviour for the example above if only 'foo' is selected by
the config file is:
#define NFOO 1
#define NBAR 0
#define NBAZ 0
which is what config now does. This bug has been present for a while.
(I don't know for sure that it was present in 4.4-Lite2, but from looking
at the Lite2 config sources, it appears to be there.)
- split softc size and match/attach out from cfdriver into
a new struct cfattach.
- new "attach" directive for files.*. May specify the name of
the cfattach structure, so that devices may be easily attached
to parents with different autoconfiguration semantics.
lists to not have a newline properly emitted. (It was emitting a
newline only if the line position was != 7. However, the only time the
line position was 7 was right after the initial variable assignment
string (e.g. "OBJS=\t") was printed.)
gwr