Moving vm_pmap in struct vmspace last
Marcel Moolenaar
xcllnt at mac.com
Wed Feb 27 20:39:13 UTC 2008
All,
On PowerPC we'll support Book E alongside the AIM processor
and there's one area where this results in an ABI problem:
For Book E the struct pmap is larger than for AIM. As such,
struct vmspace will have a different layout depending on
the configured CPU. This only affects libkvm, but is enough of a
hassle that I want to apply the following patch to address
that:
Index: sys/vm/vm_map.h
=
=
=
========================================================================
--- sys/vm/vm_map.h 2008/02/27 20:14:01 #56
+++ sys/vm/vm_map.h 2008/02/27 20:14:01
@@ -233,7 +233,6 @@
*/
struct vmspace {
struct vm_map vm_map; /* VM address map */
- struct pmap vm_pmap; /* private physical map */
struct shmmap_state *vm_shm; /* SYS5 shared memory private data XXX
*/
segsz_t vm_swrss; /* resident set size before last swap */
segsz_t vm_tsize; /* text size (pages) XXX */
@@ -243,6 +242,12 @@
caddr_t vm_daddr; /* (c) user virtual address of data */
caddr_t vm_maxsaddr; /* user VA at max stack growth */
int vm_refcnt; /* number of references */
+ /*
+ * Keep the PMAP last, so that per-CPU variations within a
+ * single architecture can be handled by the same toolchain
+ * without having to worry about the MI fields.
+ */
+ struct pmap vm_pmap; /* private physical map */
};
#ifdef _KERNEL
The consequence of this patch is that the ABI will be
broken for all arhcitectures (once). Again, this only
affects libkvm. Do people see a problem with this change?
Thanks,
--
Marcel Moolenaar
xcllnt at mac.com
More information about the freebsd-arch
mailing list