From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=LONGWORDS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32406 invoked from network); 20 Aug 2021 20:29:57 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Aug 2021 20:29:57 -0000 Received: (qmail 25795 invoked by uid 550); 20 Aug 2021 20:29:55 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 25771 invoked from network); 20 Aug 2021 20:29:54 -0000 Date: Fri, 20 Aug 2021 16:29:41 -0400 From: Rich Felker To: Olivier Galibert Cc: musl@lists.openwall.com Message-ID: <20210820202940.GQ13220@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Is systemd in scope for musl? On Fri, Aug 20, 2021 at 08:55:43PM +0200, Olivier Galibert wrote: > Hi, > > I'm trying to build a kinda-distribution of linux on arm64 where all the > userspace is done with clang and which uses systemd[1]. I can either use > glibc or musl. Glibc aggressively does not want to be compiled by anything > else than gcc. Musl is missing a bunch of stuff systemd wants. > > I have two possibilities, either make glibc work but not contribute the > changes (because I don't want to give my copyright to the fsf[2]) or extend > musl until it has all the missing APIs and contribute them. I'd rather do > the latter. systemd support is out of scope because systemd has no contract for what they will use except "anything in glibc we like". We are not going to get in the business of letting systemd dictate what goes in musl, and are not going to start adding functions now that just happen to make the current version of systemd build, because they will never be enough and folks will just complain again when it breaks, and we'll be stuck maintaining the junk functions we added already. This has been discussed in at least one thread in the past. On the other hand, many people have successfully used systemd with musl just by patching it not to use glibcisms. I believe yocto/openembedded maintains patches for this. > Some APIs (qsort_r) are clearly going to be added in the future. Others > are very glibc, e.g. printf configurability stuff, and do not come from any > standard. So, is "this API is used by systemd" a good enough reason to > accept it as in-scope for musl[3] or will there be things that are "never" > going to be accepted? The criteria for inclusion/exclusion of nonstandard interfaces involve multiple factors including existing precedent across multiple systems, how widely used it is in applications, whether there's justifiable reason applications need it vs existing portable interfaces, size of code, interactions with other libc components that constrain their implementations, etc. The printf customization stuff is a huge no in that last area, introducing mutable global state where there was none and being library-unsafe (impossible for different independent parts of the application to each use without stepping on each other). Some of the other things systemd wants aren't "hard" no's, but simply have nothing significant using them except systemd, which is apparently using them for the sake of being stubborn, and lots of individual soft reasons to lean towards no. Rich