> Date: Sun, 25 Oct 2026 04:20:57 -0400 > From: Brad Smith <[email protected]> > > So the name is the same, but both the signature and the semantics > differ from what is proposed here: a canonical absolute path rather > than the verbatim execve(2) argument. If NetBSD goes ahead with > this, it would be good to either match OpenBSD's interface or pick a > different name.
Why do you want the kernel to compute some notion of a canonical absolute path? Of what use is this for applications? Isn't this strictly less useful than the original verbatim exec path? You can always pass the original verbatim exec path to realpath(3) if you want to canonicalize it, but you can't undo realpath(3) (or the kernel's equivalent) if the program wants to use the same symlinks for to (dl)open supporting data and libraries as the caller used to execute the program. I think it is a mistake for the kernel to expose anything other than the original verbatim exec path. (I don't have strong feelings about char *getexecpath(void) vs void getexecpath(char *, size_t); the first one is a little simpler, but whatever.) > Portable software is already starting to probe for getexecpath() > (HAVE_GETEXECPATH checks in configure/meson/CMake), and two > incompatible functions under the same name would be an unpleasant > trap. Sounds like the `portable' software needs #ifdef __OpenBSD__, since API this isn't portable to any platform except OpenBSD anyway?
