is to provide routines that do as KASSERT(9) says: append a message
to the panic format string when the assertion triggers, with optional
arguments.
Fix call sites to reflect the new definition.
Discussed on tech-kern@. See
http://mail-index.netbsd.org/tech-kern/2011/09/07/msg011427.html
when building a MODULAR kernel or compiling _MODULE.
It should be noted that MODULAR or _MODULE export a view of the kernel
as being MULTIPROCESSOR (even if isn't).
The shared pmap TLB uses mdpg in places where it used mdpg to avoid
deadly embrance inclusion problems.
Add fast softint support for PowerPC (though only booke uses it).
Redo FPU/VEC support and add e500 SPE support.
Rework trap/intrs to use a common trapframe format.
Support SOFTFLOAT (no hardfloat or fpu emulation) for BookE.
it's used only by pmap. vmparam.h has definitions for wider
audience.
All GENERIC kernels build tested, except ia64.
powerpc/include/booke/vmparam.h has one too, but it has no pmap.h,
so it's left as is.
- Addresses the issue described in PR/38828.
- Some simplification in threading and sleepq subsystems.
- Eliminates pmap_collect() and, as a side note, allows pmap optimisations.
- Eliminates XS_CTL_DATA_ONSTACK in scsipi code.
- Avoids few scans on LWP list and thus potentially long holds of proc_lock.
- Cuts ~1.5k lines of code. Reduces amd64 kernel size by ~4k.
- Removes __SWAP_BROKEN cases.
Tested on x86, mips, acorn32 (thanks <mpumford>) and partly tested on
acorn26 (thanks to <bjh21>).
Discussed on <tech-kern>, reviewed by <ad>.
which is now the "API" provided by the pmap module. pmap_kernel()
remains as the syntactic sugar.
Bonus cosmetics round: move all the pmap_t pointer typedefs into
uvm_pmap.h.
Thanks to Greg Oster for providing cpu muscle for doing test builds.
deal with the 64bit bridge mode. pmap changes by Matt Thomas, rest by myself.
Change pmap.c to work similar to exec_elf.c to allow us to compile in
multiple pmaps to a single kernel. This allows the pmap for bridge64 to
co-exist with the 32bit pmap.
Yank __HAVE_PMAP_PHYSSEG from all the oea code.
Add a new global, "oeacpufeat", which is used early in locore to determine
certain cpu features. This allows us to conditionalize code early in the boot
for certain CPUs that have special needs.
Yank most of the ifdef PPC_OEA_BRIDGE64 code from almost every file it was
found in. Some of it seemed incorrect, and my 7044 booted just fine
without it. It would appear that the bridge cpus treat BAT instructions
as nops, so they seem to be safe.
In ofppc, check the oeacpufeat, and if we are on a 64bit proc, clear
MSR[SF], and ASR[V].
With all of these changes, a kernel with both PPC_OEA and PPC_OEA_BRIDGE64
will boot on the POWERIII-2 cpu. However, it will not yet boot on a 32bit
cpu, because of CACHELINESIZE. Work remains to be done there to fix that.
