[lsb-discuss] New Interfaces for 3.2/4.0

Nick Stoughton 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
more specific.

If you don't know all the options or just want to get an impression of
the current mess, look at

http://people.redhat.com/drepper/posix-option-groups.html

plain text document attachment (posix-opt-v7)
Options to be made mandatory in POSIX:


_POSIX_ASYNCHRONOUS_IO:

  Useful and can be implemented at userlevel.  No reason to not demand it.


_POSIX_BARRIERS:

  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.


_POSIX_MAPPED_FILES:

  Indispensable nowadays.  Every system striving for POSIX compliance
  probably has it.  This does not include systems using subprofiles.

_POSIX_MEMORY_PROTECTION:

  Similar to _POSIX_MMAPED_FILES.


_POSIX_READER_WRITER_LOCKS:

  Often required, should be possible to implement if mutexes can be
  implemented.


_POSIX_REALTIME_SIGNALS:

  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.


_POSIX_SEMAPHORES:

  Simple to implement and these are the only sync primitives which can
  be used in signal handlers (sem_post).


_POSIX_SPIN_LOCKS:

  Very easy to implement, even the inter-process version.  The code is
  also small so no need to shy away from supporting it.


_POSIX_SYNCHRONIZED_IO:

  Supported everywhere and essential to write well-performing and safe
  programs.


_POSIX_THREAD_ATTR_STACKSIZE:

  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
  reliable programs.


_POSIX_THREAD_SAFE_FUNCTIONS:

  Several of these functions are needed in multi-threaded code, if only
  for performance reasons.


_POSIX_THREADS:

  Make threads mandatory.  They are one of the main reasons people adhere
  to POSIX.


_POSIX_TIMEOUTS:

  These interfaces are really needed all the time in serious thread
  programming.


_XOPEN_ENH_I18N

  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:

_POSIX_SPORADIC_SERVER

  There is no general acceptance of this option.


_POSIX_THREAD_SPORADIC_SERVER

  See above


_POSIX_TRACE
_POSIX_TRACE_EVENT_FILTER
_POSIX_TRACE_INHERIT
_POSIX_TRACE_LOG

  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
  as abandoned.


_XOPEN_LEGACY

  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
  option.


_XOPEN_STREAMS:

  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
  is portable.




More information about the lsb-discuss mailing list