libc: expose execvpe for Linux compat
ClosedPublic
Actions

Authored by brooks on Nov 29 2023, 11:39 PM.

Details

Reviewers

Commits

rG8ccd0b876e67: libc: expose execvpe for Linux compat

Summary

We already implemented execvpe internally with an _ prefix in libc so
go ahead and expose it for compatibility with Linux.

This reverts c605eea952146348e5e1ad5cab6c127d7a1bd164.

Bump __FreeBSD_version for the addition and add definitions to supress
compat shims in libzfs.

PR: 275370

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

brooks created this revision.Nov 29 2023, 11:39 PM

Herald added subscribers: asomers, delphij, imp. · View Herald TranscriptNov 29 2023, 11:39 PM

brooks requested review of this revision.Nov 29 2023, 11:39 PM

Harbormaster completed remote builds in B54702: Diff 130824.Nov 29 2023, 11:39 PM

Comments on c605eea952146348e5e1ad5cab6c127d7a1bd164 suggest this will need an exp-run.

I've submitted the OpenZFS bits upstream in https://github.com/openzfs/zfs/pull/15609

Yeah, definitely an exp-run for this one...

This revision is now accepted and ready to land.Nov 30 2023, 1:00 AM

actually export the symbol...
update doc date in manpage
ZFS changes were merged from upstream

This revision now requires review to proceed.Dec 8 2023, 11:46 PM

Harbormaster completed remote builds in B54878: Diff 131199.Dec 8 2023, 11:46 PM

Exp-run came back clean https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275370 so I've updated for a Monday commit.

This revision was not accepted when it landed; it landed in state Needs Review.Dec 11 2023, 7:28 PM

Closed by commit rG8ccd0b876e67: libc: expose execvpe for Linux compat (authored by brooks). · Explain Why

This revision was automatically updated to reflect the committed changes.

brooks added a commit: rG8ccd0b876e67: libc: expose execvpe for Linux compat.

On Discord a question has been asked related to if the modern execvpe no longer has the kind of issues that lead to: https://cgit.freebsd.org/src/commit/?id=c605eea952146348e5e1ad5cab6c127d7a1bd164 :

author		Ed Schouten <ed@FreeBSD.org>	2008-06-23 05:22:06 +0000
committer	Ed Schouten <ed@FreeBSD.org>	2008-06-23 05:22:06 +0000
. . .
Turn execvpe() into an internal libc routine.
Adding exevpe() has caused some ports to break. Even though execvpe() is
a useful routine, it does not conform to any standards.
. . .

In D42846#1034558, @markmi_dsl-only.net wrote:
On Discord a question has been asked related to if the modern execvpe no longer has the kind of issues that lead to: https://cgit.freebsd.org/src/commit/?id=c605eea952146348e5e1ad5cab6c127d7a1bd164 :
author		Ed Schouten <ed@FreeBSD.org>	2008-06-23 05:22:06 +0000
committer	Ed Schouten <ed@FreeBSD.org>	2008-06-23 05:22:06 +0000
. . .
Turn execvpe() into an internal libc routine.
Adding exevpe() has caused some ports to break. Even though execvpe() is
a useful routine, it does not conform to any standards.
. . .

We did a ports exp-run and fixed the fallout that was found. The main type of issue was blindly enabling a compatibility implementation of execvpe leading to declaration clashes. Did the poster find an issue or just wonder?

. . .
We did a ports exp-run and fixed the fallout that was found. The main type of issue was blindly enabling a compatibility implementation of execvpe leading to declaration clashes. Did the poster find an issue or just wonder?

I'll point them here. An issue might be build-time vs. operation/behavioral issues. The old c605eea95214 commit notes were not explicit what kind of mix of those might have been involved. But the wording "Even though execvpe() is a useful routine, it does not conform to any standards" suggested to me that operation/behavioral issues were likely involved, not just build issues.