tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: $ORIGIN (was: Re: make: ensure ${.MAKE} works)

On Apr 21,  3:41pm, (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?).


Home | Main Index | Thread Index | Old Index