included. This is done by tracking the current directory for the
file being parsed, and constructing a path relative to that directory
when an include directive's file name begins with "./".
a simple print statement showing the build directory location after
running config and creating a usage() function instead of using the
goto usage statement. Approved by christos@ and thanks to Tor for
the suggestions and patch.
the kernel is missing the newline at the end of the file, the string
doesn't get closed properly, resulting in a message from the compiler
about a missing #endif. It's somewhat misleading, so config will now
point it out and compensate for the missing newline.
Addresses PR kern/21920: including kernel config fails in some cases.
with either "options INCLUDE_CONFIG_FILE" or "options INCLUDE_JUST_CONFIG".
The program can now be invoked like:
- config -b objdir -s srcdir /netbsd
This will use configuration data from /netbsd to automatically create the
build directory of the new kernel.
- config -x /netbsd > CONFFILE
This will store configuration data from /netbsd in the CONFFILE file for
further editing.
such pseudo-devices, create cfdrivers for them which carry the appropriate
attributes. This allows devices in the config file to be attached to
pseudo-devices.
for config_time.h) that contains, for example:
/* Sun Nov 17 05:37:51 2002 GMT */
#define CONFIG_TIME 1037511471
#define CONFIG_YEAR 2002
#define CONFIG_MONTH 11
#define CONFIG_DATE 17
#define CONFIG_HOUR 5
#define CONFIG_MINS 37
#define CONFIG_SECS 51
These values represent the current time as of when config was last
run, so that functions (eg, inittodr()) can use these values instead
of being updated once every year or so with the "current" time.
The associated modification to Makefile.kern.inc makes config_time.h
depend on this depend on this and the kernel Makefile, so that
granularity of kernel builds is not reduced.
means that the appropriate combination of checking for KERNEL_BUILD,
RELEASEDIR, DESTDIR, and/or BSD_PKG_MK, can allow the setting of COPTS
or CFLAGS (or anything else) depending on the specific task at hand.
Personally, I think that per-kernel install rules are the best part.
party software packages to the kernel. The statment:
package "../path/to/some/directory/files.package"
is equivalent to the sequence:
prefix "../path/to/some/directory"
include "files.package"
prefix
allowing for the following:
file foo.c foobar | bar
defflag BAR
device foobar
...to be expressed in the following (more natural) way:
define foo
file foo.c foo
defflag BAR: foo
device foobar: foo
allows for the following:
define foo
define bar { }: foo
device foobar: bar
An instance of "foobar" will select "bar", which will in turn select
"foo" due to "bar"'s dependency on "foo".
Circular dependencies are not allowed, and a dependency may also not
be an interface attribute.
now carries the name of the attachment (e.g. "tlp_pci" or "audio"),
and cfattach structures are registered at boot time on a per-driver
basis. The cfdriver and cfattach pointers are cached in the device
structure when attached.
a vector of indices into the cfdata table to specify potential parents,
record the interface attributes that devices have and add a new "parent
spec" structure which lists the iattr, as well as optionally listing
specific parent device instances.
See:
http://mail-index.netbsd.org/tech-kern/2002/09/25/0014.html
...for a detailed description.
While here, const poison some things, as suggested by Matt Thomas.
itojun