Subject: PSARC-EXT FastTrack [09/05/2006]: libcmd must die
Template Version: @(#)sac_nextcase %I% %G% SMI
This information is Sun Proprietary: Need-to-Know
1. Introduction
1.1. Project/Component Working Name:
libcmd must die
1.2. Name of Document Author/Supplier:
Author: Joseph Kowalski
1.3 Date of This Document:
28 September, 2006
4. Technical Description
Title: libcmd must die
Case Number: PSARC/2006/XXX
Submitter: Joseph Kowalski
Sponsor: Joseph Kowalski
Date: September 28th, 2006
libcmd must die....
Long live libcmd!
Background and Summary
======================
Solaris has long contained the Private library libcmd containing a small
set of routines (referred to as the def*() functions) designed for parsing
NAME=VALUE pairs as are expected in /etc/default files. The exact taxonomy
of these routines is unknown, but it is some form of Private. Non-Solaris
Sun products have latched on to these routines making them effectively
Sun Private and there is reason to suspect that third party products may
also be (inappropriately) using them.
The community reference sources for ksh (1993) also contains a libcmd and
an OpenSolaris based project wishes to integrate ksh (1993). The historical
nature of the Solaris libcmd and the desire for upstream compatibility with
the reference ksh community makes simply changing the name of either library
distasteful. (See PSARC/2006/550 for discussion and detailed rationale as
to why the name is significant.)
This project removes the existing Solaris libcmd, clearing the way for the
ksh (1993) libcmd, which will require only trivial modification. Also, an
official interface taxonomy level is established for the def* routines.
Project Details
===============
The following steps will be taken:
1) The contents of the existing libcmd will be moved to libc and
there be labeled as SUNW_private.
2) All references to libcmd (-lcmd) will be removed from the ON
consolidation. It is only required that they be removed from
eight utilities in /sbin which may be used before /usr is mounted
but maintaining sanitary conditions in ON strongly suggests that
they all be removed. (As the sign says, "State law and common
decency require that ...".)
3) Remove the existing libcmd from the product.
4) Integrate the new ksh (1993) libcmd into the product. It is
required to filter the def*() functions to libc.[1]
The taxonomy level of the existing def*() routines is Sun Private.
Although this level is generally considered intractable, it correctly
reflects reality in this instance. Ideally, these would be Consolidation
Private.[2]
Note that this commitment level should not be considered a blanket
endorsement of these routines. In the case of system services, SMF
is the clearly preferred solution and /etc/default files should not
be created. The usage is less clear for an arbitrary application. (Again,
see PSARC/2006/550 for discussion.) This should not be a problem because
analysis of usage should be triggered by the proposal of the /etc/default
file itself as an interface.
This project explicitly requests permission to integrate as multiple
putbacks. Steps 1) and 2) are allowed to integrate separately from
the subsequent steps. Steps 3) and 4) must happen monolithically and
logically as part of the ksh (1993) putback. It seems unreasonable to
burden an OpenSolaris originated project with steps 1) and 2), particularly
as some instances of -lcmd may be in closed source.
Exported Interfaces
===================
Interface Level Comments
def*() functions Sun Private Reality bites.
Errata
======
[1] It might seem that the filter entries are not required (and for
a brief period I held that hope). After all, in general the
existing utilities need to find something called libcmd and they
need to find the def*() routines (which they will in libc). They
don't need to find the def*() routines in libcmd. However, in
the case of -B direct linker bindings, they do need to find the
def*() in something called libcmd.
[2] In the discussion of PSARC/2006/550, it was suggested that the
def*() routines be made Public (and to be of use, Committed).
As has been said before, that's not this case. However, note
that this case makes that action as simple as the generation of
man pages and a quick edit of the libc mapfile.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack