Skip to content

procctl for freebsd 15 upgrade. #4657

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

procctl for freebsd 15 upgrade. #4657

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions libc-test/build.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2743,6 +2743,17 @@ fn test_freebsd(target: &str) {
// Added in FreeBSD 14.2
"SO_SPLICE" if Some(14) > freebsd_ver => true,

// Added in FreeBSD 15
"PROC_LOGSIGEXIT_CTL"
| "PROC_LOGSIGEXIT_STATUS"
| "PROC_LOGSIGEXIT_CTL_NOFORCE"
| "PROC_LOGSIGEXIT_CTL_FORCE_ENABLE"
| "PROC_LOGSIGEXIT_CTL_FORCE_DISABLE"
if Some(15) > freebsd_ver =>
{
true
}
Comment on lines +2746 to +2755
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these added to FreeBSD < 15 in the first place? I think they could just live in src/unix/bsd/freebsdlike/freebsd/freebsd15

Copy link
Contributor Author

@devnexen devnexen Sep 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think what you refer to (ie freebsd < version >) is the place where data types change across releases.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure I understand - freebsd15/mod.rs also includes constants.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @asomers

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a function or constant changes between releases, then we need to put it in the appropriately versioned file. That's so users don't, for example, call the FreeBSD-11-compat version of fstatat with the FreeBSD 12+ struct stat. That would be bad. But if a function, struct, or constant newly appears in some new FreeBSD release, then it's fine to put it into the main freebsd/mod.rs file. If a user tries to use it while running a too-old version of FreeBSD, they'll simply get an ENOSYS error, which isn't too bad.


_ => false,
}
});
Expand Down
6 changes: 6 additions & 0 deletions libc-test/semver/freebsd.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1047,6 +1047,12 @@ POSIX_SPAWN_SETSCHEDULER
POSIX_SPAWN_SETSIGDEF
POSIX_SPAWN_SETSIGMASK
PPPDISC
PPROT_CLEAR
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the list of symbols you're adding here different than what you're adding in freebsd/mod.rs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also added forgotten ones.

PPROT_DESCEND
PPROT_FLAGS
PPROT_INHERIT
PPROT_OP
PPROT_SET
PROC_NO_NEW_PRIVS_CTL
PROC_NO_NEW_PRIVS_DISABLE
PROC_NO_NEW_PRIVS_ENABLE
Expand Down
13 changes: 13 additions & 0 deletions src/unix/bsd/freebsdlike/freebsd/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3011,6 +3011,11 @@ pub const PROC_NO_NEW_PRIVS_CTL: c_int = 19;
pub const PROC_NO_NEW_PRIVS_STATUS: c_int = 20;
pub const PROC_WXMAP_CTL: c_int = 21;
pub const PROC_WXMAP_STATUS: c_int = 22;
pub const PROC_LOGSIGEXIT_CTL: c_int = 23;
pub const PROC_LOGSIGEXIT_STATUS: c_int = 24;
pub const PROC_LOGSIGEXIT_CTL_NOFORCE: c_int = 1;
pub const PROC_LOGSIGEXIT_CTL_FORCE_ENABLE: c_int = 2;
pub const PROC_LOGSIGEXIT_CTL_FORCE_DISABLE: c_int = 3;
pub const PROC_PROCCTL_MD_MIN: c_int = 0x10000000;

pub const PPROT_SET: c_int = 1;
Expand Down Expand Up @@ -4809,6 +4814,14 @@ safe_f! {
pub {const} fn PR_SCTP_VALID_POLICY(x: c_int) -> bool {
PR_SCTP_POLICY(x) <= SCTP_PR_SCTP_MAX
}

pub {const} fn PPROT_OP(o: c_int) -> c_int {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally would prefer the PPROT changes in a separate commit (same PR is ok), so they can get a more focused commit message (perhaps with a reference link as well)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but ultimately I will have to squash it so..

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just fyi, >1 commit per PR is fine if they're meaningful (the merge strategy here is rebase). We just don't want the progress commits like "fix abc" "update" etc.

o & 0xf
}

pub {const} fn PPROT_FLAGS(o: c_int) -> c_int {
o & !0xf
}
}

cfg_if! {
Expand Down