candidate for this is "npx0", more are likely to follow.
Check for pseudo-devices that are being configured, but don't appear
in any "files" file. The ``pseudo-device bpf 2'' already hit me too
often.
follow.
* Rename/reorder all of the pccard structures, change many of the member
names to be descriptive, and follow more closely other 'bus' drivers
naming schemes.
* Rename a bunch of parameter and local variable names to be more
consistant in the code.
* Renamed the PCCARD 'crd' device to be the 'card' device
* KNF and make the code consistant where it was obvious.
* ifdef'd out some unused code
o Add missing $Id$s
o Move extern decls from .c -> .h files
o Staticize
o Remove #includes from .h files
o style(9)ify includes
o bcopy -> memcpy
bzero -> memset
bcmp -> memcmp
index -> strchr
rindex -> strrchr
o Move timeout.h -> timer.h (making it consistent w/ timer.c)
o Add -Wmissing-prototypes
before any file names. This change makes pkg_add to process those
packages if @exec/@unexec commands don't contain any %[fFB]. Also
enable @exec/@unexec that have %D if the installation prefix is known to
pkg_add.
Reviewed by: jkh
and the kernel will have a 'config interface version number'. If an
incompatable change is made to the kernel that requires a rebuild of
config(8) (such as the cam devtab stuff), then the version number would be
bumped in both places. If a user neglects to rebuild config, then they
will get a nagging (but non-fatal) warning that they need to rebuild
config.
to find dependent packages on the local disk (i.e. package given as
filename, not URL)
- document $PKG_PATH
- use -v on pkg_add for dependent packages
Submitted by: hubertf@NetBSD.ORG
Obtained from: NetBSD
don't claim that _any_ serial speed is settable, mention that it has to
be supported by the device driver. Some have very flexible baud rate
selection (ie: based on divisors etc, such as the com ports), while others
have explicit baud rate choices.
Properlay clean the global RM variable if cgetstr() failed for it.
Otherwise, a connection attempt to a remote machine was made (and a
bogus result code printed) if a local printer followed a remote one in
printcap, and you did a `lpq -a', since checkremote() falsely assumed
the printer to be a remote one.
While i was at it, removed a gratuituous newline printed in front of
the remote machine's name, thus making the output more consistent (and
better machine-parseable) now.
