On Apr 21, 3:41pm, [email protected] (David Holland) wrote: -- Subject: Re: $ORIGIN (was: Re: make: ensure ${.MAKE} works)
| 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. That's right, and it affects in my opinion < 5% of the invocations, since the majority of the execs are done via the shell and the shells pass absolute paths to exec for commands that don't contain '/'. | 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. That's what vnode_to_path() does (it calls getcwd), so the cost is the same. I think what you propose is to call something like a kernel realpath(path) and use this to set $ORIGIN which is fine with me. I did not do it because I did not want to deal with path canonicalization (eliminating ../.././// from the path, but I guess that getcwd() does this for you if you call it with the full path?). christos
