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.