Hacker News Reader

Comment by IshKebab | Hacker News Reader

I skimmed it. TL;DR: Musl developers don't want to make it 100% compatible with glibc because a lot of glibc is retarded; Systemd developers don't want to avoid glibc functionality in favour of pure and holy POSIX because a lot of POSIX is retarded, and nobody actually runs pure POSIX Linux systems anyway.

Seems to me they are both right. Probably the best solution is a compromise where Musl implements some of the most commonly used / difficult to emulate functions, and systemd avoids using the rest. Won't hold my breath though.

View on HN

The systemd people are absolutely not right here. Just look at some of the interfaces they won't give up. malloc_info writes XML to a FILE* with state of the allocator. That is a comically bad interface.

Why you'd even want the state it describes in the first place I can't tell. malloc, realloc and free are the complete primitives for 50 years but somehow systemd can't function until it can spit out a few numbers into XML on top of this, for reasons? In the patchset for TFA, I was surprised to see the comment for the commit that makes this functionality conditional is marked as "this can't be upstreamed." Makes upstream sound like a bunch of babies.

> That is a comically bad interface.

I imagine it was added for debugging purposes. It looks like systemd uses it for that purpose too. Not unreasonable, though I agree, XML is a stupid output format. Supposedly so the output format can change.... and silently break clients.

Really systemd should work with glibc to make their APIs saner, and then musl can copy them.

That would be amazing, but I don't imagine that malloc internal probes would be readily accepted to musl even if they were improved. One of the things musl admits is the ability to swap allocators around; you can just LD_PRELOAD a new one. Or even, with Chimera, replace the stock one too! Having internal debug probes would mean every allocator you want to use would need to provide those same APIs, and I don't find that particularly reasonable.

How is musl special when it comes to interposing malloc? As far as I’m aware, (dynamically) swapping out malloc implementations is a messy business no matter what. Most libc implementations only “support” the behavior in the sense that they won’t stop users from “swimming in the deep end”, so to speak.

chimera does not interpose malloc, we outright patch it out inside musl, so not really something musl would support

malloc_info() is not consumed internally but it is only wired up as a debugging utility via systemd-analyze, which is sorely needed when things go bad in strange and weird ways. It would be entirely fine for a libc to just implement a stub that returns a fixed string:

<malloc version="0">Not implemented</malloc>

or so.

Reply on news.ycombinator.com