maps standard boot flags to corresponding RB_* values
use BOOT_FLAG() in port's MD code as appropriate
as discussed on tech-kern, add new boot flags -v, -q for booting
verbosely or quietly, and corresponding AB_VERBOSE/AB_QUIET
boot flags; also add FreeBSD-compatible bootverbose macro and
NetBSD-specific bootquiet macro
for hpcmips, use new bootverbose instead of it's own hpcmips_verbose
Tested on i386, and to limited extend (compile of affected files) also for
mvme68k, hp300, luna68k, sun3.
* All of pmap_init is now deferred to the first call of pmap_create. This
allows us to allocate stuff dynamically using malloc.
* pv_table (which is needed before malloc is available) is temporarily
allocated using pmap_steal_memory in pmap_bootstrap, and then
re-allocated using malloc in pmap_create, with the old allocation being
given back to UVM. This should save some memory on small machines, but
the malloc overhead probably soaks it up.
the fmovecr constant table has the internal format
of the constants. So, when changing the mantissa size by a
non-multiple of 32 bits, we'd have to change this table, too. As
all other code changes just chopped of the least significand
32bit word of the mantissa, we correct the mantissa size instead
to (115 - 32 == 83) bits.
fpu_fmovecr.c:
put a safety belt in, to catch the next person who doesn't know this.
fpu_int.c:
in one place, the reduction of the mantissa size was overlooked.
fpu_log.c:
as the most significand 32bit word of the mantissa was changed back to the
old format, change back the table indexing code, too.
This should fix PR 11045.
indeed tagged with ASM and the ASN, "per the Alpha architecture".
It is therefore safe to cancel any pending lazy I-sync on a
given CPU when a new ASN is assigned on that CPU.
that the page being zero'd was not completed and that page zeroing
should be aborted. This may be used by machine-dependent code doing
slow page access to reduce the latency of running a process that has
become runnable while in the middle of doing a slow page zero.
backend.
The VME2chip can use this to translate a VMEbus irq to a cpu irq.
The VMEchip (on mvme147) can't deal with the VMEbus irq and cpu irq
being different so we just panic in that case for now.
sato