[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 25 May 2014 10:57:50 +0100
From: Justin Cormack <justin@...cialbusservice.com>
To: musl@...ts.openwall.com
Subject: Re: [UGLY PATCH] Support for no-legacy-syscalls archs
On Sun, May 25, 2014 at 10:52 AM, Szabolcs Nagy <nsz@...t70.net> 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?
Issue seems to be that if you were running an old kernel (say no
ppoll) this would have to be called twice or add runtime conditionals,
which would be slower. Also it means that strace shows closer to what
you called. In many cases (where the new ones are Posix and portable)
users should switch to the new calls, but some are Linux only.
> and what will happen with SYS_open?
Whats the issue with open?
Justin
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.
