Newsgroups: comp.std.unix
Path: bga.com!news.sprintlink.net!howland.reston.ans.net!gatech!bloom-beacon.mit.edu!
cambridge-news.cygnus.com!news.cygnus.com!sef
From: n...@usenix.org (Nicholas M. Stoughton)
Subject: Standards Update, POSIX.1: System Interface
Message-ID: < D0tBtH.Fz8@cygnus.com>
Sender: s...@cygnus.com (Sean Eric Fagan)
Reply-To: std-u...@uunet.uu.net
X-Submissions: std-u...@uunet.uu.net
Organization: USENIX Standards Report Editor
Date: Wed, 14 Dec 1994 17:03:01 GMT
Approved: s...@cygnus.com (Moderator, Sean Eric Fagan)
Lines: 199
Submitted-by: n...@usenix.org (Nicholas M. Stoughton)
USENIX Standards Report Editor
Nicholas M. Stoughton < n...@usenix.org>, Report Editor
POSIX.1: System Interface
Shravan Pargal < par...@sdiv.cray.com> reports on the October
17-21, 1994 meeting in Seattle, WA.:
A newcomer's view to POSIX, and the work of POSIX.1
This was my first POSIX meeting. Given this fact, my
perspective on the proceedings of the meetings attended
should be viewed with a large pinch of salt. This report is
not necessarily factually accurate or binding in any way.
The POSIX.1 working group (WG) was small, with 4 seniors and
2 freshmen (including me) present the first day. Both of us
freshmen were accepted warmly, so there were two less
freshmen on the last day of the meeting. The WG was now
growing ... proof of life and success!!
The Seattle WG meeting was dominated by outstanding
interpretations and ballot issues on Draft 11 of the
POSIX.1a ballot. While other issues were discussed, the
ballot status and issues surrounding Checkpoint/Restart
seemed to keep resurfacing. Issues discussed during the week
included:
1. Trailing Slashes
2. Application conformance
3. Optional environment functions like _w_a_l_k_e_n_v(),
fIsavenv(), _a_n_d _f_I_l_o_a_d_e_n_v()
4. Checkpoint/Restart
5. Removable Media Study Group
Summary
Trailing slashes.
The problem with the current standard is that it is unclear
in the definition of pathname in the case that the pathname
contains one or more trailing slashes.
It was decided that this is really a problem with the
definition of ``pathname resolution'', and not with trailing
slashes in particular. Thus the solution lay in clarifying
the definition of ``pathname resolution''.
- 2 -
A proposal was put forth to tighten the requirement on
pathnames ending in trailing slashes to allow them only in
the case of existing directories - the behavior of BSD based
systems. The definition of pathname resolution will now
include something like the following:
``A pathname that ends with one or more trailing slashes
shall be interpreted as if it ended with slash-dot,
except that the slash-dot does not count in {PATH_MAX}
calculations.''
Application conformance.
Two points were proposed here. First the need for an
additional definition to be added to POSIX.1 from C language
- a definition that would allow for an application to
conform to both POSIX.1 and to ISO 9899 C. The second was a
plea for consistency in the wording of definitions in the
different POSIX standards - at least those that relate to
conformance issues.
The additional definition was that of a ``Rigorously
Conforming POSIX.1 C Application''. This is defined as an
application that requires the services and facilities only
described in ISO/IEC 9945-1 and ISO/IEC 9899. Furthermore,
with regard to the use of the C language, it shall not
produce output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not exceed any
minimum implementation limits; as defined in ISO 9899.
The second point was about consistency in wording referred
at least in part to the difference in the definitions of
Strictly Conforming POSIX.1 and POSIX.2 Applications.
The language above was taken from the ``Application
conformance issues'' paper by Derek Jones of Knowledge
Software. This is not a complete definition of the
``Rigorously Conforming POSIX.1 C Application''. The
complete definition can be got directly from the paper.
Optional environment functions
There was a discussion of the environmental functions
(_x_x_x_e_n_v()) in POSIX.1a. The WG felt that such functions were
probably useful in threaded environments, and should thus
probably be optional. There was some discussion about
_w_a_l_k_e_n_v() actually making things worse for threaded
environments. The final decision was to discuss at the next
meeting if the functions should be optional and if there
could be an alternative function to _w_a_l_k_e_n_v() that would be
thread-safe. [_S_u_b_s_e_q_u_e_n_t _t_e_l_e_p_h_o_n_e _m_e_e_t_i_n_g_s _o_f _t_h_e _W_G _h_a_v_e
- 3 -
_d_e_c_i_d_e_d _t_o _r_e_m_o_v_e _t_h_e_s_e _c_o_n_t_e_n_t_i_o_u_s _f_u_n_c_t_i_o_n_s _f_r_o_m _t_h_e _n_e_x_t
_d_r_a_f_t _o_f _P_O_S_I_X._1_a, - _E_d]
Checkpoint/Restart
There was a joint meeting with the Fault Tolerant (SRASS)
group and the Super Computing Profile (POSIX.10) groups
about checkpoint/restart. There are still a lot of
conflicting goals for this. The POSIX.1 WG would like to see
a useful minimal interface specification, something that can
be implemented and used by a reasonable set of applications.
The SRASS group would like to see the name changed from
checkpoint/restart to something like "batch services", since
the functions do not go far enough for there particular
needs, and were invented originally within the batch
profile.
The POSIX.1 WG would like to see a common name agreeable to
all groups. It will oppose the possibility of two similar
but different interfaces coming into existence for
checkpoint/restart.
Removable Media Study Group
This group discussed issued associated with tapes (generally
true for any removable media) and work supporting it might
proceed. They expect to submit a Project Authorization
Request (PAR) in January describing the scope and goals of
the group.
The next meeting is in sunny Ft. Lauderdale FL, January 15-
21, 1995. I enjoyed the last meeting enough to be planning
on going to Fort Lauderdale (well, it is Florida in January
...), perhaps you should think about coming too?
Volume-Number: Volume 35, Number 16
|