[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140525114515.GX507@brightrain.aerifal.cx>
Date: Sun, 25 May 2014 07:45:15 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [UGLY PATCH] Support for no-legacy-syscalls archs
On Sun, May 25, 2014 at 11:52:57AM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2014-05-25 01:42:37 -0400]:
> > Here's a proposed next phase for supporting no-legacy-syscall archs
> > (aarch64 and or1k, among others). It's not complete but I think it
> > covers most of the important syscalls for standard functionality (not
> > linux-specific stuff tho). Some of them might be missing some error
> > cases or otherwise buggy so I'm sending the patch for review before
> > committing.
> ....
> > +#ifdef SYS_poll
> > __syscall(SYS_poll, pfd, 3, 0);
> > +#else
> > + __syscall(SYS_ppoll, pfd, 3, 0, 0, _NSIG/8);
> > +#endif
>
> cant it be done the other way around so new syscalls
> are tried and then the classic ones are just fallbacks?
The "legacy" (I like the word "classic" better here, actually)
syscalls are actually preferred when available. Not only is there the
natural small amount of bloat decrease (fewer args, less chance of
having to shuffle the stack and spill registers in the caller, etc.),
and the consideration that using the new syscalls by default would
require fallback code for the ENOSYS case, but in some cases emulating
the behavior of the simpler function with the "general purpose"
syscall is actually expensive and error-prone.
I thought getpgid was an example of this (see the patch, which uses 4
syscalls instead of 1 to avoid a race reading the pid then using it,
which can race with fork from a signal handler) but it turned out an
argument of 0 to the syscall yields the getpgrp behavior, so I'm
updating that aspect of the patch.
An example that can't be optimized away is dup2, where special logic
is needed to deal with the case that dup3 treats differently. BTW,
the use of dup2 in posix_spawn also needs attention; I'm fixing it
now but the fix is rather ugly.
> and what will happen with SYS_open?
Already committed what seems to be the least invasive at both the
source and binary level. See the commit message; other approaches had
me worried that it might be too easy to break things (e.g. posix_spawn
where the child is sharing memory with the parent and thus can't touch
errno, cancellation state, etc.).
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.
