the NetBSD-1.1 convention. Change the mainbus `struct confargs'
and the "generic" interrupt-establish method, used by devices that
appear on both a kn01 and TC decstations, to match.
Change the macros in autconf.h accordingly.
Add new device-attach struct cfattach le_tc_ca and struct cfdriver le_cd.
Change IOASIC cfdriver references from "ioasiccd" to "ioasic_cd".
Change "mainbuscd" to "mainbus_cd"
update the old-config to new-config glue used with the 4.4bsd/pmax
SCSI drivers to use new device attach declarations and names for
the "oldscsibus", "tz" and "rz" drivers.
change tc_submatch() to compile with the new device-attach scheme:
the TC bus uses a 'submatch' function which checks device locators
and then calls a match function.
Instead of calling cf->cf_driver->cd_match(), we now need to call
cf->cf_attach->ca_match().
Rename the extern declaration of `tccd' and `ioasiccd' in
src/sys/dev/tc/{tvar.h,ioasicvar.h", respectively, to be
`tc_cd' and `ioasic_cd', to match the 1.1B-style definitions.
only include the relevant code in the probe & attach functions. Still
one probe and one attach function, with #ifdefs, but this is a step
in the right direction and saves a few hundred bytes (ooh, ahh!).
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.
tls