[musl] Inquiry Regarding Patch Review Process for musl

[musl] Inquiry Regarding Patch Review Process for musl

[Valter Sage]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

Dear musl Development Team,

I greatly admire the musl project and regularly use systems that
incorporate it. However, I am involved in a project that unfortunately
still does not work on musl-based systems, despite patches being
submitted quite some time ago. To cite a couple of examples:

- https://www.openwall.com/lists/musl/2021/08/11/3
- https://www.openwall.com/lists/musl/2022/08/10/1

Additionally, there are many other patches I have noticed, such as the
fdlopen patch, which was submitted a long time ago.

I understand that every open-source project faces challenges,
particularly in terms of code review and approval. However, it is
concerning that numerous patches submitted to musl do not receive
responses or are entirely ignored. This lack of feedback not only
discourages contributors but also hinders the adoption and improvement
of musl in various projects.

Could you please provide some insights into the reasons behind this?
Is there a specific bottleneck in the review process or criteria that
patches must meet to be considered? Understanding this would be
immensely helpful for the community and for those of us who rely on
musl for our projects.

Thank you for your attention to this matter. I look forward to your
response.

[-- Attachment #2: Type: text/html, Size: 1486 bytes --]

Re: [musl] Inquiry Regarding Patch Review Process for musl

[Rich Felker]

On Wed, Jul 31, 2024 at 07:08:22PM -0300, Valter Sage wrote:
> Dear musl Development Team,
> 
> I greatly admire the musl project and regularly use systems that
> incorporate it. However, I am involved in a project that unfortunately
> still does not work on musl-based systems, despite patches being
> submitted quite some time ago. To cite a couple of examples:
> 
> - https://www.openwall.com/lists/musl/2021/08/11/3

The syscalls were added in commit
ee05b11b67d59a6c5bb4b9d661bcc20bbd0bbe7a.

> - https://www.openwall.com/lists/musl/2022/08/10/1

The replies indicate both that the functionality is controversial (its
main purpose is invoking UB) and that there were open questions about,
if it were accepted, what kind of fallback there should be, if any,
for kernels without the syscall.

> Additionally, there are many other patches I have noticed, such as the
> fdlopen patch, which was submitted a long time ago.

fdlopen meets pretty much all the criteria for exclusion. It's not a
widely agreed upon function across implementations, it has lots of
subtleties in behavior (how name is determined, whether the loaded
library has a name for the purpose of searching to use it as a dep,
etc.) that are prone to being incompatible/mismatching with what
applications wanting to use it would expect, and it has really no
practical advantage over the standard way to do the same thing (with a
pathname), just an ideological one.

> I understand that every open-source project faces challenges,
> particularly in terms of code review and approval. However, it is
> concerning that numerous patches submitted to musl do not receive
> responses or are entirely ignored. This lack of feedback not only
> discourages contributors but also hinders the adoption and improvement
> of musl in various projects.

Of the ones you cited, one was already merged (just as part of a
larger series submitted by nsz earlier) and the other *did* have
replies indicating why it wasn't merged.

musl is not a project where anything or even most things you can
propose as patches are going to be accepted. We are implementing
standards and *widely agreed-upon, cross-platform* extensions, not
every random feature somebody comes up with and thinks would be nice
to have in libc. The goal is not to facilitate making software which
depends on musl, but making a better foundation for software which
works everywhere, whether people want to use musl or something else.

Rich