On Thu, 18.09.14 21:21, Emil Renner Berthing (syst...@esmil.dk) wrote: > Hi Tom, > > On 18 September 2014 18:29, Tom Gundersen <t...@jklm.no> wrote: > > In general, I don't think we should add patches for the sole purpose > > of non-glibc compatibility. You would in most cases be much better > > served by adding the missing functionality to your libc, rather than > > to each of the project requiring the functionality. > > Thank you for looking through these. The problem is that musl is aiming > at making a lean and efficient posix libc, not a glibc clone. So stuff > like parse_printf_format and canonicalize_file_name is not a fix, but > unnecessary bloat. So it seems I'm stuck between a rock and a hard place.
Well, "bloat" is a misleading term here. canonicalize_file_name() you can implement via a macro hence costs pretty much nothing. And parse_printf_format() is genuinely useful, that's why we make use of it. It's also something that can only be reasonably implemented at the same place your printf() implementaton is maintained, since it needs to stay compatible with that. In general I think it's a very weird approach to have a non-useful libc and then claim things would be less bloated because every user of a variety of useful GNU APIs is supposed to reimplement everything from scracth, so that we have a multitude of different, crappy implementations in a variety of projects, instead of a single one in the libc. Your overall footprint will be larger. Also, the entire dance around "POSIX is awesome and what we thrive for, and GNU is bad" is just nonsense. It shows that your libc was created for religious reasons, not for practical ones. If you want to create something useful, create something useful, but don't cut off useful functionality people use just because it was introduced by GNU, not by POSIX. The POSIX API alone does not cover many many things anyway. POSIX doesn't know epoll, pivot_root(), memfd, fanotify, inotify and all those other Linux-specific syscalls, that solve real problems. Don't tell me musl refuses to support those too? Or is Linux good, just GNU bad, hence Linux extensions are well supported, just not the ones from GNU? We will not take part in this game. Yes, we tend to gravitate more towards POSIX interfaces, if both a GNU and a POSIX version exists and both are equivalent in their functionality. But also: we will make use of GNU extensions and of Linux extensions if they are useful. And since these ultimately are part of the Linux API, that is the right thing to do. Anyway, regardless what the goal of the patches people sent us are and whether we sympasize with them, we'll always merge the ones that make sense to us. We are not married to GNU, but we are married to the idea that we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes. Hope that makes sense, Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list email@example.com http://lists.freedesktop.org/mailman/listinfo/systemd-devel