Subject: Re: PT_MEMMAP
To: Gregory McGarry <g.mcgarry@ieee.org>
From: Love <lha@stacken.kth.se>
List: tech-kern
Date: 07/31/2002 19:21:46
Gregory McGarry <g.mcgarry@ieee.org> writes:

> > : lha@nutcracker ; ./pmap 303
> > start: 08048000 end: 0804c000   r-x rwx COW  NC   obj 0 1 0     /usr/bin/od
> > start: 0804c000 end: 0804d000   rw- rwx COW  NNC  anon 0 1 0
> > start: 0804d000 end: 0805f000   rwx rwx COW  NNC  anon 0 1 0
[...]
> 
> I like it!
> 
> > http://www.e.kth.se/~lha/patches/netbsd/gdb-core/ptrace-patch2
> 
> Check out ktrsyscall()/ktrwrite() for a clean way to do the uiomove
> stuff.

You mean by a header or something else ? I have to use two uiomove's since
as far I know there there isn't a uiomove-version that takes two uio's as
argument.
 
> I'm not sure whether the use of getcwd_common() isn't a horrible hack.
> It doesn't seem like the right thing to do.

I don't really feel responsible that proc_vnode_to_path() does to get the
results. I think that getcwd_common() is somewhat missname (although I
can't find another better name for it). 

Still, pmap wont be that useful info if NAMECACHE_ENTER_REVERSE isn't
turned on. Should it be ? If it isn't I think that the interface should
include the dev_t and inode number of the file and let the user find the
info with find(1).

Love