things may happen in a parallel build - especially with rules like the
automatic size adjustment for SYMTAB_SPACE, see long standing failure of
evbarm on the build cluster.
Easy fix: .WAIT for each config to complete, before going on with the
next. Low impact, only minor loss of paralellism, and only in cases where
needed.
instead of using struct nvlist.
(struct nvlist holds lists (or trees!) of semi-arbitrary stuff with no
structure and almost no type safety; it should go away.)
(This allows cleaning up when a syntax error occurs, because yacc just
dumps the parser stack on the floor.)
The new logic can handle arbitrary data types instead of being limited
to struct nvlist.
This was nagging me already yesterday, but I decided to leave it
alone for better compat with old ioconf.c builds. But as it turns
out, new code depends on newly built ioconf.c with a new config(1)
anyway, so renaming is not an issue (at least not at this stage).
While renaming, namespace cfdriver and cfattach in "ioconf" rather
than "comp", since the former reflects the config(5) keyword.
with the also-experimental ioconf keyword. pseudo-root allows to
specify a root at any point in the device tree without having
attachments from the actual root.
For example, instead of having a config file like this:
mainbus0 at root
bus_a? at mainbus0
bus_b? at bus_a*
device7 at bus_b?
You can have one like this:
pseudo-root bus_b*
device7 at bus_b?
This will produce the relevant ioconf.c glue for device number 7
only instead of the whole 9 yards from root. Perhaps needless to
say, this can be used to generate snippets of config glue for
modules and, let's not deny that my main motivation for doing this,
rump components.
This is part 2/3 of my modifications to config (the last part is
autogenerating source file lists and component Makefiles).
No strong objection from cube (after a little pressuring ;), but
like he said, the implementation will most likely need some more
tweaking and may not work correctly under all pseudo-root uses yet.
This is done by giving the "ioconf" keyword in the config file.
As a result, config produces only ioconf.c and locators.h. Currently,
only "monolithic" configurations with the device path starting from
root are supported. Eventually, the goal is to support a local
root in the input file from any point along the device tree using
files.* in our kernel tree. This will make autogenerating the
config glue for device modules possible instead of having to write
it by hand like is currently required (yes, it sounds simple to
implement, but ...).
reviewed by cube.
(the next part will demand major discussions with you, so prepare ;)
ht_new()... So actually rename it to condmkoptions to avoid confusion.
Reported build failure on amd64 (strange that I wouldn't get it on i386) on
current-users by Kurt Schreiner.
