Skip to content
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.

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

Support AIX signal handler types #136

Merged
merged 2 commits into from Feb 11, 2023
Merged

Support AIX signal handler types #136

merged 2 commits into from Feb 11, 2023

Conversation

ecnelises
Copy link
Contributor

The main differences for AIX:

Note that AIX hasn't been an official Tier-3 Rust target. (rust-lang/compiler-team#553)

Copy link
Owner

@vorner vorner left a comment

Choose a reason for hiding this comment

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

Hello

There are some style issues that would be nice to get addressed. Nevertheless, there's this bigger concern I have.

You mention that AIX is not yet a tier-3 Rust target. When trying to look at the libc crate, it doesn't seem to offer any aix target officially and grepping it for the word aix yields nothing, so is it even supported by libc? Or is it some kind of unofficial fork of the libc crate?

So I'd like to know how stable that target is, if it's likely to change (like, if the libc crate might paper-over the differences in the names, for example, in the future, which would break the currently proposed code). If it's not going to change, having it included in the CI in some way would be nice, because I have no other way to tell if it has any chance to work or if some future changes would break it.

#[cfg(target_os = "aix")]
let set_handler =
|action: &mut libc::sigaction, handler| action.sa_union.__su_sigaction = handler;
set_handler(&mut new, handler);
Copy link
Owner

Choose a reason for hiding this comment

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

Why in this super-complicated way and not just having conditionally-compiled blocks?

@@ -141,6 +141,9 @@ pub(crate) fn wake(pipe: RawFd, method: WakeMethod) {
let data = b"X" as *const _ as *const _;
match method {
WakeMethod::Write => libc::write(pipe, data, 1),
#[cfg(target_os = "aix")]
WakeMethod::Send => libc::send(pipe, data, 1, libc::MSG_NONBLOCK),
#[cfg(not(target_os = "aix"))]
Copy link
Owner

Choose a reason for hiding this comment

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

I would prefer the same nowait_flag trick here too, to avoid two „same“ calls to duplicate in the code.

let res = unsafe { libc::send(pipe, &[] as *const _, 0, libc::MSG_DONTWAIT) };
#[cfg(target_os = "aix")]
let res = unsafe { libc::send(pipe, &[] as *const _, 0, libc::MSG_NONBLOCK) };
Copy link
Owner

Choose a reason for hiding this comment

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

The same as above.

usize,
extern "C" fn(libc::c_int, *mut libc::siginfo_t, *mut libc::c_void),
>(sigaction)
};
Copy link
Owner

Choose a reason for hiding this comment

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

Doesn't the same sigaction as _ work, only assigning it to a different field?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Seems direct casting from usize to extern fn is not allowed:

error[E0605]: non-primitive cast: `usize` as `extern "C" fn(i32, *mut siginfo_t, *mut c_void)`
   --> src/low_level/signal_details.rs:120:46
    |
120 |             action.sa_union.__su_sigaction = libc::SIG_DFL as _;
    |                                              ^^^^^^^^^^^^^^^^^^ invalid cast

@ecnelises
Copy link
Contributor Author

You mention that AIX is not yet a tier-3 Rust target. When trying to look at the libc crate, it doesn't seem to offer any aix target officially and grepping it for the word aix yields nothing, so is it even supported by libc? Or is it some kind of unofficial fork of the libc crate?

So I'd like to know how stable that target is, if it's likely to change (like, if the libc crate might paper-over the differences in the names, for example, in the future, which would break the currently proposed code). If it's not going to change, having it included in the CI in some way would be nice, because I have no other way to tell if it has any chance to work or if some future changes would break it.

AIX has not been an official Rust target yet. We have a proposal here rust-lang/compiler-team#553 and multiple patches like rust-lang/libc#2894. So this PR might need to be in draft status.

As for CI, we also plan to gradually set up CI for Rust toolchain after AIX target got accepted, but since it seems no public CI system supports AIX, we need to figure out how to support CI of these critical crates (also FYI @bzEq). Is that the necessity for now?

@vorner
Copy link
Owner

vorner commented Oct 21, 2022

As for CI, we also plan to gradually set up CI for Rust toolchain after AIX target got accepted, but since it seems no public CI system supports AIX, we need to figure out how to support CI of these critical crates (also FYI @bzEq). Is that the necessity for now?

Not necessarily. Considering the state of the proposal, etc, I'd be OK merging it with the knowledge this is an experimental target, not guaranteed to work or compile despite the crate being past 1.0. That is, I'm OK accepting it and even publishing a new version if it helps you, but until there's some CI and such, I can't promise not to accidentally break it in some future version 🤷. If that's fine for you, we can go forward with this.

@ecnelises
Copy link
Contributor Author

Not necessarily. Considering the state of the proposal, etc, I'd be OK merging it with the knowledge this is an experimental target, not guaranteed to work or compile despite the crate being past 1.0. That is, I'm OK accepting it and even publishing a new version if it helps you, but until there's some CI and such, I can't promise not to accidentally break it in some future version 🤷. If that's fine for you, we can go forward with this.

Thanks. Now powerpc64-ibm-aix has been accepted as Tier-3 target. I'm okay with potential build break from future change due to lack of CI.

@vorner vorner merged commit 1b8cafa into vorner:master Feb 11, 2023
@vorner
Copy link
Owner

vorner commented Feb 11, 2023

Thank you, released…

@ecnelises
Copy link
Contributor Author

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants