2011-09-09 05:07:38 +00:00
|
|
|
#ifndef _AIO_H
|
|
|
|
|
#define _AIO_H
|
|
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
|
extern "C" {
|
|
|
|
|
#endif
|
|
|
|
|
|
2012-09-08 03:13:55 +00:00
|
|
|
#include <features.h>
|
2011-09-09 05:07:38 +00:00
|
|
|
#include <signal.h>
|
|
|
|
|
#include <time.h>
|
|
|
|
|
|
|
|
|
|
#define __NEED_ssize_t
|
|
|
|
|
#define __NEED_off_t
|
|
|
|
|
|
|
|
|
|
#include <bits/alltypes.h>
|
|
|
|
|
|
|
|
|
|
struct aiocb {
|
2011-09-28 15:36:11 +00:00
|
|
|
int aio_fildes, aio_lio_opcode, aio_reqprio;
|
2011-09-09 05:07:38 +00:00
|
|
|
volatile void *aio_buf;
|
|
|
|
|
size_t aio_nbytes;
|
|
|
|
|
struct sigevent aio_sigevent;
|
|
|
|
|
void *__td;
|
|
|
|
|
int __lock[2];
|
make all objects used with atomic operations volatile
the memory model we use internally for atomics permits plain loads of
values which may be subject to concurrent modification without
requiring that a special load function be used. since a compiler is
free to make transformations that alter the number of loads or the way
in which loads are performed, the compiler is theoretically free to
break this usage. the most obvious concern is with atomic cas
constructs: something of the form tmp=*p;a_cas(p,tmp,f(tmp)); could be
transformed to a_cas(p,*p,f(*p)); where the latter is intended to show
multiple loads of *p whose resulting values might fail to be equal;
this would break the atomicity of the whole operation. but even more
fundamental breakage is possible.
with the changes being made now, objects that may be modified by
atomics are modeled as volatile, and the atomic operations performed
on them by other threads are modeled as asynchronous stores by
hardware which happens to be acting on the request of another thread.
such modeling of course does not itself address memory synchronization
between cores/cpus, but that aspect was already handled. this all
seems less than ideal, but it's the best we can do without mandating a
C11 compiler and using the C11 model for atomics.
in the case of pthread_once_t, the ABI type of the underlying object
is not volatile-qualified. so we are assuming that accessing the
object through a volatile-qualified lvalue via casts yields volatile
access semantics. the language of the C standard is somewhat unclear
on this matter, but this is an assumption the linux kernel also makes,
and seems to be the correct interpretation of the standard.
2015-03-04 03:50:02 +00:00
|
|
|
volatile int __err;
|
2011-09-09 05:07:38 +00:00
|
|
|
ssize_t __ret;
|
|
|
|
|
off_t aio_offset;
|
|
|
|
|
void *__next, *__prev;
|
|
|
|
|
char __dummy4[32-2*sizeof(void *)];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define AIO_CANCELED 0
|
|
|
|
|
#define AIO_NOTCANCELED 1
|
|
|
|
|
#define AIO_ALLDONE 2
|
|
|
|
|
|
|
|
|
|
#define LIO_READ 0
|
|
|
|
|
#define LIO_WRITE 1
|
|
|
|
|
#define LIO_NOP 2
|
|
|
|
|
|
|
|
|
|
#define LIO_WAIT 0
|
|
|
|
|
#define LIO_NOWAIT 1
|
|
|
|
|
|
2011-09-14 01:21:53 +00:00
|
|
|
int aio_read(struct aiocb *);
|
|
|
|
|
int aio_write(struct aiocb *);
|
2011-09-14 01:09:35 +00:00
|
|
|
int aio_error(const struct aiocb *);
|
2011-09-09 05:07:38 +00:00
|
|
|
ssize_t aio_return(struct aiocb *);
|
|
|
|
|
int aio_cancel(int, struct aiocb *);
|
2011-09-14 01:09:35 +00:00
|
|
|
int aio_suspend(const struct aiocb *const [], int, const struct timespec *);
|
2011-09-09 05:07:38 +00:00
|
|
|
int aio_fsync(int, struct aiocb *);
|
|
|
|
|
|
2012-09-07 02:44:55 +00:00
|
|
|
int lio_listio(int, struct aiocb *__restrict const *__restrict, int, struct sigevent *__restrict);
|
2011-09-09 05:07:38 +00:00
|
|
|
|
2022-09-27 19:04:05 +00:00
|
|
|
#if defined(_LARGEFILE64_SOURCE)
|
2012-05-04 04:13:23 +00:00
|
|
|
#define aiocb64 aiocb
|
|
|
|
|
#define aio_read64 aio_read
|
|
|
|
|
#define aio_write64 aio_write
|
|
|
|
|
#define aio_error64 aio_error
|
|
|
|
|
#define aio_return64 aio_return
|
|
|
|
|
#define aio_cancel64 aio_cancel
|
|
|
|
|
#define aio_suspend64 aio_suspend
|
|
|
|
|
#define aio_fsync64 aio_fsync
|
2012-07-19 04:37:43 +00:00
|
|
|
#define lio_listio64 lio_listio
|
2012-05-04 04:13:23 +00:00
|
|
|
#define off64_t off_t
|
|
|
|
|
#endif
|
|
|
|
|
|
add time64 symbol name redirects to public headers, under arch control
a _REDIR_TIME64 macro is introduced, which the arch's alltypes.h is
expected to define, to control redirection of symbol names for
interfaces that involve time_t and derived types. this ensures that
object files will only be linked to libc interfaces matching the ABI
whose headers they were compiled against.
along with time32 compat shims, which will be introduced separately,
the redirection also makes it possible for a single libc (static or
shared) to be used with object files produced with either the old
(32-bit time_t) headers or the new ones after 64-bit time_t switchover
takes place. mixing of such object files (or shared libraries) in the
same program will also be possible, but must be done with care; ABI
between libc and a consumer of the libc interfaces is guaranteed to
match by the the symbol name redirection, but pairwise ABI between
consumers of libc that define interfaces between each other in terms
of time_t is not guaranteed to match.
this change adds a dependency on an additional "GNU C" feature to the
public headers for existing 32-bit archs, which is generally
undesirable; however, the feature is one which glibc has depended on
for a long time, and thus which any viable alternative compiler is
going to need to provide. 64-bit archs are not affected, nor will
future 32-bit archs be, regardless of whether they are "new" on the
kernel side (e.g. riscv32) or just newly-added (e.g. a new sparc or
xtensa port). the same applies to newly-added ABIs for existing
machine-level archs.
2019-07-31 19:24:58 +00:00
|
|
|
#if _REDIR_TIME64
|
|
|
|
|
__REDIR(aio_suspend, __aio_suspend_time64);
|
|
|
|
|
#endif
|
|
|
|
|
|
2011-09-09 05:07:38 +00:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#endif
|