Date: Mon, 29 Feb 2016 16:30:58 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH] add sched_getcpu 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
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.