[Toybox] musl intentionally broke chrt

[enh]

On Wed, Aug 30, 2017 at 1:42 AM, Rob Landley <rob at landley.net> wrote:
> On 08/29/2017 10:32 AM, enh wrote:
>> On Tue, Aug 29, 2017 at 8:32 AM, enh <enh at google.com> wrote:
>>> can't you just infer musl from the relatively small
>>
>> ...number of c libraries out there...
>
> It would work, but I'm uncomfortable with it.
>
> People keep threatening to port toybox to to BSD and MacOS, there is an
> active uClibc fork buildroot's using, it's posible newlib, klibc, or
> dietlibc will grow legs someday, far down on my todo list is maybe
> porting toybox to xv6, what library is fuchsia using, musl itself didn't
> publicly exist ~5 years ago...

1. YAGNI
2. if you ever do, you can just add them

> The posix API is insufficient so I'm using Linux as my API, but
> freebsd's Linux emulation layer is a viable target too, and I wanted the
> rest of it to be as generic as I could with target-specific stuff hidden
> in portability.h. That means C library, compiler, processor architecture...
>
> I'm not sure that's _achievable_ with musl refusing to identify itself
> because its' experience is universal and everyone else is wrong...
>
> Sigh. If I'm going to have the "else case" apply workarounds, I might as
> well make the workarounds apply to everybody. Calling the syscalls
> directly isn't that big a deal.

yes and no...

yes: this is certainly the reason why bionic only uses non-legacy
system calls. aarch64 doesn't have the legacy calls, and rather than
have code paths that differ depending on architecture, we do the same
thing everywhere. (so for example bionic never calls open; it's always
openat, regardless of architecture.)

no: the point of the C library is to hide the mapping from
functionality to system call. if you ever do port to BSD/macOS you'll
need to cope with their syscall differences if you don't let the C
library do it, and you're likely to hit places on Android where the
traditional system call isn't allowed because bionic doesn't use it
and seccomp disables the rest.

> But having musl stay broken because it broke itself seems pretty
> reasonable too. The fact is, Linux has a system call and the man page
> says we have a certain behavior, and musl isn't supporting that. If you
> build against a uClibc where you switched off regex support, grep won't
> work. If you build against a musl you haven't fixed, chrt won't work...
>
> (This is one of those "the choices are close enough that there's no
> obvious winner" things that's harder to make than a more important
> decision would be. :)

yeah, there are enough theoretical pulls in different directions here
that it makes sense to see which ones actually matter as time goes by.

> Right now I've thrown it back on the todo list, which means "musl stays
> broken" is the default for now. Probably acceptable. Lemme finish this
> utf8 plumbing and then I need to fix ps again, then get back to... was
> lsof or dd next?

didn't you get in to utf8 because of my wc -m patch? :-)

> Rob
>
> (Taking a break from endless GPS. For some reason it takes me about a
> day to switch mental contexts after doing serious GPS stuff, and I keep
> getting sucked back into "5 more minutes of GPS, just this one quick
> thing" that turns into 8 hours, so I'm saying no a bit because the
> toybox todo heap is teetering dangerously September 19th is the 3 month
> anniversary of last release which means time for a new one...)



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.