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.
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.)
This fix is a kludge:
- make the nfs filehandle conditional on v2 and v3
- set the nfs_args fields for the version and the
file handle size.
- make the file handle pointer type void * so that
it works on both nfsv2 and nfsv3
- fix the mountd rpc results parsing.
A proper fix should:
- register an nfsv3 server for amd.
- make amd try v2/v3 mounts exactly like mount_nfs does.
- understand the nfsv3 mount options.
- cleanup the #undef's in the protocol header.
Also in order to auto-recognize v2 vs v3, I moved the inclusion of
<sys/mount.h> to am.h.
