On Sep 20,  2:10pm, matt@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: code to store the path of the executable in struct proc...

| What happens if you move the executable (or a parent directory of it)?
| (ignoring the fact if you use a remote file system, that could happen
| without you being able to compensate for it.)
|
| It probably makes more sense to store the file handle of the executable
| and the directory it's in instead of the path.

You lose. Consider the other case where you have multiple hard links
and you remove the one that you stored. For the purposes of AT_SUN_EXECPATH,
and $ORIGIN it is a non-issue because this gets evaluated during dynamic
linking for the purpose of establishing the directory where the executable
was started from. The other known cases on linux (java for example), use
it for the same reason; to establish the directory the binary was executed
from so that they can do ../lib to it and find the shared libraries they
want to load or their configuration files...

What I don't like in the code:
1. It is cpu inefficient; programs that fork and don't exec get penalized
   because they have to copy the string. I considered ref-counting the
   path, but that adds complexity.
2. It is storage inefficient; most path names are < 32 chars long and
   we store a whole MAXPATHLEN worth of string.
3. vnode_to_path() is a kludge. If we don't have the reverse namei cache
   it does not work, and it also does not work if the vnode is not in the
   cache anymore. Well, since we just namei()'d the vnode, this is not
   a problem in this case, but still. Sanctioning vnode_to_path() could
   be a good thing, specially because realpath() can be implemented directly
   in the kernel (or most of it).

christos