[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160229213057.GE9349@brightrain.aerifal.cx>
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.
