Robert Swindells <rjs@fdy2.demon.co.uk> writes:

> Hiroyuki Bessho wrote:
>>"Chris Gilbert" <chris@dokein.co.uk> 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
>>me.
>
> 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;
 };
+#endif
 
 /*
  * vm_map_entry etype bits:


--
bsh.