[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240801025445.GQ10433@brightrain.aerifal.cx>
Date: Wed, 31 Jul 2024 22:54:46 -0400
From: Rich Felker <dalias@...c.org>
To: Valter Sage <manipuladordedados@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Inquiry Regarding Patch Review Process for musl
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
