From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4943 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Changes for no-legacy-syscalls archs Date: Mon, 21 Apr 2014 19:13:32 -0400 Message-ID: <20140421231332.GA7115@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 1398122037 2383 80.91.229.3 (21 Apr 2014 23:13:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Apr 2014 23:13:57 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4947-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 22 01:13:51 2014 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 1WcNPF-00009f-H2 for gllmg-musl@plane.gmane.org; Tue, 22 Apr 2014 01:13:45 +0200 Original-Received: (qmail 32116 invoked by uid 550); 21 Apr 2014 23:13:44 -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 32108 invoked from network); 21 Apr 2014 23:13:44 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:4943 Archived-At: Based on reports from the in-progress aarch64 port, at least the following syscalls musl uses internally in several places are missing on "new" archs: - open - stat - pipe I'm actually surprised it way so few, but I think that's indicative that our test coverage is insufficient; all of the syscalls with "at" variants or 2/3/4 variants (pipe/dup/accept) should be problems. Anyway, as far as I can tell, of the above three, "open" is the only one used as an inline syscall in multiple places across the source. The others (stat and pipe) are just used via calls to the public function, so any changes needed can be made in just one place. For open, of the 8 uses, 3-4 are in places that need to be namespace-protected (so we can't just call the open function, and anyway it's a cancellation point which is problematic) and one, __init_security, is in a place that's size-critical (linked in all static programs) so we don't want to add a function call there anyway. The rest of the call points are all largish functions where the inline syscall is not making a significant difference to size. So, for all instances except __init_security and open itself, I think it would make sense to call an external __open function. This would also be a nice place to tuck away the O_LARGEFILE flag, rather than having all calling code be aware of it. We could then just add two additional, mildly-ugly #ifdef SYS_open checks to __init_security.c and open.c and be done with it (open itself is special because it has to make a cancellable syscall). Alternatively, instead of the external function __open, we could define a macro __open, or sys_open, or similar, in internal/syscall.h and have it expand to either an inline syscall to SYS_open or SYS_openat depending on whether SYS_open is defined. This would avoid any size increase and would also avoid having an #ifdef in __init_security. The second solution might be preferable; eventually, we could transition to having most/all syscalls be made via sys_* function-like macros in syscall.h, which would facilitate porting to bare-metal without implementing a huge numeric syscall dispatch function like what's in the kernel. Rich