Date: Sun, 2 Sep 2012 13:02:20 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Syscall cleanup? Hi all, I just committed the inline/__inline patch resolving the issue with syscall.h, but I'd like to reconsider some issues with syscall.h. The whole inline issue arose from having inline asm for syscalls that gets exposed in the public syscall.h header. To me this seems both gratuitously incompatible with non-GNUC compilers, and gratuitously dependent on the __syscall_ret function in musl which was never really intended to be exposed as a public interface. What I'd like to consider doing is: 1. Have the public syscall.h only expose __NR_* and SYS_* macros and the variadic long syscall(long, ...) function, possibly even eliminating the remapping of legacy syscalls to their 64-bit variants, etc. 2. To achieve this, keeping only the syscall number definitions in bits/syscall.h and moving the __SYSCALL_LL_* macros and inline syscall functions to an internal arch-specific header, and if we want to remove the legacy/64-bit remapping from the public header, putting this remapping in the private arch-level header. I think this approach is arguably cleaner (but some people might disagree), and would probably stand up better against applications doing stupid things (like assuming syscall() is a function rather than a variadic macro). Opinions? 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.