the environment:
CPUFLAGS Additional flags to the compiler/assembler to select
CPU instruction set options, CPU tuning options, etc.
Since CPUFLAGS is not implicitly set by any part of the make infrastructure,
it is safe to set in mk.conf, unlike COPTS or DBG.
educate, elucidate, and otherwise answer ancient PR 5885, which
complained about lack of documentation for DHCP booting systems.
Please review, comment & correct. Writing is hard work.
* Unnecessarily causes lib/librpcsvc (etc) to be rebuilt every time
rpcgen is updated.
* No other "generated" file (.l, .y, ...) depends upon its tool
like this
* As <bsd.own.mk> wasn't being pulled in, the tools/ version
wasn't being used, so a lot of times the dependency was wrong.
Fixes [toolchain/11568] by Bernd Ernesti.
Note: this is the first tool using a "TOOL_" prefix in the make(1) variable;
other similar "non-standard" variable names will be converted in the future.
message buffer has not yet been set up, mimicking code from the top of
the sysctl routine for retrieving the message buffer.
(2) Add a /l modifier to the trace command. This makes it print the
backtrace using printf() instead of db_printf(), which has the nice
side-effect of also putting it into the message buffer. A kernel with
ddb in it but disabled (ie, ddb.onpanic set to zero) will print a
backtrace (which ends up in the message buffer) before dumping (or
not, depending on the value of kern.dump_on_panic) and rebooting, but
if ddb is not disabled, the backtrace is not printed, and there's no
way to get it to display a backtrace such that you can retrieve it
after the dump. The backtrace printed by gdb is sometimes a little
different.
(3) Documentation for the above.
http://mail-index.netbsd.org/source-changes/2003/05/08/0068.html
There were some side-effects that I didn't anticipate, and fixing them
is proving to be more difficult than I thought, do just eject for now.
Maybe one day we can look at this again.
Fixes PR kern/21517.
space is advertised to UVM by making virtual_avail and virtual_end
first-class exported variables by UVM. Machine-dependent code is
responsible for initializing them before main() is called. Anything
that steals KVA must adjust these variables accordingly.
This reduces the number of instances of this info from 3 to 1, and
Simplify the way the bounds of the managed kernel virtual address
space is advertised to UVM by making virtual_avail and virtual_end
first-class exported variables by UVM. Machine-dependent code is
responsible for initializing them before main() is called. Anything
that steals KVA must adjust these variables accordingly.
This reduces the number of instances of this info from 3 to 1, and
simplifies the pmap(9) interface by removing the pmap_virtual_space()
function call, and removing two arguments from pmap_steal_memory().
Simplify the way the bounds of the managed kernel virtual address
space is advertised to UVM by making virtual_avail and virtual_end
first-class exported variables by UVM. Machine-dependent code is
responsible for initializing them before main() is called. Anything
that steals KVA must adjust these variables accordingly.
This reduces the number of instances of this info from 3 to 1, and
simplifies the pmap(9) interface by removing the pmap_virtual_space()
function call, and removing two arguments from pmap_steal_memory().
This also eliminates some kludges such as having to burn kernel_map
entries on space used by the kernel and stolen KVA.
This also eliminates use of VM_{MIN,MAX}_KERNEL_ADDRESS from MI code,
this giving MD code greater flexibility over the bounds of the managed
kernel virtual address space if a given port's specific platforms can
vary in this regard (this is especially true of the evb* ports).
