Provide the same sched.h constants for musl as gnu#3534
Provide the same sched.h constants for musl as gnu#3534alyssais wants to merge 1 commit intorust-lang:mainfrom
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) soon. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
|
@bors r+ |
Provide the same sched.h constants for musl as gnu I don't understand why these constants from Linux headers aren't just defined in linux_like/mod.rs. Surely they'd be the same for every libc?
|
💔 Test failed - checks-actions |
|
CI fails: https://github.com/rust-lang/libc/actions/runs/7487138095/job/20379076829 |
|
@alyssais are you able to update this to get it over the line? If you need help figuring out the CI, let me know. |
|
@alyssais ping, are you able to update this? |
tgross35
added
the
stable-nominated
tgross35
force-pushed
the
musl-sched
branch
2 times, most recently
from
0e177e5 to
1adff9a
Compare
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
tgross35
force-pushed
the
musl-sched
branch
2 times, most recently
from
f2838cc to
4286e0e
Compare
| pub const CLONE_NEWTIME: c_int = 0x80; | ||
| pub const CLONE_CLEAR_SIGHAND: c_ulonglong = 0x100000000; | ||
| pub const CLONE_INTO_CGROUP: c_ulonglong = 0x200000000; | ||
|
|
There was a problem hiding this comment.
Actually CLONE_NEWTIME is defined at https://github.com/kraj/musl/blob/1b06420abdf46f7d06ab4067e7c51b8b63731852/include/sched.h#L52, but CLONE_CLEAR_SIGHAND and CLONE_INTO_CGROUP do not seem to be defined in Musl
There was a problem hiding this comment.
That's true, but given the values are passed straight to the kernel anyway, does it matter?
There was a problem hiding this comment.
We shouldn't really be peeking into what the libcs do with constants, i.e. whether the values go right to the kernel or if they get intercepted. Also it is a CI failure.
There was a problem hiding this comment.
As far as I can tell Glibc doesn't define CLONE_CLEAR_SIGHAND in a public header either — only the linux/sched.h kernel header and the internal linux/clone3.h header do. What's the difference?
There was a problem hiding this comment.
I believe glibc actually reexports the kernel headers directly, while musl redefines a specific subset that is more cross-platform compatible. Does that seem to match up?
There was a problem hiding this comment.
On Alpine at least, musl doesn't install any headers under linux/ — you're expected to separately install the kernel headers. So it's really just a packaging difference, as I understand it. The API is the same.
There was a problem hiding this comment.
@tgross35 so what do we do here? I'm noticing a lot of other constants that are also defined in kernel headers yet only available for Glibc in libc. It would be good to have a path forward for these.
There was a problem hiding this comment.
I think this is okay since we are already including linux/sched.h in tests. In general we are trying to move away from providing linux/ exports and instead suggesting https://docs.rs/linux-raw-sys/latest/linux_raw_sys/, but if this is expected to work well on musl, I don't think there is too much harm in smoothing the API across platforms a bit.
Could you rebase?
|
@rustbot author |
|
Reminder, once the PR becomes ready for a review, use |
|
Oh, looks like this has already been done in 3ba96df without me noticing :) |
|
Well sorry about that, I didn't realize there was overlap. That PR can't actually be backported due to the type changes there. So if you are interested, feel free to prepare a version of what you have here that targets the |
tgross35
removed
the
stable-nominated
5 participants
I don't understand why these constants from Linux headers aren't just defined in linux_like/mod.rs. Surely they'd be the same for every libc?