2017-08-29 05:35:09 UTC
PID's scheduler category (by default making it a realtime process), but
the musl-libc maintainer decided he didn't like that system call and
changed the wrapper to return -ENOSYS instead of making the system call:
Unfortunately musl-libc has a policy that musl is never wrong and thus
it doesn't provide a #define __MUSL__ that you can test against to work
around this kind of breakage, the way every other libc does.
I did a quick stab at replacing sched_setscheduler() with a wrapper that
calls syscall(NR_sched_setscheduler) but that musl commit broke _all_
the sched functions, sched_get_priority_max() and so on. I'd have to
wrap all of them, even on systems that provide non-broken wrappers for
the Linux syscall.
This is why we have the TOYBOX_MUSL_NOMMU_IS_BROKEN config symbol, for a
similar case where for 20 years nommu linux let you tell if you were
building for a system with mmu or without it by a simple compile time
probe: build a hello world that links against fork(); if it's not there
it's a nommu system. Rich decided he didn't like that, and provided a
broken fork() (always returns -ENOSYS) for nommu systems so you can't
tell at compile time whether it's mmu or not.
I'm trying to figure out if I should just leave chrt broken on musl and
add a FAQ entry about it. If there was an #ifdef __MUSL__ I'd have the
build produce a warning and the runtime produce a message, but of course