star, rmt, and librmt [PSARC/2008/176 FastTrack timeout 03/12/2008]
James Carlson
james.d.carlson at sun.com
Tue Mar 11 13:04:27 PDT 2008
Joseph Kowalski writes:
> Joerg Schilling wrote:
> > James Carlson <james.d.carlson at sun.com> wrote:
> >
> >
> > Why do you believe you made a mistake?
> >
> > The ksh93 discussion was very long and I really don't like to repeat it.
> >
> > Jörg
> >
> I know this was a reply to Jim, but my answer is "I don't know". I will
> need to
> review it *before* commenting on the follow-up case you seem to be planning.
There are at least three classes of users:
- Those in the same consolidation. They don't need to have headers
in a shipping package at all; they can just refer to the
consolidation's proto area or directly to the source.
- Those in some other OpenSolaris consolidation. They need a
package to be installed on the build machine, but don't need a
package that ships in the final product. It'd just be bloatware.
- Those outside of OpenSolaris itself. They need a public package
that gets included in one of the metaclusters. Most likely the
"developer" one, but possibly just SUNWCall.
The ksh93 folks have convinced me that the set in that third class is
not zero, because of the ksh93 plug-in interface. If you write
extensions to ksh93, then you need the library and some of the
headers.
I would have called it a mistake to include libast and headers in the
final product *if* that third class didn't exist. There's no point in
shipping things that nobody uses.
I see no equivalent case for libschily. Does anyone anywhere actually
write to that rather than writing to libc and, if so, who and why?
That's what needs to be presented -- probably as part of some other
case that promotes a higher (public) stability level for this library,
and not as part of this case.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
More information about the opensolaris-arc
mailing list