musl on a different syscall layer?

musl on a different syscall layer?

[u-wsnj]

An observation, NetBSD libc file looks about 50% bigger than musl
being used (via Linux ABI) on the same system.

I am also kind of put off by the NetBSD monolithic build environment,
musl seems much easier to handle independently of other components of
the OS than the NetBSD libc.

Wonder how big effort would be needed to adjust musl to be compilable
against the NetBSD native syscalls? Unlike Linux, *BSD kernels do not
promise the stability of the syscall interface, but in practice the
default compatibility level covers many kernel versions and looks almost
as stable as in Linux.

(Linux-ABI-only musl would probably always remain "slightly insufficient"
for using with OS-specific tools, when the OS is not Linux - as there
are syscalls which reflect the internals of the kernel and they hardly
can ever become represented via a foreign ABI)

How much in musl is fundamentally linux-specific, besides the low level
syscall interfacing? How feasible would it be to introduce multiple
"kernel flavour" targets?

Rune

Re: musl on a different syscall layer?

[Rich Felker]

On Wed, Sep 17, 2014 at 04:57:58PM +0200, u-wsnj@aetey.se wrote:
> An observation, NetBSD libc file looks about 50% bigger than musl
> being used (via Linux ABI) on the same system.
> 
> I am also kind of put off by the NetBSD monolithic build environment,
> musl seems much easier to handle independently of other components of
> the OS than the NetBSD libc.
> 
> Wonder how big effort would be needed to adjust musl to be compilable
> against the NetBSD native syscalls? Unlike Linux, *BSD kernels do not
> promise the stability of the syscall interface, but in practice the
> default compatibility level covers many kernel versions and looks almost
> as stable as in Linux.
> 
> (Linux-ABI-only musl would probably always remain "slightly insufficient"
> for using with OS-specific tools, when the OS is not Linux - as there
> are syscalls which reflect the internals of the kernel and they hardly
> can ever become represented via a foreign ABI)
> 
> How much in musl is fundamentally linux-specific, besides the low level
> syscall interfacing? How feasible would it be to introduce multiple
> "kernel flavour" targets?

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.

Rich

Re: musl on a different syscall layer?

[u-wsnj]

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

Thanks Rich.

Rune

Re: musl on a different syscall layer?

[Justin Cormack]

On Wed, Sep 17, 2014 at 7:02 PM,  <u-wsnj@aetey.se> 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 (justin@netbsd.org)

Re: musl on a different syscall layer?

[Alexander Revin]

> On Wed, Sep 17, 2014 at 7:02 PM,  <u-wsnj@...ey.se> 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 (justin@...bsd.org)

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.

Best,
Alex