tech-userlevel archive

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

Re: Proposal: getexecpath(3)



Le 04/01/2025 à 07:52, Taylor R Campbell a écrit :
Date: Wed, 18 Dec 2024 19:26:50 +0100
From: "Jean-Yves Migeon (NetBSD)" <jym%helkyn.org@localhost>
1 - As there is prior art elsewhere (getexecname(3)), unless there is a
specific (legal?) reason not to have the same name, I would reuse it (or
provide an alias) -- especially when obscure autotooling are looking for
such a function;

We could adopt the name `getexecname' from Sun.  The reason I didn't
do this is that Solaris (or at least, illumos) has somewhat quirky
semantics about partial normalization.  The semantics I'm suggesting
instead is extremely simple and reliably predictable: the path
argument to execve(2) is passed through verbatim.

On the other hand, we already implement AT_SUN_EXECNAME with different
semantics from Solaris (our own quirky partial normalization) -- but
then that's not really a public interface, so it's not as risky to
break the `new semantics, new name' rule.

I'm willing to adopt the Sun name if there's consensus on it -- I'm
just not convinced that Sun's partial normalization semantics is
reasonable, and I'm leery of breaking the `new semantics, new name'
rule for public-facing interfaces like this.

Understood; in that case forget about the suggestion.

Linux added AT_EXECFN in auxv, do you think that might be worth considering instead? [1]

(while still providing getexecpath for convenience)

Cheers,

[1] https://patchwork.kernel.org/project/qemu-devel/patch/20200221202857.126170-1-yuanzi%google.com@localhost/

--
jym@


Home | Main Index | Thread Index | Old Index