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  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? > >  - 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.