Subject: Re: Build failure for pmap(1)
To: None <>
From: Hiroyuki Bessho <>
List: port-arm
Date: 09/14/2002 14:53:44
Robert Swindells <> writes:

> Hiroyuki Bessho wrote:
>>"Chris Gilbert" <> writes:
>>> I stumbled on this a while back with lsof I think.  I think it's tied
>>> closely enough to the kernel that it could define _KERNEL (I should really
>>> have a look at what it does at some point)
>>    Why do we need to protect things with #ifdef _KERNEL in
>><machine/vmparam.h>?  Other ports doesn't have such protection.
>>    Usual userland programs don't include vmparam.h.  So, just
>>removing #ifdef _KERNEL from <machine/vmparam.h> seems a good fix to
> The bit I can't work out is whether the pmap program uses anything
> from struct uvm.
> The size of this structure can be different between ports that share
> the same MACHINE_ARCH if VM_NFREELIST differs.

...ok, It was not a good idea to remove #ifdef _KERNEL in vmparam.h.
We'd better to keep VM_NFREELIST behind _KERNEL curtain.

   pmap(1) doesn't really require VM_NFREELIST or struct uvm. It just
uses things from <uvm/uvm_object.h> and <uvm/uvm_device.h>, and some
constants defined in <uvm/uvm.h>.  How about a patch to <uvm/uvm.h>
like following:

--- uvm.h	2001/09/15 20:36:44	1.31
+++ uvm.h	2002/09/13 12:07:38
@@ -64,6 +64,7 @@
 #include <uvm/uvm_pdaemon.h>
 #include <uvm/uvm_swap.h>
+#ifdef _KERNEL
  * pull in VM_NFREELIST
@@ -121,6 +122,7 @@
 	/* kernel object: to support anonymous pageable kernel memory */
 	struct uvm_object *kernel_object;
  * vm_map_entry etype bits: