Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 Aug 2018 01:12:56 +0200
From: Alexander Revin <>
Subject: Re: musl on a different syscall layer?

> On Wed, Sep 17, 2014 at 7:02 PM,  <> wrote:
>> On Wed, Sep 17, 2014 at 01:53:46PM -0400, Rich Felker wrote:
>>> The main requirement is having equivalent functionality available. On
>>> the BSD targets I've asked BSD folks about, there's supposedly no
>>> equivalent of futex except inthe Linux compat layer, which is pretty
>>> much a show-stopper unless/until it can be remedied. clone is a big
>>> unknown to me too. The other big potential problem is if the native
>>> syscall API requires a stack to communicate with the kernel (one or
>>> more BSDs require this, IIRC), since at least __unmapself needs to be
>>> able to call SYS_munmap and SYS_exit without a stack.
>> Oh I see.
>> This means "not much to hope for" (pity but good to know).

> I don't think NetBSD uses the stack for syscalls on any common
> architecture, maybe on some of the obscure ones, but maybe you don't
> want to support them.
> Adding futex support to NetBSD would be an interesting project; it is
> not in the compat layer at present either, so that is a good reason to
> add it. NetBSD is pretty friendly...
> Justin (

Hi guys, sorry for reviving a dead thread, but do you know if things
has changed ever since? I'm asking also because it would be nice to
unify efforts of porting musl to another archs - for example, openrisc
or m68k - though there're ports for both Linux and NetBSD, libc
support is kind of scattered over large codebase.


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.