[Toybox] musl intentionally broke chrt

[Rob Landley]

On 08/30/2017 04:39 AM, Andre Renaud wrote:
> Hi Rob,
> Can you not call "pthread_setschedparam" using on pthread_self instead
> of calling sched_setscheduler?

The same commit broke a half-dozen related system calls, so I'd still
need to wrap sched_get_priority_max() and similar myself. (Not just -m.
The kernel barfs if you feed it an illegal value but I need range
checking to provide a reasonable error message saying what _would_ be
allowed...)

But a bigger reason is toybox doesn't currently use threads so I'm not
linking -lpthread (a requirement on glibc, which subtly changes the
behavior of lots of stuff, plus now it won't build on a toolchain built
with --disable-threads and it starts caring about allocating a thread
local storage block/register... I use "minimal bootstrapping cycle" as a
proxy for ease of porting to new hardware targets, ease of fully
understanding a system end to end (ala xv6's explicit educational goal),
and people keep gluing chunks of busybox into bootloaders and RTOS's
where you have to manually provide all the system interfaces the code
uses and if they might want to do the same with toybox someday keeping
it down to a dull roar is useful. I'm aware /proc and /sys are a
quagmire in that regard, but I'd prefer _not_ to open another can of
worms without good reason.

In general moving the system call wrapper over into the threading
library with added gratuitous locking does not strike me as an
improvement. I just want the system call. There's a function for the
system call, with a man page and everything. Musl still PROVIDES the
function, it's just broken at runtime so as with fork() I can't compile
time probe and provide my own wrapper in portability.h only if it wasn't
there; musl gives me broken crap I can only tell is broken at runtime
and refuses to let the _build_ make decisions.

There's a theme here...

Rob