[Buildroot] [PATCH 0/9] Introducing service supervision/management with s6
Eric Le Bihan
eric.le.bihan.dev at free.fr
Tue Aug 9 19:54:12 UTC 2016
Hi!
Le Tue, 9 Aug 2016 06:14:44 +0200,
Waldemar Brodkorb <wbx at openadk.org> a écrit :
> > This series provides all the packages for programs and libraries to
> > build an embedded system with service supervision and management
> > using s6 from http://skarnet.org.
> >
> > Note that these packages only provide the mechanism for
> > supervising/managing services using s6, not the policy. Packages to
> > provide a policy suitable for Buildroot-based embedded systems,
> > using s6 as init (instead of SysV or systemd), will be provided
> > later. An example is available in the buildroot-s6 demo project
> > [1].
>
> Is there a reason s6 series depends on glibc or musl?
The problem with uclibc-ng is twofold:
1. a compilation issue.
2. a runtime lock-up.
I've finally found time to tackle these issues ;-).
When configuring skalibs, a runtime test is created to check if
posix_spawnp() is present. For whichever reason, when using uclib-ng.
this function is provided by librt. So by default the test fails and
instead of using posix_spawnp(), the function child_spawn0() from
skalibs falls back to a fork/execve homegrown version. This fallback
function is buggy but this has been fixed [0], but this is not
available in skalibs 2.3.10.0.
Anyway, the ./configure script from skalibs can be patched to check
for posix_spawnp() in librt. But then, for each package skarnet
program/library, this extra library should be passed to the build
process (e.g. execline):
```
ifeq ($(BR2_TOOLCHAIN_USES_UCLIBC),y)
EXECLINE_MAKE_OPTS = EXTRA_LIBS="-lrt"
endif
```
Unfortunately, posix_spawnp() is buggy, which results in the `if`
command from execline going into an infinite loop. This due to a
incorrect pointer update in __spawni(). I sent a patch upstream to
fix this [2].
So the limitation can now be removed, provided I add one patch for
skalibs and one for uclibc-ng. I'll check with the skalibs maintainer
to see if there is a cleaner way to handle the uclibc-ng librt issue,
because I'd prefer to avoid using the EXTRA_LIBS variable trick in all
the skarnet packages.
Or I can also backport [1] as a temporary workaround.
> I once played with s6, but was scared about pre-configring for all
> architectures. Do you think your patch to skalibs has any chance to
> be upstreamed?
The patch for detecting the endianness was previously discussed [3]. As
Thomas P. suggested some improvements for type size checks, I'll bump
the topic once this part has been reworked.
[1]
http://git.skarnet.org/cgi-bin/cgit.cgi/skalibs/commit/?id=2dc76616b2b0884f0203cf36b58f94c5656c0c81
[2]
http://mailman.uclibc-ng.org/pipermail/devel/2016-August/001126.html
[3]
http://www.mail-archive.com/supervision@list.skarnet.org/msg01034.html
Best regards,
--
ELB
More information about the buildroot
mailing list