From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4945 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Changes for no-legacy-syscalls archs Date: Mon, 21 Apr 2014 20:03:21 -0400 Message-ID: <20140422000321.GK26358@brightrain.aerifal.cx> References: <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 1398125052 5494 80.91.229.3 (22 Apr 2014 00:04:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Apr 2014 00:04:12 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4949-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 22 02:04:04 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 1WcOBv-000232-SJ for gllmg-musl@plane.gmane.org; Tue, 22 Apr 2014 02:04:03 +0200 Original-Received: (qmail 23746 invoked by uid 550); 22 Apr 2014 00:04:03 -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 23672 invoked from network); 22 Apr 2014 00:03:33 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:4945 Archived-At: On Mon, Apr 21, 2014 at 06:38:12PM -0500, Josiah Worcester wrote: > On Mon, Apr 21, 2014 at 6:13 PM, Rich Felker wrote: > > > 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. > > > > The complete list of variants missing from new ports can be seen in > include/uapi/asm-generic/unistd.h in the kernel tree, under the > __ARCH_WANT_SYSCALL_NO_AT, __ARCH_WANT_SYSCALL_NO_FLAGS, and > __ARCH_WANT_SYSCALL_DEPRECATED #ifdefs. As far as I'm aware this should > apply to all future Linux archs, as the current Linux development policy is > to use arch-generic constants for anything new, rather than the crazy > approach of matching some old API. Thanks. I'll check these. > > 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. > > > > > I rather like this approach to doing the syscalls, as it does make it > notably easier to port musl to environments where the numeric syscall > dispatch function is not very nice. However, I would think it'd be > preferable to switch to this for all the system calls rather than just have > a single sys_open macro. So, for the minimally-invasive approach, I feel > that just doing the #ifdef in the two places it's needed is nicer > (particularly as it doesn't restrict you from switching to the sys_* macros > in the future). Indeed; also switching to the "bare-metal-friendly" system would require a way to make both cancellable and non-cancellable variants of the syscall. However the change is not just #ifdef in two places. It's #ifdef in two places, plus changing all other uses to call an external function __open or similar, which would require either finding a place to put a prototype for it, or duplicating the prototype all over the place (which is error-prone). This is why I kinda like the syscall.h solution anyway: it provides a nice place to put the prototype or macro definition, and we can use a macro rather than an external function and avoid one of the ifdefs (the "__init_security" one that's now in __init_libc since I flattened some code). Basically, the syscall.h approach is both easier/simpler and closer to what we might want to do in the long term. That's why I kinda lean towards it. Rich