From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1807 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Syscall cleanup? Date: Sun, 2 Sep 2012 13:02:20 -0400 Message-ID: <20120902170220.GD27715@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1346605211 32118 80.91.229.3 (2 Sep 2012 17:00:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 2 Sep 2012 17:00:11 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1808-gllmg-musl=m.gmane.org@lists.openwall.com Sun Sep 02 19:00:13 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1T8DWt-00020I-SC for gllmg-musl@plane.gmane.org; Sun, 02 Sep 2012 19:00:12 +0200 Original-Received: (qmail 12143 invoked by uid 550); 2 Sep 2012 17:00:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 12135 invoked from network); 2 Sep 2012 17:00:08 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1807 Archived-At: 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