[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Sep 2012 11:28:04 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: capset() capget() syscalls
* Justin Cormack <justin@...cialbusservice.com> [2012-09-06 09:22:58 +0100]:
> WIth glibc I cannot seem to find a set of headers to include that will
> give me access to all the system calls plus the types and constants
> needed to call them. There are always conflicts. I am hoping I will be
> able to with Musl.
>
so these are functions not present in any standard and any libc
why do you want to include them in musl?
that would mean applications will break using glibc vs musl
why not use a separate library (libcap2)
> I don't see it can be deprecated if it has not been replaced... it is
> one of the syscalls not generally intended for everyday use. But it is
> a bit unclear.
>
this is the question
and we need an authorative answer
> For reference (this list is not complete), Musl is missing the
> following syscalls that glibc has:
> fallocate, acct, setns, sync_file_range, readahead, tee,
> timerfd_create, timerfd_settime, timerfd_gettime
>
these are non-standard functions, but the non-broken
ones should be provided eventually
the ugly ones are those which glibc declares in standard
headers (eg readahead, tee)
(timerfd* functions are easy to provide as they live in
their own header)
some of them might be obsolete
(eg posix_fallocate is in musl and can be used instead
of fallocate, and posix_fadvise may be used instead of
readahead)
> And neither provide the non obsolete
> clock_getres, clock_settime, clock_gettime
>
these are posix standard api and musl provides them
if the necessary feature test macros are defined when
time.h is included
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.
