From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14524 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [Support]: Porting Musl to a non Linux kernel Date: Wed, 7 Aug 2019 02:24:53 -0400 Message-ID: <20190807062453.GB9017@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="4873"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14540-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 07 08:25:11 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hvFNm-000183-7Z for gllmg-musl@m.gmane.org; Wed, 07 Aug 2019 08:25:10 +0200 Original-Received: (qmail 17838 invoked by uid 550); 7 Aug 2019 06:25:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17816 invoked from network); 7 Aug 2019 06:25:06 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14524 Archived-At: 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