Update the documentation of the vnode flags so that it lists only (and all)
of the flags understood by the program. (The documentation is likely in need
of more cleanup.)
'out' arg to svc_sendreply must point to a long if outproc is
xdr_long. It was pointing to an 'int', and that was crashing on the
alpha, due to bad alignment.
some machines (because on those (64-bit) machines, -1L is
0xffffffffffffffff, but a u_int32_t will never be sign extended).
Compare to 0xffffffff; that's what was really meant, anyway.
machines (Alpha). fixed sized types, not 'timeval's should go over
the net, and the stuff that goes over the net can't necessarily be
passed directly to functions that expect timevals.
order to match the function prototype and to work with compilers that
default to unsigned chars.
Compare the getopt() return value with -1 instead of EOF.
order to match the function prototype and to work with compilers that
default to unsigned chars.
Compare the getopt() return value with -1 instead of EOF.
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.
mycroft