Subject: Re: NAMECACHE_ENTER_REVERSE (Re: CVS commit: src/sys/kern)
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Christos Zoulas <christos@zoulas.com>
List: tech-kern
Date: 11/30/2006 10:41:30
On Nov 30, 11:08pm, yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
-- Subject: Re: NAMECACHE_ENTER_REVERSE (Re: CVS commit: src/sys/kern)

| > If I deal with the failure, I think that they will work.
| 
| then, the current implementation only sometimes works, right?

Let's be a bit more precise here. We know that gdb just needs to find
the executable from the pid in order to load symbols, and any instance
of the binary will do (i.e. any path to the executable will work). So
for that, even without going to the name cache we can get it to work
even making a symlink /proc/pid/exe -> /proc/pid/file. We want exe to
be a symlink because programs expect it to be. In the rdbms case (I am
just guessing here) they may need to get the path to the executable so
that they can find the installation location of the software. But this
might not be the case.

| > | > >something similar to what linux and dragonflybsd do.
| > | > 
| > | > I did not want to keep a full pathname buffer in struct proc. There
| > | > is also the issue of the binary being renamed/removed. I guess those
| > | > are corner cases that are not worth discussing though.
| > | 
| > | is it related to what i said?  i guess you replied to a wrong message.
| > 
| > I thought that Linux stores the pathname.
| 
| linux can construct the pathname from "dcache" entries.

Ah, ok.

christos