Re: musl thoughts

[Khem Raj <raj.khem@gmail.com>]

On Thu, Mar 21, 2019 at 6:11 PM Andreas Müller <schnitzeltony@gmail.com> wrote:
>
> Just prepared meta-networking/networkmanager update and spent hours to
> get musl patches applied. Have no idea if musl will build and
> currently all my machines are building.
>
> For me - not using musl and looking forward to have a beer with Khem

you will have to be sober, because I will show you data that you need
to understand :)

> explaining me why I should want musl [1] - it is just useless effort
> and patches are rejected often due to failures on musl build.
>

If you make a valid case, and seek others to chime in then it could be
considered.
but its desired to keep our musl port to be healthy.

> So on my way home I though about the options I see to handle musl specifics:
>
> 1. Continue as we do - patch recipe-wise: This is lots of efforts and
> requires resources we don't have. Most patches are created by Khem and
> it would be better for all of us to save his time for other tasks.
> 2. Sending musl related patches upstream: Surely the cleanest approach
> but even more effort because upstream maintainers all have different
> thoughts. Some of them might hear of musl for the first time and are
> possibly not keen on patches they do not see a need for.
> 3. Change our musl slightly: Many patches we currently have are
> trivial. Missing headers or #defines for missing functions... So if we
> add few headers
>   * Empty chunks for e.g <net/ethernet.h>
>   * Add defines as #define strndupa(x,s) strncpy(alloca(strlen(x)+1),x,s)
>   * ...
>

There are certain design aspects of musl which are actually turning
out to be good
e.g. there is no __MUSL__ define, so non-portable code can not be
hidden which is a good
thing, similarly, adding these defines to musl itself would probably
be not serving the purpose
of cleaning up the apps and making them portable. The fact they do
exist as patches is a reminder
to clean the application code or rethink to fix it differently. This
has actually resulted in cleaning up
many packages, several of musl initialed patches regarding portability
has been accepted in upstream
and some are not, and some are not proposed. While the eyes may hurt
to see them, it does serve a
good reminder of whats needed for a given package.

> As you might guess I'd prefer 3 because:
> + Many patches can go and don't need maintenance on upstream refactoring anymore
> + Burden for people sending patches would be reduced
> + Recipes not building with musl currently might work without further
> modification
> + Just in case musl stops (we have seen this before with others e.g
> ulibc) the cleanup would be reduced
>

this points to the above as I said. Musl stays or goes cleaning them
up would be good regardless

> Of course there are disadvantages:
> - We turn musl into glibc direction. Posix-purists do not like that.

right. and IMO its valuable for apps to be a bit portable.

> - Configuration scripts already aware of musl and deciding upon the
> existence of headers missing in musl might do the wrong thing
> - ?
>
> Some other ideas?
>

I think we should propose the fixes upstream and see what is acceptable.

> Andreas
>
> [1] http://lists.openembedded.org/pipermail/openembedded-devel/2018-March/193521.html