> On Oct 1, 10:57am, yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> -- Subject: Re: second pass at the "store the path of the executable in struc
> 
> | > This is only true for executables that are in the path and the shell
> | > constructs the path for you. Not true ./foo, ../foo, or foo where .
> | > is in the path and foo is an executable in the current working directory.
> | > Or if you execv("foo", ..); 
> | 
> | my point is, for this purpose, it isn't necessary to keep it in proc.
> 
> 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?

> | > 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?

yes.

> What happens if you delete it?

"foobar (deleted)".

> What happens if a process chroots?

i don't know.

> | 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.

YAMAMOTO Takashi