[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120908221449.GZ27715@brightrain.aerifal.cx>
Date: Sat, 8 Sep 2012 18:14:49 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: capset() capget() syscalls
On Sat, Sep 08, 2012 at 05:02:35PM +0100, Justin Cormack wrote:
> On Fri, Sep 7, 2012 at 5:56 AM, Rich Felker <dalias@...ifal.cx> wrote:
> > On Thu, Sep 06, 2012 at 09:22:58AM +0100, Justin Cormack wrote:
> >> For reference (this list is not complete), Musl is missing the
> >
> > Would you be willing to complete this list and submit a patch to add
> > all the missing syscalls?
> >
>
> OK stage 1, I have gone through all the syscalls (on x64) to work out
> what is missing. As people have been going and adding them there are
> now not that many that should definitely be in.
>
> missing and should definitely be in:
> accept4
> acct
> dup3
> ppoll
> preadv
> pwritev
> recvmmsg
> setdomainname
> setns
> syncfs
Agreed. Most of them are trivial to add, but acct may be problematic
unless we also add the ugly header with the struct definitions for
on-disk representation of process accounting info. Otherwise, programs
might assume it exists since acct exists and break when it doesn't.
Also, recvmmsg will require the same ugly kernel bug workarounds as
revcmsg requires, on 64-bit targets. Since there's not just one msghdr
to fix up, but a whole list of them, there may not be temporary
storage available for all of them. I think it might be easier/cleaner
to just unconditionally call recvmsg in a loop in this case,
implementing the MSG_WAITFORONE logic in userspace if possible. Of
course this eliminates all the performance advantages of recvmmsg on
64-bit machines. I think we really need to get the kernel folks to fix
the underlying bugs, and then we can make the workarounds conditional
on kernel version...
> missing but fairly specialist (or not useful), not sure if some should
> be exposed, not all in glibc (some are very new):
> create_module
Deprecated, part of the ancient (2.2? 2.0?) kernel module interface, I
think...
> exit_group
This is actually the syscall for the exit function. The syscall named
"exit" is the syscall for the pthread_exit function. It's confusing.
> futex
glibc does not expose this as far as I know. I would not be opposed to
having sys/futex.h however. It's less ugly than having to use
linux/futex.h and syscall()...
> get_kernel_syms
Probably deprecated..?
> clock_adjtime
Modern, should be exposed.
> get_thread_area
Largely useless, and intended only for use in implementing pthreads.
> io_cancel, io_destroy, io_getevents, io_setup, io_submit (ie native
> Linux aio not posix aio)
Is there any legitimate user of this horrible API? Last I checked
these functions were only useful for block-aligned IO on block devices
and the impression I got was that they were designed solely for
Oracle's use. (puke) I suppose they could be useful for FUSE drivers
too, however. We can add them if they have legitimate software that
needs them.
> kexec_load
Useful, especially for certain embedded systems.
> lookup_dcookie
> migrate_pages
> mincore
Not sure about these; possibly useful.
> modify_ldt
Probably useful for dosemu or something...
> mqgetsetattr (used internally to provide mq interfaces)
Indeed; we already use it there.
> name_to_handle_at
> nfsservctl
> open_by_handle_at
Useful for userspace nfsd, maybe other similar things.
> perf_event_open
> getcpu
> personality
Not sure about these.
> process_vm_readv
> process_vm_writev
These are supported.
> query_module
Almost surely deprecated.
> quotactl
> remap_file_pages
Probably useful. Don't know details.
> sched_setaffinity, sched_getaffinity (note glibc uses different
> interface to syscalls)
Useful, I think, but we should provide the libc api, not the low-level
syscall api.
> sendmmsg (probably should be in but no man page on my box)
Same issue as recvmmsg. Very useful but likely buggy.
> set_robust_list
> set_thread_area
> set_tid_address
Only meaningful to the pthreads implementation, and already used
internally there. Any direct use of these by an application is likely
to cause dangerous breakage of implementation internals.
> sigaltstack
Already used.
> restart_syscall
This is a kernel implementation detail related to signal handling and
avoiding EINTR.
> tgkill
Used internally in pthread. Not sure if it's useful to provide to apps
too..
> obsolete or unimplemented in Linux
> [...]
Agree.
> unknown (eg no man page on my box, probably obsolete or should not be
> exported, but check)
> afs_syscall
> arch_prctl
> get_robust_list
arch_prctl is used internally for threads on x86_64. The others seem
useless.
> syscall differs in prototype etc (probably missing some of these):
> clone
We provide clone.
> only exposed as weak alias:
> getdents
> vfork
There's no "only" to it; the reason it's weak is so that we can use
the namespace-safe __-prefixed names for these functions without
polluting the external namespace.
> These are in libkeyutils even though they are syscalls:
> add_key
> request_key
> keyctl
Not even sure what they're for. But I don't think they're a priority
if glibc does not even have them internally.
> These are in libnuma, even though they are syscalls
> move_pages
> mbind
> get_mempolicy
> set_mempolicy
Same.
> naming differences (including 64), ignore this list:
> fadvise64 is posix_fadvise
> fstat
> fstatat, newfstatat
> lstat
> signalfd4
> syslog is klogctl
Indeed, these can be ignored.
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.
