Subject: Re: Build failure for pmap(1)
To: None <email@example.com>
From: Hiroyuki Bessho <firstname.lastname@example.org>
Date: 09/14/2002 14:53:44
Robert Swindells <email@example.com> writes:
> Hiroyuki Bessho wrote:
>>"Chris Gilbert" <firstname.lastname@example.org> 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>
--- uvm.h 2001/09/15 20:36:44 1.31
+++ uvm.h 2002/09/13 12:07:38
@@ -64,6 +64,7 @@
* 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: