[lsb-discuss] New Interfaces for 3.2/4.0
nick at usenix.org
Tue Aug 1 17:29:07 PDT 2006
As you probably know by know, in the same timeframe as 4.0, POSIX is
being revised again. This revision process occurs approximately every 5
years (1988, 1990, 1995, 2003, 2008).
One of the things that is being considered in the revision process is
the changing of optional behavior into mandatory behavior. There are
several interfaces we currently have either deferred or excluded that
fall into these options groups that may now become mandatory. Attached
is an initial proposal from Ulrich Drepper (glibc maintainer) to the
Austin Group for cleaning up options in POSIX. This is for information
only ... the Austin Group have yet to discuss this paper.
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 |
-------- Forwarded Message --------
From: Ulrich Drepper <drepper at redhat.com>
To: austin-group-l at opengroup.org
Subject: Reducing the option mess
Date: Sat, 01 Jul 2006 09:23:55 -0700
At the plenary meeting in Ottawa we agreed to reduce the options POSIX
provides today as much as possible. This means merging options,
removing options by making the functionality mandatory, marking options
obsolete so that they can be removed in a later revisions.
The following is a first proposal I volunteered to come up with. I
think we should be pretty hard on the requirement to _keep_ an option.
Use options only when really necessary.
Note, that making functionality mandatory has no negative impact on the
sub-profiling efforts. Subprofiles can also remove mandatory
functionality. So in the worst case the subprofiles have to be a bit
If you don't know all the options or just want to get an impression of
the current mess, look at
plain text document attachment (posix-opt-v7)
Options to be made mandatory in POSIX:
Useful and can be implemented at userlevel. No reason to not demand it.
Barriers are simple to implement. The code is small, the functionality
useful. There is no reason to make this optional. The pshared attribute
is another thing.
Indispensable nowadays. Every system striving for POSIX compliance
probably has it. This does not include systems using subprofiles.
Similar to _POSIX_MMAPED_FILES.
Often required, should be possible to implement if mutexes can be
The limitations of the old-style signals almost force many programs
to use RT signals. They are old enough for people to have gained
sufficient experience implementing them.
Simple to implement and these are the only sync primitives which can
be used in signal handlers (sem_post).
Very easy to implement, even the inter-process version. The code is
also small so no need to shy away from supporting it.
Supported everywhere and essential to write well-performing and safe
If default stacks are too small, this is the only portable way to size them
appropriately. If the size is too large the implementation can decide to
ignore the hints and allocate the stack normally. It should, to not waste
memory and address space, but it could. So, this option is necessary for
Several of these functions are needed in multi-threaded code, if only
for performance reasons.
Make threads mandatory. They are one of the main reasons people adhere
These interfaces are really needed all the time in serious thread
Add the nl_langinfo() functions to the base. The functionality is
needed frequently, e.g., to determine the currently used encoding.
I do not suggest adding catopen/catclose/catgets.
Options to be obsoleted:
There is no general acceptance of this option.
No serious uptake and the authors have not been respinsive at all when
it came to fixing problems in the spec. One could regard the option
I'm not sure whether we can already remove the interfaces. They
certainly should go as soon as possible. If none is left remove the
IMO this option should go. The developer community spoke, STREAMS lost.
They continue to be used on some platforms but it's no interface which
More information about the lsb-discuss