On Wed, Apr 21, 2010 at 08:58:31AM -0400, Christos Zoulas wrote: > | Is it reasonable to just do that? I don't think calling getcwd() from > | exec is going to cause locking problems, but it might be more overhead > | than we want to swallow. > > The code that we have there works fine now, yamt objected about it because > strictly speaking the path could have been evicted from the namei() cache, > but this never happens since the call is immediately after. Calling getcwd > will add overhead and it is not really necessary because we already did > resolve the path.
If you exec "../bin/foo", that's all namei will resolve or touch, and that's the string that'll come back from namei. If we want an absolute path out, it needs getcwd, either in exec or in namei... and in exec is probably preferable. If we really want to support the feature we need to either buy into that overhead, or inspect the binary in some fashion to only do it in cases where it's going to be used. AFAICT getcwd should be no more expensive than vnode_to_path if the parentage of the current directory is in the name cache, which should be the common case. -- David A. Holland dholl...@netbsd.org