[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190807062453.GB9017@brightrain.aerifal.cx>
Date: Wed, 7 Aug 2019 02:24:53 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [Support]: Porting Musl to a non Linux kernel
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
