[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 1 Aug 2015 03:32:08 +0000 (UTC)
From: Brad Conroy <technosaurus@...oo.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: Re: Using direct socket syscalls on x86_32 where
available?
> On Fri, Jul 31, 2015 at 11:13:54PM +0000, Brad Conroy wrote:
> > On 29 July 2015 at 19:32, Andy Lutomirski <luto@...capital.net> wrote:
> > > On Wed, Jul 29, 2015 at 5:51 AM, Justin Cormack
> > > <justin@...cialbusservice.com> wrote:
> > >> On 28 July 2015 at 08:44, Alexander Larsson <alexander.larsson@...il.com> wrote:
> > >>> On Tue, Jul 28, 2015 at 1:56 AM, Andy Lutomirski <luto@...capital.net> wrote:
> > >>>>
> > >>>> One way to implement it would be to favor the new syscalls but to set some
> > >>>> variable the first time one of them returns ENOSYS. Once that happens,
> > >>>> either all of them could fall back to socketcall or just that one syscall
> > >>>> could.
> >
> >
> > I've had (DRY) concerns over including a copy of unistd.h for each arch.
> > If musl used system linux include headers, this could be an ifdef.
> >
> > #include <linux/unistd.h>
> > #ifdef __NR_something
> > //use syscall
> > #else
> > //use socketcall
> > #endif
>
> I don't follow. This is roughly what we do and it does not solve the
> problem because it assumes that the choice is constant for a given
> arch, whereas the proposal is adding alternative syscalls that are
> conditionally available dependent on kernel version. Supporting this
> would require more complex logic for which to use and runtime fallback
> code.
>
> Rich
AFAICT musl uses its own arch specific __NR_* definitions
http://git.musl-libc.org/cgit/musl/tree/arch/i386/bits/syscall.h
http://git.musl-libc.org/cgit/musl/tree/arch/arm/bits/syscall.h
etc...
If you replace those with <linux/unistd.h>, you will get the same defs
except that:
if the sytem kernel is newer you will have additional syscalls
if the kernel is older you won't have some that are needed for functions
Using system definitions will ensure the system supports the defined syscalls.
This will provide an automatic path for future architectures to do the same.
It looks like the current method allows musl to be built with syscalls that
may not even be supported by the (older) system kernel and then try to make
non-existent syscalls during runtime (rfkill comes to mind)
- R,
Brad Conroy
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.
