from Kentaro A. Kurahone, with minor adjustments by me.
the ack prediction part of the original patch was omitted because
it's a separate change. reviewed by Rui Paulo.
SPECIAL prog {objs,objpaths,keepsymbols} itemX
lines (where "prog" is fixed) in crunchgen configuration the same as
SPECIAL prog {objs,objpaths,keepsymbols} item1 ... itemN
OK by David Laight
Instead of polluting libkern.h with ifdefs introduce our own private
copy. Since AFAICT we only need it for libsa/ufs.c which only
includes it for the strlen() prototype, trim it to provide just that
for now.
We cannot just #include <string.h> (the WinCE one) here, as that pulls
in a lot of unrelated stuff, e.g. defines for limits that collide with
machine/limits.h
Remove the apparently always true "styp(nt) != SHORT" part of the
innermost test. Allow atomatic conversion of literals as long as
they fit into the target type.
This should fix some of the lint issues in proplib on some of our
platforms.
Approved by christos.
stack, cpu_info structure, panicstack, idle uarea and normal kernel
stack in here. the idle uarea and kernel stack are in the 2nd 64KB
page. the interrupt stack and cpu_info structure are as the same
place in the 1st 64KB page, and the panicstack grows down from the
top of this page. update comments in param.h to suit (XXX: a lot
of these constants should move to a header file that will not pollute
the name space so much.) map these pages identically between
cpu_initialise() and cpu_mp_startup(), and deal with the two 64KB
pages in pmap_extract(). keep an unmapped 64KB page between them.
don't initialise the unused "ci_eintstack" member of the cpu_info
structure
use constants to initialise many addresses in the cpu_info structure,
consolidating these assignments from cpu0 and cpu>0
delete u0/estack0/panicstack from locore.s
clean up some wrong comments in locore.s
fix a 32bit-only bug in cpu_mp_startup().
delete 'u0' entirely.
this fixes recent random lossage seen on port-sparc64: processes
stuck in RUN state, data faults, and hangs.
so that our kernels works with newer xen-3 hypervisors; and correct the value
of VIRT_BASE for dom0.
Now that we can embed the values of KERNBASE and KERNTEXTOFF in the binary
for Xen, make the domU memory layout the same as dom0 for Xen3 (making
it the other way round doens't work; probably because of alignement
constraints in the hypervisor). The old domU layout is used if options
XEN_COMPAT_030001 is present in the kernel config file. Enable this the
domU kernel config files for now, in case someone wants to run a NetBSD
domU on an older Xen3 installation.
tnozaki