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

Thomas Petazzoni thomas.petazzoni at bootlin.com
Mon May 13 20:13:41 UTC 2019


Hello Stefan,

Thanks for your contribution!

On Mon, 13 May 2019 22:00:58 +0200
stefan.nickl at gmail.com wrote:

> Signed-off-by: Stefan Nickl <Stefan.Nickl at gmail.com>
> ---
>  package/musl/0002-sched-linux-compat.patch | 74 ++++++++++++++++++++++
>  1 file changed, 74 insertions(+)
>  create mode 100644 package/musl/0002-sched-linux-compat.patch
> 
> diff --git a/package/musl/0002-sched-linux-compat.patch
> b/package/musl/0002-sched-linux-compat.patch
> new file mode 100644
> index 0000000000..c1626ea7c3
> --- /dev/null
> +++ b/package/musl/0002-sched-linux-compat.patch
> @@ -0,0 +1,74 @@
> +The POSIX functions sched_getscheduler(), sched_setscheduler(),
> +sched_getparam(), sched_setparam() are technically not correctly
> +implemented by the Linux syscalls of the same name, because what the
> +kernel calls a PID and what POSIX calls a PID isn't truly the same,
> +resulting in somewhat different semantics as to what these functions
> +exactly apply to.
> +
> +Since the musl developers put a high premium on POSIX compliance, they
> +deliberately implement these functions to return -ENOSYS instead of
> +relaying them to the respective Linux syscalls as glibc/uClibc do.
> +
> +This means that virtually all programs written for Linux using these
> +functions are currently broken. For example running 'chrt -p 1' fails
> +with "Function not implemented" on a musl-libc based system.
> +
> +While the musl developers are right strictly speaking, it seems
> +unfeasible to fix all affected programs in a way that hardly any Linux
> +developer will consider to be broken in the first place. So this patch
> +simply changes musl to fall in line with the other libcs.
> +
> +Signed-off-by: Stefan Nickl <Stefan.Nickl at gmail.com>

On a purely formatting point of view, we will need this patch to be
generated by git format-patch.

However, I really wonder if we want to carry this kind of change/fix
inside Buildroot. We would have to keep it forever, because it's
basically something the musl upstream developers would never accept.

On the other hand, we already have some quirks for musl in the
musl-compat-headers, and maybe we want to be more pragmatic than the
musl upstream developers are.

Peter, Arnout, Yann, others, any opinion ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


More information about the buildroot mailing list