mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <>
Subject: Re: [musl] musl -- FFS get your shit together, please
Date: Mon, 17 Jul 2023 17:32:34 +0200	[thread overview]
Message-ID: <ZLVfEocHrBR7p8HM@voyager> (raw)
In-Reply-To: <>

I realize this is a flame, and I may be feeding the fire. I hope the OP
reads this when he has cooled off a bit.

Am Mon, Jul 17, 2023 at 01:17:58AM -0500 schrieb Dave Blanchard:
> 2) Did it occur to anyone involved in this project to maybe actually
> organize and COMMENT the system header files, instead of just randomly
> throwing a random assortment of shit into an .H file and calling it
> good? The amount of duplicated, undocumented, assorted crap is pretty
> ridiculous for a project that's supposed to be a FROM SCRATCH libc
> implementation! How about getting it right from the beginning, with a
> clean and organized implementation, instead of starting off with a
> random pile of shit? Even glibc is better organized, for fuck's sake!

Most documentation is in the commit comments. As for the organization
being bad, I would dispute that. Everything that ends up in libc is in
src/*/*.c or src/*/$ARCH/*.[csS], with the latter always included, and
overriding any of the former with the same name that may be present.
Dynlinker is in ldso/ and CRT is in crt/.

Meanwhile in glibc, you have the sysdeps directory, and if there is any
organization to it, I haven't found it.

> 3) Why in the hell does musl duplicate/change(!) internal structures
> from Linux kernel headers instead of just #include'ing the damn Linux
> headers (and relevant structures) and be done with it?

So musl is independent of the kernel version installed. This has many
advantages, such as being able to build musl without even having a
kernel installed at all. The kernel APIs (syscall/ioctl numbers and
structures) must all be stable anyway, or else violate the kernel's ABI
stability goals.

Some kernel interfaces also conflict with userspace interface. E.g.
struct msghdr is supposed to contain members of type "socklen_t" as per
POSIX, but Linux defines them to contain the length fields as "unsigned
long", which is a different type on 64-bit systems. So musl must define
padding fields to smoothe things over.

Generally, Linux header files are not compatible with userspace
programs. musl's approach is the one favored by most applications and
libraries that actually do anything with the kernel, such as libfuse and

> 4) Would it kill you to add in various simple #defines and such in the
> headers which greatly improve compatibility with GNU code, without
> actually requiring any support in the libc library code??

Would probably not kill anyone, but being compatible with glibc is
simply not a musl goal. musl aims to be a POSIX implementation. Some
concessions to the real world have been made, beyond that, there's
gcompat. For everything else, there's patches.

> Between the above, plus the 6-7 "musl addon" support packages required
> to be installed alongside to make my Linux system build with musl, at
> this point I have essentially FORKED musl!

As is your right as per the license. Where's the problem?


      parent reply	other threads:[~2023-07-17 15:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-17  6:17 Dave Blanchard
2023-07-17  7:20 ` (GalaxyMaster)
2023-07-17 12:14 ` Daniel Gutson
2023-07-17 15:21 ` Rich Felker
2023-07-17 15:43   ` [musl] ITT: Nothing but a bunch of excuses and no solutions Dave Blanchard
2023-07-17 15:50     ` Joakim Sindholt
2023-07-17 17:12     ` Rich Felker
2023-07-17 17:23     ` Laurent Bercot
2023-07-17 16:01   ` [musl] musl -- FFS get your shit together, please Jeffrey Walton
2023-07-17 16:10     ` Joakim Sindholt
2023-07-17 16:55     ` Rich Felker
2023-07-17 15:32 ` Markus Wichmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZLVfEocHrBR7p8HM@voyager \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).