Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Musl-libc version 1.0.0 released

musl-libc.org

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Musl-libc version 1.0.0 released

#21

Post by dalias »

Fede_V wrote: post #17
dalias wrote: post #15

Hi all. I'm the original author and maintainer of musl, and I'm happy to answer any questions anyone might have about the project. Glad to see so much interest!

First - awesome job! I'm curious, what motivated you to start working on it?

The original idea goes back to around 2005 and frustration at the ever-growing size of glibc and poor (slow) support for UTF-8. At the time I made a prototype and used it personally. In 2010 I relaunched the project with a goal of doing it a lot better and targeting user bases who might actually be looking for a new libc; later on this turned out to include a lot of people unhappy with GPL/LGPL, so we re-licensed from LGPLv2.1+ to MIT.

Re: Musl-libc version 1.0.0 released

#22

Post by dalias »

jokoon wrote: post #19

wait, but I thought premature optimization was evil !

musl actually has very little in the way of optimization, premature or otherwise. Most functions are written to be as simple and direct as possible. Often but not always this gives near-optimal size and speed too. The places where more complex approaches are used are _mostly_ situations where the naive solution would have corner cases that fail or corner cases that have pathologically bad performance and could be used as a DoS attack vector. The main exception is things like memcpy, memset, etc.; if they're slow, people are generally very unhappy.

BTW, one difficulty in libc is that it's hard to know what optimizations are "premature" because you can't envision everybody's usage cases without an enormous volume of experience with third-party code.

Re: Musl-libc version 1.0.0 released

#23

Post by JoshTriplett »

dalias wrote: post #15

Hi all. I'm the original author and maintainer of musl, and I'm happy to answer any questions anyone might have about the project. Glad to see so much interest!

How much abstraction does musl have over the use of Linux syscalls, and how easily could it supply a partial libc for some other environment, such as an embedded bare-metal environment?

Re: Musl-libc version 1.0.0 released

#24

Post by dalias »

JoshTriplett wrote: post #23
dalias wrote: post #15

Hi all. I'm the original author and maintainer of musl, and I'm happy to answer any questions anyone might have about the project. Glad to see so much interest!

How much abstraction does musl have over the use of Linux syscalls, and how easily could it supply a partial libc for some other environment, such as an embedded bare-metal environment?

Fairly easily.

A relatively small number of syscalls are used as part of implementing other functions. Most if not all of these are made via macros that expand to inline syscalls; by replacing them with a call into your own function that implements the equivalent of the syscalls you need "on the metal" rather than calling into a kernel, most of the work is done.

Some syscalls are made directly from assembly source files because C is unable to represent the work that needs to be done around them (e.g. clone and vfork) or simply because their usage is arch-specific. These obviously use the trap-to-kernel instructions directly and cannot be re-routed as described above. Still the number of files is so small you could just rewrite the asm.

One future direction (albeit with lower priority than further functionality/quality improvements, unless somebody funds it) is making it easier to port to bare-metal and documenting the process.

Re: Musl-libc version 1.0.0 released

#25

Post by anonemouscoward »

justincormack wrote: post #2

I have been using Musl for various purposes for quite some time. I think my favourite things are: * The team are very helpful, and fix things fast and correctly. You can see some of the detail in this post on race conditions in glibc http://ewontfix.com/16/ * It is very standards compliant, so it is a good portability test for your code. It is a bit like using a BSD libc, except it does have Linux specific syscalls e…

> Static linking works

False. It doesn't. At the very least, VDSO support on Linux for static builds is broken.

I.e., calls to time() and gettimeofday() and friends will be orders of magnitude slower when linking statically.

Looking at the code I think nobody on the team was even aware that this is an important corner case.

I'll stick to glibc, they at least do proper testing.

Re: Musl-libc version 1.0.0 released

#27

Post by throwawayaway »

dalias wrote: post #15

Hi all. I'm the original author and maintainer of musl, and I'm happy to answer any questions anyone might have about the project. Glad to see so much interest!

Is there any reason why, theoretically, using LD_PRELOAD to replace libc6 with this would not work?

Re: Musl-libc version 1.0.0 released

#29

Post by dalias »

throwawayaway wrote: post #27
dalias wrote: post #15

Hi all. I'm the original author and maintainer of musl, and I'm happy to answer any questions anyone might have about the project. Glad to see so much interest!

Is there any reason why, theoretically, using LD_PRELOAD to replace libc6 with this would not work?

LD_PRELOAD alone wouldn't do it because glibc's dynamic linker is closely tied to glibc. In particular thread-local storage requires close cooperation between them. Likewise, musl needs its own dynamic linker.

What could be done in theory is replacing /lib/ld-linux.so.2 with a symlink to musl. One of the long-term goals for musl is for this to actually work, at least for many programs. But right now there are a lot of glibc-specific symbols that get pulled in magically by glibc's headers, even when the program at the source-level is 100% portable code, and we don't have coverage for all of these.

Re: Musl-libc version 1.0.0 released

#30

Post by throwawayaway »

dalias wrote: post #29
throwawayaway wrote: post #27

Earlier quoted context omitted.

Is there any reason why, theoretically, using LD_PRELOAD to replace libc6 with this would not work?

LD_PRELOAD alone wouldn't do it because glibc's dynamic linker is closely tied to glibc. In particular thread-local storage requires close cooperation between them. Likewise, musl needs its own dynamic linker. What could be done in theory is replacing /lib/ld-linux.so.2 with a symlink to musl. One of the long-term goals for musl is for this to actually work, at least for many programs. But right now there are a lot o…

Excellent response! I have a program that spends 10% of it's time in vfprintf for string processing, and I really think the program should not be spending that much time/any time there. I looked at the libc6 vfprintf implementation and it's pretty esoteric looking stuff. It might be worth my time using your library or something similar to swap it out.
Post reply on HN