3 ms·

libc is a bad idea. Deciding the default allocator how to talk to the kernel should be provided by the same library is a bad. Musl should be able to exist with

libc is a bad idea. Deciding the default allocator how to talk to the kernel should be provided by the same library is a bad. Musl should be able to exist without providing any allocator.

sidkshatriya 3y ago
You can use other allocators with musl. For example in Chimera Linux, musl uses the llvm scudo allocator instead of the default allocator packaged with musl libc.
- Ericson2314 3y ago
  Yes and that's good, but it should be even easier. Rather than every libc needing to invent how to make the allocator pluggable, we should have that separation of concerns stock and shared by all implementations.
  - q66 3y ago
    the above is incorrect, chimera does use scudo but it patches musl to achieve that and scudo is probably one of the few allocators that would work for this purpose, it absolutely cannot be applied to any allocator; there are some concerns that get in the way of that, e.g. the handling of ELF TLS in a libc (ELF TLS may not be and in musl's case is not available within the dynamic linker, which means you cannot use __thread and the likes anywhere within libc.so; scudo is designed to be flexible so you can get around it (we shove a pointer to the thread-local state directly in the pthread structure and manually mmap the data for it) but that is not necessarily the case with many other allocators, including mimalloc, hardened_malloc, and others)
flohofwoe 3y ago
The question that popped into my mind is rather: why does Rust rely on the C stdlib at all (e.g. why even call into musl or glibc). Shouldn't the Rust stdlib implement its own allocator which directly requests memory from Linux via syscalls?
- Ericson2314 3y ago
  That is what Go does. BSDs hate it. https://github.com/redox-os/relibc https://github.com/redox-os/relibc could be repurposed for this easily enough.

3 ms·

libc is a bad idea. Deciding the default allocator how to talk to the kernel should be provided by the same library is a bad. Musl should be able to exist with

by Ericson2314 3y ago

libc is a bad idea. Deciding the default allocator how to talk to the kernel should be provided by the same library is a bad. Musl should be able to exist without providing any allocator.

sidkshatriya 3y ago
You can use other allocators with musl. For example in Chimera Linux, musl uses the llvm scudo allocator instead of the default allocator packaged with musl libc.
- Ericson2314 3y ago
  Yes and that's good, but it should be even easier. Rather than every libc needing to invent how to make the allocator pluggable, we should have that separation of concerns stock and shared by all implementations.
  - q66 3y ago
    the above is incorrect, chimera does use scudo but it patches musl to achieve that and scudo is probably one of the few allocators that would work for this purpose, it absolutely cannot be applied to any allocator; there are some concerns that get in the way of that, e.g. the handling of ELF TLS in a libc (ELF TLS may not be and in musl's case is not available within the dynamic linker, which means you cannot use __thread and the likes anywhere within libc.so; scudo is designed to be flexible so you can get around it (we shove a pointer to the thread-local state directly in the pthread structure and manually mmap the data for it) but that is not necessarily the case with many other allocators, including mimalloc, hardened_malloc, and others)
flohofwoe 3y ago
The question that popped into my mind is rather: why does Rust rely on the C stdlib at all (e.g. why even call into musl or glibc). Shouldn't the Rust stdlib implement its own allocator which directly requests memory from Linux via syscalls?
- Ericson2314 3y ago
  That is what Go does. BSDs hate it. https://github.com/redox-os/relibc https://github.com/redox-os/relibc could be repurposed for this easily enough.