Re: Proposal: getexecpath(3)

"Jean-Yves Migeon (NetBSD)" <[email protected]> Sun, 5 Jan 2025 03:28:34 +0100
Newsgroups gmane.os.netbsd.devel.userlevel
Organization NetBSD
Message-ID <[email protected]>
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)" <[email protected]>
>> 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/[email protected]/

-- 
jym@