Re: [PATCH] add sched_getcpu

[Rich Felker <dalias@libc.org>]

On Tue, Mar 01, 2016 at 09:35:21PM +0100, Tomasz Sterna wrote:
> W dniu 29.02.2016, pon o godzinie 16∶30 -0500, użytkownik Rich Felker
> napisał:
> > 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?
> 
> $ grep -roh 'syscall(SYS_[a-z]*' src/kits/kernel/ | sort -u
> syscall(SYS_exit

SYS_exit cannot be used safely unless you have a single-threaded
program, and in that case you can use _exit (SYS_exit_group).

> syscall(SYS_futex

There's work on getting glibc to expose futex, but I want to ensure
that we do it in a compatible (in terms of types used, and where the
declaration and macros get defined) way, so I'm waiting til we reach
consensus on that to take any action in musl.

> syscall(SYS_gettid

For glibc it's been controversial whether to expose tids as a public
API, since it pokes through the pthread abstraction and imposes a 1:1
threads implementation. My view is that, unless you want to write a
gigantic framework emulating each blocking syscall in userspace, POSIX
already imposes a 1:1 threads implementation, and it's stupid to still
pretend that M:N is viable.

> syscall(SYS_tgkill

tgkill also requires tids to be exposed an potentially has other
issues, and doesn't seem to offer anything that pthread_kill doesn't.

> >  The topic of what should and should not be given libc wrappers has
> > been under discussion on the glibc list for a while now. [...]
> > You should not need to use syscall() to access any Linux
> > functionality that's meant to be exposed to applications; [...]
> 
> Really depends on how you define "applications".

I mean syscalls that are intended for writing application programs
rather than for implementing the userspace part of C/POSIX.

> Basically why I asked the question - if the above should also be
> wrapped, I am all for it. But if not, why some syscalls are special?

I hope I've answered this to some extent. If not please elaborate on
what specific things aren't clear.

Rich