[lsb-discuss] New Interfaces for 3.2/4.0
Wichmann, Mats D
mats.d.wichmann at intel.com
Tue Aug 1 20:16:44 PDT 2006
>However, if POSIX does go ahead with this proposal, then the following
>interfaces should be actively considered for either 3.2 or 4.0:
>
>+--------------------------------+---------+
>| Iname | Istatus |
>+--------------------------------+---------+
>| aio_cancel | Defered |
>| aio_cancel64 | Defered |
>| aio_error | Defered |
>| aio_error64 | Defered |
>| aio_fsync | Defered |
>| aio_fsync64 | Defered |
>| aio_read | Defered |
>| aio_read64 | Defered |
>| aio_return | Defered |
>| aio_return64 | Defered |
>| aio_suspend | Defered |
>| aio_suspend64 | Defered |
>| aio_write | Defered |
>| aio_write64 | Defered |
>| pthread_barrier_destroy | Defered |
>| pthread_barrier_init | Defered |
>| pthread_barrier_wait | Defered |
>| pthread_barrierattr_destroy | Defered |
>| pthread_barrierattr_getpshared | Defered |
>| pthread_barrierattr_init | Defered |
>| pthread_barrierattr_setpshared | Defered |
>| pthread_spin_destroy | Defered |
>| pthread_spin_init | Defered |
>| pthread_spin_lock | Defered |
>| pthread_spin_trylock | Defered |
>| pthread_spin_unlock | Defered |
Based on my understanding of the level of support
in our target systems, the barrier and spinlock
thread stuff could be ready now. The aio stuff,
as you know, awaits a resolution of the dilemma
that exists today:
- userspace aio, in glibc, isn't full enough POSIX
conforming for ISVs to want it (or so the small
number that have weighed in have told us; and
it didn't pass the one testsuite we had available)
- kernel-level aio doesn't implement the POSIX
API/ABI (although I keep hearing there's a project
by Bull and others to wrap the ABI in the POSIX
set)
It may be that the former isn't really a problem
any more, it's hard to tell without revisiting
the issue. It *used* to be that opinions ran
pretty strong on that. Time may have changed it.
More information about the lsb-discuss
mailing list