sys/user.h is a stub that just #includes sys/pcb.h.
There are no 'struct pcb' anywhere in here, so I'm extremely doubtful
any of the builds will fail.
OTOH it might be relying on a header that pcb.h includes.
In any case i386 and amd64 build.
This value seems to never have been used anywhere.
This makes it consistent with it's cousin p_vm_msize (which is in pages as
well and has several uses).
- add kvm_i386pae.c (used for PAE memory translations), and update Makefile
for libkvm build.
- in pdppaddr: pass a flag to indicate PAE mode. Use a bit ignored
by the MMU. Mask address with PG_FRAME to avoid side effects.
Tested with vmstat(1)/netstat(1) to debug core files of PAE and !PAE
kernels. Older kernel dumps will default to native i386 (!PAE) mode.
XXX Currently, savecore(8) will fail to dump a PAE kernel in a !PAE
environment (and reciprocally). So you need to sync and reboot
with a kernel of the same mode as the one that crashed. Once the dump
is successful, this does not matter anymore.
-int _kvm_kvatop(kvm_t *, u_long, u_long *);
-off_t _kvm_pa2off(kvm_t *, u_long);
+int _kvm_kvatop(kvm_t *, vaddr_t, paddr_t *);
+off_t _kvm_pa2off(kvm_t *, paddr_t);
Basically, use vaddr_t for VA and paddr_t for PA. In addition, for variables
representing addresses, use paddr_t or vaddr_t, depending on the context.
For most arches, vaddr_t and paddr_t are equivalent to unsigned long. However,
the change was needed for exotic situations, like i386 PAE, were unsigned long
is not suitable for PA which are 64 bits long. As this required a complete
change of the function prototypes, all arches had to be adapted accordingly.
Core files from before this commit should still work with the new code; I did
not see any direct dependency between core's structure and kvatop/pa2off.
The change was compile tested for all arches, as it impacts all of them.
See also:
http://mail-index.netbsd.org/current-users/2010/09/07/msg014249.html
- 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>.
provided, kvm_open() and kvm_openfiles() will try _PATH_KSYMS first,
then either the path from sysctl machdep.booted_kernel (if that's
available) or _PATH_UNIX (if the sysctl is not available).
so that it is used both for the /dev/mem case and the core dump case.
Output from savecore(8) before:
savecore - - - (null): kvm_openfiles: /netbsd: No such file or directory
and after:
savecore - - - no core dump
address space available to processes. this limit exists in most other
modern unix variants, and like most of them, our defaults are unlimited.
remove the old mmap / rlimit.datasize hack.
- adds the VMCMD_STACK flag to all the stack-creation vmcmd callers.
it is currently unused, but was added a few years ago.
- add a pair of new process size values to kinfo_proc2{}. one is the
total size of the process memory map, and the other is the total size
adjusted for unused stack space (since most processes have a lot of
this...)
- patch sh, and csh to notice RLIMIT_AS. (in some cases, the alias
RLIMIT_VMEM was already present and used if availble.)
- patch ps, top and systat to notice the new k_vm_vsize member of
kinfo_proc2{}.
- update irix, svr4, svr4_32, linux and osf1 emulations to support
this information. (freebsd could be done, but that it's best left
as part of the full-update of compat/freebsd.)
this addresses PR 7897. it also gives correct memory usage values,
which have never been entirely correct (since mmap), and have been
very incorrect since jemalloc() was enabled.
tested on i386 and sparc64, build tested on several other platforms.
thanks to many folks for feedback and testing but most espcially
chuq and yamt for critical suggestions that lead to this patch not
having a special ugliness i wasn't happy with anyway :-)
matt