[Support]: Porting Musl to a non Linux kernel

[Support]: Porting Musl to a non Linux kernel

[Ben Mezger]

Hi,

I've been interested in porting Musl to a microkernel I've been
working on. The 'how to use' page [1] mentions this possibility, but I
haven't found any documentation specifying on how to archive this.

Has anyone done something similar of has any resource I can check?

[1] - https://www.musl-libc.org/how.html

-- 
Kind regards,
Met een vriendelijke groet,

Ben Mezger
https://seds.nl
PGP: B456 B356 E3DC F1A6 1479  C936 AC7A 3084 3ADC 0D65

Re: [Support]: Porting Musl to a non Linux kernel

[Szabolcs Nagy]

* Ben Mezger <me@benmezger.nl> [2019-08-06 17:40:44 -0300]:
> I've been interested in porting Musl to a microkernel I've been
> working on. The 'how to use' page [1] mentions this possibility, but I
> haven't found any documentation specifying on how to archive this.
> 
> Has anyone done something similar of has any resource I can check?
> 
> [1] - https://www.musl-libc.org/how.html

i don't see where it is mentioned.

musl assumes linux syscalls, if your os does not have
linux syscall emulation then you will have to do some
porting.

example ports of musl to webassembly and windows nt:

https://github.com/NWilson/musl/blob/musl-wasm-native/arch/wasm/bits/syscall.h.in
https://git.midipix.org/mmglue/tree/arch/nt64/syscall_arch.h

depending on the os and the level of posix support you
want to achive this can be moderate to large amount of
work.

Re: [Support]: Porting Musl to a non Linux kernel

[Rich Felker]

On Tue, Aug 06, 2019 at 05:40:44PM -0300, Ben Mezger wrote:
> Hi,
> 
> I've been interested in porting Musl to a microkernel I've been
> working on. The 'how to use' page [1] mentions this possibility, but I
> haven't found any documentation specifying on how to archive this.
> 
> Has anyone done something similar of has any resource I can check?
> 
> [1] - https://www.musl-libc.org/how.html

There is not any existing "framework" for porting to bare-metal or
non-Linux-syscall-API environments. For various subsets of musl, it
could be done pretty easily with some additional thin abstraction
layers, but these subsets are ones where it would be trivial to just
wire up syscalls that are largely "generic unix syscalls" without
anything Linux-specific to them.

But for the parts that are not easy, and where musl is doing
significant work in userspace to make them work -- especially
everything to do with threads -- it's a delicate balance of the
primitives that Linux provides that makes it possible to implement
correct versions of the POSIX functions at all, and any abstraction is
either not going to be able to do it right, or is going to be so
abstract that it's just a duplication of the (e.g. pthread) API
exposed to the application.

In light of this, the *preferred* way to do musl on alternate kernels,
if you can do it this way, is to provide an ABI-compatible or at least
API-compatible syscall interface. If ABI-compatible, you could use the
existing musl archs and even musl binaries built for Linux on your
kernel. If it's only API-compatible, you'd be doing a custom arch
tree, but all the src/* code in musl should still work.

One option that makes sense for bare metal, which I believe several
people have done successfully, might also make sense for microkernels.
The basic idea is doing the port as a custom arch where the syscalls
are defined like:

#define SYS_foo ((long)SYS_foo_function)

with SYS_foo_function being an actual function you provide, and where
__syscallN macros expand to:

((long(*)(long,long,long,long,long,long))n)(a,b,c,d,e,f)

This lets the linker link only the syscalls (or syscall stubs) that
are used, while retaining full compatibility with the code in musl
that calls them.

At some point it may make sense to do more of a baremetal/alt-kernels
porting framework, but it's not clear what one that's better than the
above would look like.

Rich