From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9418 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] add sched_getcpu Date: Mon, 29 Feb 2016 16:30:58 -0500 Message-ID: <20160229213057.GE9349@brightrain.aerifal.cx> References: <1456764572-18648-1-git-send-email-nathan@nathan7.eu> <1456780194.12169.25.camel@xiaoka.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1456781475 20338 80.91.229.3 (29 Feb 2016 21:31:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Feb 2016 21:31:15 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9431-gllmg-musl=m.gmane.org@lists.openwall.com Mon Feb 29 22:31:14 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aaVPM-0007Aa-8n for gllmg-musl@m.gmane.org; Mon, 29 Feb 2016 22:31:12 +0100 Original-Received: (qmail 5624 invoked by uid 550); 29 Feb 2016 21:31:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5604 invoked from network); 29 Feb 2016 21:31:10 -0000 Content-Disposition: inline In-Reply-To: <1456780194.12169.25.camel@xiaoka.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9418 Archived-At: On Mon, Feb 29, 2016 at 10:09:54PM +0100, Tomasz Sterna wrote: > W dniu 29.02.2016, pon o godzinie 17∶49 +0100, użytkownik Nathan Zadoks > napisał: > > This is a GNU extension, but a fairly minor one, for a system call > > that otherwise has no libc wrapper. > > Does it need a libc wrapper? > Calling it using syscall() seems pretty straightforward. If getting sufficient performance for it to be practically useful ends up dependent on vdso, then calling it via syscall() is not useful at all. > There are a lot of Linux specific syscalls without libc wrappers. > Is this one special enough? I wouldn't say there are a lot; do you have a list? The topic of what should and should not be given libc wrappers has been under discussion on the glibc list for a while now. There's been some strong opposition to exposing new things, even useful ones, if they're clearly "Linux-specific", but my position has been that libc is justified in exposing anything that can reasonably be used by applications without making assumptions about libc internals. This means things like set_thread_area, set_tid_address, set_robust_list, brk, possibly gettid, etc. are not appropriate to expose, but other things could be. You should not need to use syscall() to access any Linux functionality that's meant to be exposed to applications; syscall() has nasty quirks that vary by arch (like alignment of 64-bit argument slots, argument passing on x32 and similar ILP32-on-64 ABIs, etc.) that applications should never have to be aware of. Rich