On Fri, Jun 03, 2011 at 03:27:37PM +0200, David Coppa wrote:
> On Thu, Jun 2, 2011 at 7:14 PM, Antoine Jacoutot <ajacou...@bsdfrog.org>
> wrote:
>
> > I guess you are not current enough to build lsof.
>
> >> dproc.c: In function 'process_text':
> >> dproc.c:539: error: 'struct vm_map' has no member named 'nentries'
> >> dproc.c:545: error: 'struct vm_map' has no member named 'header'
> >> dproc.c:547: error: 'struct vm_map_entry' has no member named 'next'
> >> *** Error code 1
>
> I'm current (done a "make build" this morning) and I confirm lsof is
> broken due to vmmap.
>
> Ariane, please, can you help shedding some light?
This is the same as procmap (from base) and libgtop (from ports) do.
They traversed the map using a linked list (in the old allocator this
list existed). The new allocator only has a tree.
The easiest way to traverse a map from userspace is to recreate the tree
in userspace, then use RB_FOREACH to traverse it. This is what is done
to make libgtop2 work properly.
See /usr/ports/devel/libgtop2/files/procmap.c for sample code; the
load_vmmap_entries and unload_vmmap_entries code can be copied verbatim
and adapted to lsofs idea of kvm_read.
RB_INIT(&root);
nentries = load_vmmap_entries(server,
(unsigned long) RB_ROOT(&vmspace.vm_map.addr),
&RB_ROOT(&root), NULL);
if (nentries == -1) {
unload_vmmap_entries(RB_ROOT(&root));
glibtop_error_io_r (server, "kvm_read (entry)");
}
RB_FOREACH(entry, uvm_map_addr, &root) {
/*
* funky code goes here
*/
}
unload_vmmap_entries(RB_ROOT(&root));
The load_vmmap_entries function performs copy from kernel to userland.
The unload_vmmap_entries is a recursive free() (and must be called if
the copy fails).
--
Ariane
