> X-Original-To: ksh93-integration-discuss at opensolaris.org
> Delivered-To: ksh93-integration-discuss at opensolaris.org
> Date: Fri, 22 Sep 2006 12:03:20 -1000 (HST)
> From: Joseph Kowalski <Joseph.Kowalski at eng.sun.com>
> Subject: Re: Re: [ksh93-integration-discuss] Re: [osol-arc] Korn Shell 93
Integration [PSARC-EXT/2006/550 Timeout:09/27/2006]
> To: Joseph.Kowalski at eng.sun.com, james.d.carlson at sun.com
> MIME-Version: 1.0
> Content-MD5: XNfz4wZp02AhSUs89Njc+g==
> Cc: ksh93-integration-discuss at opensolaris.org, don.cragun at sun.com,
PSARC-EXT at sac.sfbay.sun.com
> X-BeenThere: ksh93-integration-discuss at opensolaris.org
> X-Mailman-Version: 2.1.4
> List-Id: Korn Shell 93 integration/migration project discussion
<ksh93-integration-discuss.opensolaris.org>
> List-Unsubscribe:
<http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss>,
<mailto:ksh93-integration-discuss-request at
opensolaris.org?subject=unsubscribe>
> List-Archive:
<http://mail.opensolaris.org/pipermail/ksh93-integration-discuss>
> List-Post: <mailto:ksh93-integration-discuss at opensolaris.org>
> List-Help:
<mailto:ksh93-integration-discuss-request at opensolaris.org?subject=help>
> List-Subscribe:
<http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss>,
<mailto:ksh93-integration-discuss-request at opensolaris.org?subject=subscribe>
>
>
> > From: James Carlson <james.d.carlson at sun.com>
> ...
> > If we know that there are no programs outside of the project team's
> > ken that will want to link to this library (if it really is some
> > flavor of Private), then that'll work fine.
> >
> > Unfortunately, we've gotten varying answers on this: that there aren't
> > any, that there might be some, that we're not sure.
> >
> > I think we need to know whether this new libcmd.so needs to be Public
> > (a documented system interface), and if it is, whether it makes any
> > real difference if the linking procedures are (perhaps) different on
> > Solaris than on other platforms.
>
> I *think* if finally figured this out. Those 40 other commands are
> the 40 file system equivalents of the builtins.
>
> Obviously, at the current time, our file system equivalents don't do
> this.
>
> They probably should. This is a nice architecture which keeps the
> builtin and the file system equivalent in sync. As has been so often
> said, that's a different case.
>
> That said, I don't see a reason that *either* libcmd should become
> Public.
>
> The one associated with ksh, should be Project Private in this case
> and promoted to Consolidation Private if and when we start to implement
> the above architecture.
>
> The one associated with historical Solaris, should just stay officially
> Consolidation Private even if as April has discovered, it is defacto
> Sun Private.
Since the historical libcmd interfaces were never assigned an interface
taxonomy level, this case makes that explicit by naming the existing
libcmd and def*() interfaces as "Sun Private". Would it really be appropriate
to list them as "Consolidation Private", which presumably indicates to
the next project that modifies them, that it would be safe to do so
without considering any consumers outside of the ON consolidation?
Note that libcmd currently has many consumers in other consolidations,
including unbundled products.
April
>
> Hence, we should just rename the libcmd associated with ksh on Solaris.
> A fork from the reference community (ie: David Korn)? Yes, but an
> exceptionally minor one.
>
> - jek3
>
> _______________________________________________
> ksh93-integration-discuss mailing list
> ksh93-integration-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
