Subject: Re: second pass at the "store the path of the executable in struct proc" patch
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Christos Zoulas <email@example.com>
Date: 10/01/2007 10:22:55
On Oct 1, 9:13pm, firstname.lastname@example.org (YAMAMOTO Takashi) wrote:
-- Subject: Re: second pass at the "store the path of the executable in struc
| > That is a good point, I just kept it because people requested it in the
| > past. I can keep it in the exec package for this particular use. I don't
| > mind getting rid of it. Then the pathref code can go too.
| who requested it, for what?
| does their purpose really need p_pathref,
| or can it be just served by name cache improvements as well?
I don't recall exactly. It was part of the discussion: Filesystems have no
business of calling getcwd_common() because the locking situation is hairy.
Better to store the pathname in struct proc and retrieve it from there.
I think that cache improvements can help that too.
| > | > It is good enough for the uses procfs programs nee (finding ../lib and
| > | > opening shared libraries), and you can never win with rename and unlink.
| > |
| > | never win? you can point the new path after rename.
| > | iirc, it's what you want to follow here. ie. what linux does.
| > Does linux really update it after a rename?
| > What happens if you delete it?
| "foobar (deleted)".
| > What happens if a process chroots?
| i don't know.
All of that can be handled by the reverse-namei cache.
| > | p_pathref seems completely different thing from namei improvements to me.
| > I meant that the cache improvements will make sure that the name is always
| > found.
| > christos
| i agree that improving name cache is the right way to implement
| these functionalities.
Ok, I will kill the pathref stuff then, and just use exec_package to
temporarily store AT_SUN_EXECNAME.