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@