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 custom signals for sigaction #2319

Closed
AzariasB opened this issue Feb 21, 2024 · 3 comments · Fixed by #2326
Closed

Support custom signals for sigaction #2319

AzariasB opened this issue Feb 21, 2024 · 3 comments · Fixed by #2326

Comments

@AzariasB
Copy link

AzariasB commented Feb 21, 2024

sigaction currently only accepts the Signal enum and directly passes it to libc::sigaction as a c_int.

I'm working on a linux system that has custom signals superior to 32. And thus not declared in the Signal enum.

The idea would be to have another sigaction function that accepts directly a c_int.

Something like

pub unsafe fn sigaction_raw_signal(signal_raw: libc::c_int sigaction: &SigAction) -> Result<SigAction> {
    let mut oldact = mem::MaybeUninit::<libc::sigaction>::uninit();

    let res = libc::sigaction(signal_raw,
                              &sigaction.sigaction as *const libc::sigaction,
                              oldact.as_mut_ptr());

    Errno::result(res).map(|_| SigAction { sigaction: oldact.assume_init() })
}

It might be a bit out of scope for this library ... let me know!

I looked into implementing the function myself, but since Sigaction's fields are not public, I cannot have this function inside my own library. So another way would be to make sigaction public, but I feel like it's not ideal.

@SteveLauC
Copy link
Member

SteveLauC commented Feb 28, 2024

but since Sigaction's fields are not public, I cannot have this function inside my own library. So another way would be to make sigaction public, but I feel like it's not ideal.

This option isn't that bad, and I think this is something we should do, without this, Nix cannot be used under scenarios where interaction with raw libc types is necessary.

Actually, this has been done to a lot of Nix wrapper types, though the way they did this are not consistent, some types directly expose it, some types have functions like into_raw/from_raw, and some types did it through the From/Into traits...


cc @asomers, do you think we should make the way how our wrapper type interact with the libc types unified? In my mind, I think we should:

  1. Make the wrapper type #[repr(transparent)]
  2. Implement a standard way to convert it to/from the inner raw type

@asomers
Copy link
Member

asomers commented Feb 28, 2024

Yes, definitely @SteveLauC . That's a good idea.

@AzariasB
Copy link
Author

Thank you very much for your answers!
I'm not very familiar with nix's codebase, but if I can do anything to help, let me know!

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 a pull request may close this issue.

3 participants