<div dir="ltr">Per POSIX, <sched.h> is in ths [PS] (Process Scheduling) option. You can identify whether [PS] is implemented at compile time, by the value of _POSIX_PRIORITY_SCHEDULING defined in <unistd.h>. This can be one of<div><br></div><div>* Undefined or -1, functionality never supported</div><div>* 0, functionally *maybe* supported (you can enquire with sysconf(_SC_PRIORITY_SCHEDULING) at runtime). You can compile against it, but it might not work.</div><div>* 200809L, supported per POSIX 2008 (Or potentially a different value for a different version of POSIX)</div><div><br></div><div>(The sysconf call can return either -1 or 200809L)</div><div><br></div><div>musl doesn't define _POSIX_PRIORITY_SCHEDULING, so per POSIX is declaring that it does not support that function grouping.<br><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 30, 2017 at 9:42 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/29/2017 10:32 AM, enh wrote:<br>
> On Tue, Aug 29, 2017 at 8:32 AM, enh <<a href="mailto:enh@google.com" target="_blank">enh@google.com</a>> wrote:<br>
>> can't you just infer musl from the relatively small<br>
><br>
> ...number of c libraries out there...<br>
<br>
It would work, but I'm uncomfortable with it.<br>
<br>
People keep threatening to port toybox to to BSD and MacOS, there is an<br>
active uClibc fork buildroot's using, it's posible newlib, klibc, or<br>
dietlibc will grow legs someday, far down on my todo list is maybe<br>
porting toybox to xv6, what library is fuchsia using, musl itself didn't<br>
publicly exist ~5 years ago...<br>
<br>
The posix API is insufficient so I'm using Linux as my API, but<br>
freebsd's Linux emulation layer is a viable target too, and I wanted the<br>
rest of it to be as generic as I could with target-specific stuff hidden<br>
in portability.h. That means C library, compiler, processor architecture...<br>
<br>
I'm not sure that's _achievable_ with musl refusing to identify itself<br>
because its' experience is universal and everyone else is wrong...<br>
<br>
Sigh. If I'm going to have the "else case" apply workarounds, I might as<br>
well make the workarounds apply to everybody. Calling the syscalls<br>
directly isn't that big a deal.<br>
<br>
But having musl stay broken because it broke itself seems pretty<br>
reasonable too. The fact is, Linux has a system call and the man page<br>
says we have a certain behavior, and musl isn't supporting that. If you<br>
build against a uClibc where you switched off regex support, grep won't<br>
work. If you build against a musl you haven't fixed, chrt won't work...<br>
<br>
(This is one of those "the choices are close enough that there's no<br>
obvious winner" things that's harder to make than a more important<br>
decision would be. :)<br>
<br>
Right now I've thrown it back on the todo list, which means "musl stays<br>
broken" is the default for now. Probably acceptable. Lemme finish this<br>
utf8 plumbing and then I need to fix ps again, then get back to... was<br>
lsof or dd next?<br>
<br>
Rob<br>
<br>
(Taking a break from endless GPS. For some reason it takes me about a<br>
day to switch mental contexts after doing serious GPS stuff, and I keep<br>
getting sucked back into "5 more minutes of GPS, just this one quick<br>
thing" that turns into 8 hours, so I'm saying no a bit because the<br>
toybox todo heap is teetering dangerously September 19th is the 3 month<br>
anniversary of last release which means time for a new one...)<br>
_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div></div></div></div>