[Buildroot] [PATCH] package/musl: Make scheduler functions Linux-compatible

[stefan.nickl at gmail.com]

On Tue, 2019-05-14 at 22:24 +0200, Yann E. MORIN wrote:
> Stefan, All,
> 
> On 2019-05-14 22:03 +0200, stefan.nickl at gmail.com spake thusly:
> > On Tue, 2019-05-14 at 21:38 +0200, Arnout Vandecappelle wrote:
> > > On 14/05/2019 20:54, stefan.nickl at gmail.com wrote:
> > > > On Tue, 2019-05-14 at 20:04 +0200, Arnout Vandecappelle wrote:
> > > > >  As Thomas wrote, the patch as it is is not upstreamable
> > > > > since
> > > > > musl
> > > > > considers
> > > > > this a feature.
> > > > > 
> > > > >  However, it is possible that Rich can be convinced to
> > > > > actually
> > > > > read
> > > > > the POSIX
> > > > > spec and decide that linux behaviour is correct (except for
> > > > > the
> > > > > fact
> > > > > that it
> > > > > sched_setscheduler() should return the previous scheduling
> > > > > policy
> > > > > rather than 0,
> > > > > but that can be approximated (in a racy way) by calling
> > > > > sched_getscheduler()
> > > > > first). So it might be worth trying to push the patch
> > > > > upstream.
> > > > 
> > > > Hi Arnout,
> > > > 
> > > > I think upstreaming is out of the question since Rich has
> > > > actually
> > > > *undone* it before 
> > > > https://git.musl-libc.org/cgit/musl/commit/?id=1e21e78bf7a5
> > > > 
> > > > Also asked on #musl a couple days ago whether they might be
> > > > willing
> > > > to
> > > > at least #ifdef it, and only got suggestions for application
> > > > side
> > > > fixes. So, no dice it seems.
> > > 
> > >  Yes, but has the argument "Linux does in fact implement POSIX"
> > > been
> > > used already?
> > 
> > I haven't used that argument and I'm not aware of anyone that has.
> > 
> > This comes pretty close though: 
> > https://github.com/MusicPlayerDaemon/MPD/issues/218
> > 
> > And just recently Rich managed to convince even the glibc
> > developers of
> > the opposite, so I certainly don't feel up to arguing that position
> > ;-)
> > https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c70824b9a4645c0ecd049da8cfdb2c28ae7ada23
> 
> So, if glibc is going the musl way, because Linux does not allow to
> properly implement the sched_* stuff, when why do we even attempt to
> implement them in musl at all?

Hi Yann,

that's not what I'm seeing.

The glibc folks are not going to change the library call <-> Linux
syscall correspondence.
They merely make note of the fact that they've screwed up in the past,
and that now it is too late to change.
All that happens is that the non-conformance gets documented.

What makes this extra confusing is that there are source files in the
glibc tree with -ENOSYS-returning implementations of these functions,
but it seems the functions that really get used for Linux are generated
from a syscalls.list file to use the syscall.
Maybe someone more familiar with glibc can confirm this.
In the uclibc-ng case, it seems rather straightforward, see e.g.
libc/sysdeps/linux/common/sched_setscheduler.c

Cheers,
Stefan