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