From sacadmin Thu Sep 28 21:42:03 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8T4g3mf024982; Thu, 28 Sep 2006 21:42:03 -0700 (PDT) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k8T4g37g979779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Sep 2006 21:42:03 -0700 (PDT) Received: (from jek3@localhost) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8/Submit) id k8T4g2a2979775; Thu, 28 Sep 2006 21:42:02 -0700 (PDT) Date: Thu, 28 Sep 2006 21:42:02 -0700 (PDT) From: Joseph Kowalski Message-Id: <200609290442.k8T4g2a2979775@jurassic.eng.sun.com> To: PSARC-EXT@sac.sfbay.sun.com Cc: roland.mainz@nrubsig.org Subject: libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] Status: RO Content-Length: 4558 Subject: PSARC-EXT FastTrack [09/05/2006]: libcmd must die Template Version: @(#)sac_nextcase %I% %G% SMI This information Copyright 2006 Sun Microsystems 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 From sacadmin Thu Sep 28 22:04:09 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8T549qm025504 for ; Thu, 28 Sep 2006 22:04:09 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k8T542oY984779; Thu, 28 Sep 2006 22:04:08 -0700 (PDT) Message-Id: <200609290504.k8T542oY984779@jurassic.eng.sun.com> Date: Thu, 28 Sep 2006 19:03:51 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] To: PSARC-EXT@sac.sfbay.sun.com, ksh93-integration-discuss@opensolaris.org Cc: roland.mainz@nrubsig.or, don.cragun@sun.com, April.Chin@eng.sun.com, roger.faulkner@sun.com, Rod.Evans@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vyYNkXROWU3kOETwn+NOCA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 5146 Please ignore what appears to be another initial posting of this case automatically generated by the tools. It will only be seen by some of you. I'm sponsoring this case for myself. It is the proposed resolution of the libcmd collision issue associated with PSARC/2006/550. Note, that dispite the fact this discussion was characterized as "dumb", the resolution is so simple as to almost qualify for "Closed Approved Automatic". The only reasons I believe it doesn't is that it actually established an interface taxonomy level for the def*() routines and proposes to be allowed to integrate as two separate integrations rather than the single integration standard applied to all ARC cases. For those unfamiliar with "Closed Approved Automatic", it is for cases where the implementation follows well defined practices used be previous projects and the case is strictly to record the name space implications. Its best that this type of submission only be used by ARC Professionals (do not attempt this at home). This case times out on Thursday, October 5th, 2006. - jek3 Title: libcmd must die Case Number: PSARC/2006/561 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. Release Binding =============== Minor. 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. From sacadmin Fri Sep 29 08:07:17 2006 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8TF7GKg005733 for ; Fri, 29 Sep 2006 08:07:17 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8TF7D5Z012988; Fri, 29 Sep 2006 11:07:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k8TF7DYt018458; Fri, 29 Sep 2006 11:07:13 -0400 (EDT) Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] From: Bill Sommerfeld To: Joseph Kowalski , Korn Shell 93 integration/migration project discussion Cc: PSARC-EXT@sac.sfbay.sun.com, Rod.Evans@sun.com, roger.faulkner@sun.com, don.cragun@sun.com, roland.mainz@nrubsig.or In-Reply-To: <200609290504.k8T542oY984779@jurassic.eng.sun.com> References: <200609290504.k8T542oY984779@jurassic.eng.sun.com> Content-Type: text/plain Date: Fri, 29 Sep 2006 11:07:13 -0400 Message-Id: <1159542433.16677.12.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1000 On Thu, 2006-09-28 at 19:03 -1000, Joseph Kowalski wrote: > 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. What's the state of libcmd after part (1) delivers? is there a reduced husk of a libcmd which acts only as a filter to libc for the def*() functions it formerly implemented, or is it left intact with a second copy of the functions? Unless all four parts are delivering together, it seems like it would be better to deliver the filter-only library as part of part (1); part (4) would conceptually add the ksh93-delivered libcmd to the empty husk, and part (3) (atomically part of part 4) would essentially disappear. From sacadmin Fri Sep 29 10:45:25 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8THjPoC010316 for ; Fri, 29 Sep 2006 10:45:25 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k8THjIZX304331; Fri, 29 Sep 2006 10:45:23 -0700 (PDT) Message-Id: <200609291745.k8THjIZX304331@jurassic.eng.sun.com> Date: Fri, 29 Sep 2006 07:45:05 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] To: Joseph.Kowalski@eng.sun.com, ksh93-integration-discuss@opensolaris.org, sommerfeld@sun.com Cc: PSARC-EXT@sac.sfbay.sun.com, Rod.Evans@sun.com, roger.faulkner@sun.com, don.cragun@sun.com, roland.mainz@nrubsig.or MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +5b+i32r2tKXQ8cm5veu2w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 2042 > Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] > From: Bill Sommerfeld > To: Joseph Kowalski , Korn Shell 93 integration/migration project discussion > Cc: PSARC-EXT@sac.sfbay.sun.com, Rod.Evans@sun.com, roger.faulkner@sun.com, don.cragun@sun.com, roland.mainz@nrubsig.or > Date: Fri, 29 Sep 2006 11:07:13 -0400 > Mime-Version: 1.0 > Content-Transfer-Encoding: 7bit > > On Thu, 2006-09-28 at 19:03 -1000, Joseph Kowalski wrote: > > 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. > > What's the state of libcmd after part (1) delivers? is there a reduced > husk of a libcmd which acts only as a filter to libc for the def*() > functions it formerly implemented, or is it left intact with a second > copy of the functions? The state of libcmd after part (1) isn't specified, because it doesn't matter. It could be simply untouched or it could be the minimal filter you suggest. Is there any architecure associated with this? > Unless all four parts are delivering together, it seems like it would be > better to deliver the filter-only library as part of part (1); part (4) > would conceptually add the ksh93-delivered libcmd to the empty husk, and > part (3) (atomically part of part 4) would essentially disappear. Kinda, The filter in part (1) would be in /lib, part (4) would also have to move it to /usr/lib. Unless you feel there is real architecture here, let's take this discussion off line. If anything comes from that, we can post the summary back to these broad aliases. - cheers, - jek3 From sacadmin Fri Sep 29 11:44:08 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.38]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8TIi8P4012761 for ; Fri, 29 Sep 2006 11:44:08 -0700 (PDT) Received: from aragon (aragon.SFBay.Sun.COM [129.146.226.123]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k8TIi7vf325929; Fri, 29 Sep 2006 11:44:07 -0700 (PDT) Message-Id: <200609291844.k8TIi7vf325929@jurassic.eng.sun.com> Date: Fri, 29 Sep 2006 11:37:11 -0700 (PDT) From: April Chin Reply-To: April Chin Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] To: Joseph.Kowalski@eng.sun.com, ksh93-integration-discuss@opensolaris.org Cc: don.cragun@sun.com, roger.faulkner@sun.com, Rod.Evans@sun.com, PSARC-EXT@sac.sfbay.sun.com, roland.mainz@nrubsig.or MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: dMa9D/RR/CimImWKVQ6U9Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_31 SunOS 5.11 sun4u sparc Status: RO Content-Length: 4318 > X-Original-To: ksh93-integration-discuss@opensolaris.org > Delivered-To: ksh93-integration-discuss@opensolaris.org > Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] > From: Bill Sommerfeld > To: Joseph Kowalski , Korn Shell 93 integration/migration project discussion > Date: Fri, 29 Sep 2006 11:07:13 -0400 > Mime-Version: 1.0 > Content-Transfer-Encoding: 7bit > Cc: don.cragun@sun.com, roger.faulkner@sun.com, Rod.Evans@sun.com, PSARC-EXT@sac.sfbay.sun.com, roland.mainz@nrubsig.or > X-BeenThere: ksh93-integration-discuss@opensolaris.org > X-Mailman-Version: 2.1.4 > List-Id: Korn Shell 93 integration/migration project discussion > List-Unsubscribe: , > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > > On Thu, 2006-09-28 at 19:03 -1000, Joseph Kowalski wrote: > > 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. > > What's the state of libcmd after part (1) delivers? is there a reduced > husk of a libcmd which acts only as a filter to libc for the def*() > functions it formerly implemented, or is it left intact with a second > copy of the functions? > > Unless all four parts are delivering together, it seems like it would be > better to deliver the filter-only library as part of part (1); part (4) > would conceptually add the ksh93-delivered libcmd to the empty husk, and > part (3) (atomically part of part 4) would essentially disappear. > > > If PSARC-EXT/2006/561 specifies that the existing libcmd files be removed, per step (3), the following files would be removed: /lib/libcmd.so /lib/libcmd.so.1 /lib/{amd64,sparcv9}/libcmd.so /lib/{amd64,sparcv9}/libcmd.so.1 /usr/lib/libcmd.so /usr/lib/libcmd.so.1 /usr/lib/{amd64,sparcv9}/libcmd.so /usr/lib/{amd64,sparcv9}/libcmd.so.1 There is a pending update to the spec for PSARC-EXT/2006/550 which assumes that the ksh93 integration case will deliver only the new AT&T b_*() interfaces to an empty, existing libcmd. Well, the current version of the spec assumes this as well but isn't as clear on this point. These new interfaces are Project Private, so if PSARC-EXT/2006/550 needs to specify adding the libcmd library also, it should also be Project Private. If so, it would only be appropriate to add the libraries /usr/lib/libcmd.so.1 /usr/lib/{amd64,sparcv9}/libcmd.so.1 and no compilation environment name (libcmd.so), as recommended in the Best Practices doc on Libraries and Shared Objects Requirements: http://opensolaris.org/os/community/arc/policies/libraries/ Note that the removal of libcmd.so would be a problem for unbundled or non-ON applications which attempt to compile with -lcmd. Within ON, we're removing -lcmd (ksh93 will be able to compile by finding libcmd.so in the ON proto area). So yes, I would prefer that PSARC-EXT/2006/561 removed the def*() interfaces and leave a libcmd husk. If PSARC-EXT/2006/561 also moves this libcmd husk from /lib to /usr/lib (the real binaries live in /lib currently, with symlinks from /usr/lib), that would be fine for PSARC-EXT/2006/550 but not required. Thanks, April > > > _______________________________________________ > ksh93-integration-discuss mailing list > ksh93-integration-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss From sacadmin Fri Sep 29 12:04:59 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.55]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8TJ4xof013821 for ; Fri, 29 Sep 2006 12:04:59 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k8TJ4q5d334493; Fri, 29 Sep 2006 12:04:57 -0700 (PDT) Message-Id: <200609291904.k8TJ4q5d334493@jurassic.eng.sun.com> Date: Fri, 29 Sep 2006 09:04:39 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] To: Joseph.Kowalski@eng.sun.com, ksh93-integration-discuss@opensolaris.org, April.Chin@eng.sun.com Cc: don.cragun@sun.com, roger.faulkner@sun.com, Rod.Evans@sun.com, PSARC-EXT@sac.sfbay.sun.com, roland.mainz@nrubsig.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: by93unn9gEaBA+wa5bGkPQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 3548 > From: April Chin ... > If PSARC-EXT/2006/561 specifies that the existing libcmd files be removed, > per step (3), the following files would be removed: > /lib/libcmd.so > /lib/libcmd.so.1 > /lib/{amd64,sparcv9}/libcmd.so > /lib/{amd64,sparcv9}/libcmd.so.1 > /usr/lib/libcmd.so > /usr/lib/libcmd.so.1 > /usr/lib/{amd64,sparcv9}/libcmd.so > /usr/lib/{amd64,sparcv9}/libcmd.so.1 > > There is a pending update to the spec for PSARC-EXT/2006/550 > which assumes that the ksh93 integration case > will deliver only the new AT&T b_*() interfaces to an empty, existing libcmd. > Well, the current version of the spec assumes this as well but isn't > as clear on this point. How does it matter (as far as 550 is concerned) if it delivers the interfaces to an empty, existing libcmd or simply delivers a library? All that matters as far as 550 is concerned is the final state of the system after 550 delivers. Now, you may have valid integration/implementation concerns. If so, please just contact me directly and we can work these out. > These new interfaces are Project Private, so if PSARC-EXT/2006/550 needs to > specify adding the libcmd library also, it should also be Project Private. > If so, it would only be appropriate to add the libraries > /usr/lib/libcmd.so.1 > /usr/lib/{amd64,sparcv9}/libcmd.so.1 > and no compilation environment name (libcmd.so), as recommended in the > Best Practices doc on Libraries and Shared Objects Requirements: > http://opensolaris.org/os/community/arc/policies/libraries/ Libraries (other than the name) don't have an interface commitment level. The functions within the library each have an interface commitment level. Yes, we are violating the Best Practice by mixing taxonomy levels within a library. After all these integrations are completed most of libcmd will be project private, while the library name and filter entries will be Sun Private. Note that even if the def*() routines become Public, the filter elements remain Sun Private - the Public elements would be only by the direct to libc path. These filter entries *never* change. Also note that this mixing of commitment levels has been a property of all proposals to date. This isn't new. I perhaps should have called this out explicitly in my proposal. > Note that the removal of libcmd.so would be a problem for unbundled > or non-ON applications > which attempt to compile with -lcmd. Within ON, we're removing -lcmd > (ksh93 will be able to compile by finding libcmd.so in the ON proto area). It is only a problem if no libcmd exists. This was the deciding factor in drawing the line between the project phases. > So yes, I would prefer that PSARC-EXT/2006/561 removed the def*() interfaces > and leave a libcmd husk. If PSARC-EXT/2006/561 also moves this libcmd > husk from /lib to /usr/lib (the real binaries live in /lib currently, > with symlinks from /usr/lib), that would be fine for PSARC-EXT/2006/550 > but not required. After talking with Bill, I tend to like this suggestion also. Not for any architectural or even integration management reasons, but for testing reasons. Moving the discovery of any unforseen problems to phase 1 is a good thing (as Roland stands up and cheers!). I'll repost the proposal shortly. The final state will not be changed. Only the line between the two phases will be redrawn. (I suspect we will find that phase 2 is now empty (or more exactly, all within 550), but I want to take a few minutes to work it out and be sure. - cheers, - jek3 From sacadmin Fri Sep 29 12:43:41 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.105]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8TJhfSR014221 for ; Fri, 29 Sep 2006 12:43:41 -0700 (PDT) Received: from aragon (aragon.SFBay.Sun.COM [129.146.226.123]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k8TJhbQY346092; Fri, 29 Sep 2006 12:43:38 -0700 (PDT) Message-Id: <200609291943.k8TJhbQY346092@jurassic.eng.sun.com> Date: Fri, 29 Sep 2006 12:36:41 -0700 (PDT) From: April Chin Reply-To: April Chin Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] To: Joseph.Kowalski@eng.sun.com, ksh93-integration-discuss@opensolaris.org, April.Chin@eng.sun.com Cc: don.cragun@sun.com, roger.faulkner@sun.com, Rod.Evans@sun.com, PSARC-EXT@sac.sfbay.sun.com, roland.mainz@nrubsig.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KHK6ISyefBJLbU+vcqYEWA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_31 SunOS 5.11 sun4u sparc Status: RO Content-Length: 4374 Okay, it sounds like there is no problem here then. I just wanted to make sure what we are specifying in PSARC-EXT/2006/550 was accurate as far as this case. Thanks, April > Date: Fri, 29 Sep 2006 09:04:39 -1000 (HST) > From: Joseph Kowalski > Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] > To: Joseph.Kowalski@eng.sun.com, ksh93-integration-discuss@opensolaris.org, April.Chin@eng.sun.com > Cc: don.cragun@sun.com, roger.faulkner@sun.com, Rod.Evans@sun.com, PSARC-EXT@sac.sfbay.sun.com, roland.mainz@nrubsig.org > MIME-Version: 1.0 > Content-MD5: by93unn9gEaBA+wa5bGkPQ== > > > > From: April Chin > ... > > If PSARC-EXT/2006/561 specifies that the existing libcmd files be removed, > > per step (3), the following files would be removed: > > /lib/libcmd.so > > /lib/libcmd.so.1 > > /lib/{amd64,sparcv9}/libcmd.so > > /lib/{amd64,sparcv9}/libcmd.so.1 > > /usr/lib/libcmd.so > > /usr/lib/libcmd.so.1 > > /usr/lib/{amd64,sparcv9}/libcmd.so > > /usr/lib/{amd64,sparcv9}/libcmd.so.1 > > > > There is a pending update to the spec for PSARC-EXT/2006/550 > > which assumes that the ksh93 integration case > > will deliver only the new AT&T b_*() interfaces to an empty, existing libcmd. > > Well, the current version of the spec assumes this as well but isn't > > as clear on this point. > > How does it matter (as far as 550 is concerned) if it delivers the interfaces > to an empty, existing libcmd or simply delivers a library? All that matters > as far as 550 is concerned is the final state of the system after 550 > delivers. > > Now, you may have valid integration/implementation concerns. If so, please > just contact me directly and we can work these out. > > > These new interfaces are Project Private, so if PSARC-EXT/2006/550 needs to > > specify adding the libcmd library also, it should also be Project Private. > > If so, it would only be appropriate to add the libraries > > /usr/lib/libcmd.so.1 > > /usr/lib/{amd64,sparcv9}/libcmd.so.1 > > and no compilation environment name (libcmd.so), as recommended in the > > Best Practices doc on Libraries and Shared Objects Requirements: > > http://opensolaris.org/os/community/arc/policies/libraries/ > > Libraries (other than the name) don't have an interface commitment level. > The functions within the library each have an interface commitment level. > > Yes, we are violating the Best Practice by mixing taxonomy levels within > a library. After all these integrations are completed most of libcmd > will be project private, while the library name and filter entries will > be Sun Private. Note that even if the def*() routines become Public, > the filter elements remain Sun Private - the Public elements would be > only by the direct to libc path. These filter entries *never* change. > Also note that this mixing of commitment levels has been a property of > all proposals to date. This isn't new. > > I perhaps should have called this out explicitly in my proposal. > > > Note that the removal of libcmd.so would be a problem for unbundled > > or non-ON applications > > which attempt to compile with -lcmd. Within ON, we're removing -lcmd > > (ksh93 will be able to compile by finding libcmd.so in the ON proto area). > > It is only a problem if no libcmd exists. This was the deciding factor > in drawing the line between the project phases. > > > So yes, I would prefer that PSARC-EXT/2006/561 removed the def*() interfaces > > and leave a libcmd husk. If PSARC-EXT/2006/561 also moves this libcmd > > husk from /lib to /usr/lib (the real binaries live in /lib currently, > > with symlinks from /usr/lib), that would be fine for PSARC-EXT/2006/550 > > but not required. > > After talking with Bill, I tend to like this suggestion also. Not for > any architectural or even integration management reasons, but for testing > reasons. Moving the discovery of any unforseen problems to phase 1 is a > good thing (as Roland stands up and cheers!). > > I'll repost the proposal shortly. The final state will not be changed. > Only the line between the two phases will be redrawn. (I suspect we will > find that phase 2 is now empty (or more exactly, all within 550), but I > want to take a few minutes to work it out and be sure. > > - cheers, > > - jek3 > From sacadmin Fri Sep 29 13:04:28 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8TK4Stf014774 for ; Fri, 29 Sep 2006 13:04:28 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k8TK4Qom027529; Fri, 29 Sep 2006 15:04:26 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k8TK4Mru027528; Fri, 29 Sep 2006 15:04:22 -0500 (CDT) Date: Fri, 29 Sep 2006 15:04:22 -0500 From: Nicolas Williams To: April Chin Cc: Joseph.Kowalski@eng.sun.com, ksh93-integration-discuss@opensolaris.org, Rod.Evans@sun.com, roger.faulkner@sun.com, don.cragun@sun.com, PSARC-EXT@sac.sfbay.sun.com, roland.mainz@nrubsig.or Subject: Re: [osol-arc] Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] Message-ID: <20060929200421.GC18305@binky.Central.Sun.COM> References: <200609291844.k8TIi7vf325929@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200609291844.k8TIi7vf325929@jurassic.eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 554 I thought that's exactly what this case proposes: that the final ksh93 libcmd in Solaris will have 'filters' for the old libcmd's def*() symbols so that non-ON applications that try to find def*() in /lib/libcmd.so will transparently find them in libc. Because the def*() symbols will be moving to libc you'd think that these filters would never be needed, and they shouldn't be, but: a) if there's any non-ON applications that use direct linking to libcmd they would break without these filters, b) putting these filters there costs nothing. Nico -- From sacadmin Fri Sep 29 13:32:51 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.226.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8TKWpqV014948 for ; Fri, 29 Sep 2006 13:32:51 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k8TKWjHP359766; Fri, 29 Sep 2006 13:32:49 -0700 (PDT) Message-Id: <200609292032.k8TKWjHP359766@jurassic.eng.sun.com> Date: Fri, 29 Sep 2006 10:32:32 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: [osol-arc] Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] To: April.Chin@eng.sun.com, Nicolas.Williams@sun.com Cc: Joseph.Kowalski@eng.sun.com, ksh93-integration-discuss@opensolaris.org, Rod.Evans@sun.com, roger.faulkner@sun.com, don.cragun@sun.com, PSARC-EXT@sac.sfbay.sun.com, roland.mainz@nrubsig.or MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9h3lp+Qxc1W3SoDYVwCVhw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 689 > From: Nicolas Williams ... > I thought that's exactly what this case proposes: that the final ksh93 > libcmd in Solaris will have 'filters' for the old libcmd's def*() > symbols so that non-ON applications that try to find def*() in > /lib/libcmd.so will transparently find them in libc. > > Because the def*() symbols will be moving to libc you'd think that these > filters would never be needed, and they shouldn't be, but: a) if there's > any non-ON applications that use direct linking to libcmd they would > break without these filters, b) putting these filters there costs > nothing. As clearly outlined in Eratta in the original submission. - jek3 From sacadmin Fri Sep 29 13:37:50 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8TKboZm014970 for ; Fri, 29 Sep 2006 13:37:50 -0700 (PDT) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8TKbnHk023181; Fri, 29 Sep 2006 13:37:49 -0700 (PDT) Message-ID: <451D841D.6030900@sun.com> Date: Fri, 29 Sep 2006 13:37:49 -0700 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.5 (X11/20060731) MIME-Version: 1.0 To: Korn Shell 93 integration/migration project discussion CC: April Chin , roger.faulkner@sun.com, Rod.Evans@sun.com, roland.mainz@nrubsig.or, don.cragun@sun.com, Joseph.Kowalski@eng.sun.com, PSARC-EXT@sac.sfbay.sun.com Subject: Re: [osol-arc] Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] References: <200609291844.k8TIi7vf325929@jurassic.eng.sun.com> <20060929200421.GC18305@binky.Central.Sun.COM> In-Reply-To: <20060929200421.GC18305@binky.Central.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1021 Nicolas Williams wrote: > Because the def*() symbols will be moving to libc you'd think that these > filters would never be needed, and they shouldn't be, but: a) if there's > any non-ON applications that use direct linking to libcmd they would > break without these filters, b) putting these filters there costs > nothing. "a" is not theoretical - we know there are: elfdump -y /usr/openwin/bin/xlock | grep libcmd [23] DBL [9] libcmd.so.1 defcntl [55] DBL [9] libcmd.so.1 defread [76] DBL [9] libcmd.so.1 defopen The -lcmd will be dropped from the X makefiles sometime after this case integrates. (No sooner than 2 Nevada builds later, since X build n is build on WOS build n-2, and probably a little later than that to allow X developers to keep building & testing X even if they haven't upgraded to the absolute latest WOS build yet.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Tue Oct 3 12:49:49 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.130]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k93JnnAp008977 for ; Tue, 3 Oct 2006 12:49:49 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k93JngYX866870; Tue, 3 Oct 2006 12:49:47 -0700 (PDT) Message-Id: <200610031949.k93JngYX866870@jurassic.eng.sun.com> Date: Tue, 3 Oct 2006 09:49:22 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: [osol-arc] Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] To: ksh93-integration-discuss@opensolaris.org, rich.teer@rite-group.com Cc: April.Chin@eng.sun.com, Joseph.Kowalski@eng.sun.com, gww@eng.sun.com, roger.faulkner@sun.com, Rod.Evans@sun.com, don.cragun@sun.com, PSARC-EXT@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vJq9bEjmqoveLdsF7Xgfng== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1265 > From: Rich Teer ... > On Mon, 2 Oct 2006, Gary Winiger wrote: > > > The work going forward is to provide a unified admin interface > > without a requirement for $EDITOR as the primary answer. > > I can't be the only person who feels uneasy about this trend away > from ASCII config files. For services/daemons, I get it, but I'm > not convinced when it comes to arbitrary command line programs. > It is too reminicent of Windoze's registry... Am I the only person on the planet that doesn't hate the Windoze's registry? I actually tend to think at a high level, its a pretty good idea. They did mess up a lot of the details... Let's not start a discussion on the registry... Anyway, I too am concerned. It would be a very good idea for the project Gary referred to, to do two things: 1) Visit the ARC early. 2) Start a discussion on some OpenSolaris discussion alias. Gary, could you forward this suggestion to the team? You seem to know who they are. My concern is constructing the worlds most elaborate mouse trap. I don't think we need complicated mechanisms for arbitrary utilities. Speaking of mouse traps, remember,... The early bird gets the worm, but the second mouse gets the cheese. 8^) - jek3 From sacadmin Tue Oct 3 12:55:24 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k93JtO4C009443 for ; Tue, 3 Oct 2006 12:55:24 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k93JtGDK870031; Tue, 3 Oct 2006 12:55:22 -0700 (PDT) Message-Id: <200610031955.k93JtGDK870031@jurassic.eng.sun.com> Date: Tue, 3 Oct 2006 09:54:57 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: [osol-arc] Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] To: bart.smaalders@sun.com, Nicolas.Williams@sun.com Cc: rich.teer@rite-group.com, roger.faulkner@sun.com, Rod.Evans@sun.com, April.Chin@eng.sun.com, gww@eng.sun.com, don.cragun@sun.com, ksh93-integration-discuss@opensolaris.org, Joseph.Kowalski@eng.sun.com, PSARC-EXT@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Otd+3vKV4vMBXHw/E1eyUw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 2200 Not to pick on Nico, but its fine if we want to discuss this future evolution of a classic "not this case", but please get this off of the distribution for my pending fast-track. - thanks, - jek3 Can't resist: Note to Glenn... I'm sure "bulk update" will be a requirement for anything we accept. - jek3 > Date: Tue, 3 Oct 2006 13:52:04 -0500 > From: Nicolas Williams > To: Bart Smaalders > Cc: Rich Teer , roger.faulkner@Sun.COM, Rod.Evans@Sun.COM, April.Chin@eng.sun.com, gww@eng.sun.com, don.cragun@Sun.COM, Korn Shell 93 integration/migration project discussion , Joseph.Kowalski@eng.sun.com, PSARC-EXT@sac.sfbay.sun.com > Subject: Re: [osol-arc] Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] > Mime-Version: 1.0 > Content-Disposition: inline > User-Agent: Mutt/1.5.7i > > On Tue, Oct 03, 2006 at 10:56:21AM -0700, Bart Smaalders wrote: > > Rich Teer wrote: > > >I can't be the only person who feels uneasy about this trend away > > >from ASCII config files. For services/daemons, I get it, but I'm > > >not convinced when it comes to arbitrary command line programs. > > >It is too reminicent of Windoze's registry... > > > > > > > You mean like gnome's configuration info? > > > > The problem with ascii files to control configuration is > > editing and upgrading. Designing a robust parser to catch > > and properly report user configuration errors is often tricky > > and not done well, and trying to handle syntax changes in config > > files across upgrades, installation and un-installation of patches, > > etc, is one of the major causes of package and patch breakage > > in Solaris. > > These issues, specifically upgrade issues, don't all go away just from > using XML or what have you though. The only thing that goes away is the > need to build and maintain a special-purpose parser. > > > Configuration info needs to be owned by the app and edited by > > the app, I think. > > Yes. But CLI and, more importantly, scriptable interfaces should be > provided, not just GUI interfaces. > > Nico > -- From sacadmin Wed Oct 4 09:49:13 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.45]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k94GnC0N003804 for ; Wed, 4 Oct 2006 09:49:12 -0700 (PDT) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k94GnAlQ123536; Wed, 4 Oct 2006 09:49:10 -0700 (PDT) Message-ID: <4523E57E.6000001@Sun.COM> Date: Wed, 04 Oct 2006 09:46:54 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Mail/News 1.5 (X11/20060410) MIME-Version: 1.0 To: James Carlson CC: Rich Teer , Korn Shell 93 integration/migration project discussion , roger.faulkner@Sun.COM, Rod.Evans@Sun.COM, April.Chin@eng.sun.com, gww@eng.sun.com, don.cragun@Sun.COM, Joseph.Kowalski@eng.sun.com, PSARC-EXT@sac.sfbay.sun.com Subject: Re: [osol-arc] Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] References: <200610030550.k935ofWo001574@marduk.eng.sun.com> <4522A445.7020206@Sun.COM> <17698.44765.885349.538525@gargle.gargle.HOWL> In-Reply-To: <17698.44765.885349.538525@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2002 James Carlson wrote: > Bart Smaalders writes: >> You mean like gnome's configuration info? > > An excellent example, I think. See CR 4808196. > >> Configuration info needs to be owned by the app and edited by >> the app, I think. > > That certainly reduces the number of accurate parsers needed, but it > likely increases the difficulty of upgrade. In order to upgrade, you > need an application that can run on the oldest system to be upgraded > (as well as the current one) and parse the oldest version of the > configuration file. > > One of the attractions of plain old text files is that the upgrade > process can trust that basic text tools such as awk are present and > can run a script that we design in the future to manage that > transition. > Yes, and that upgrade process needs to be modified every time we add a new form of upgrade: diskless, zones, virtualization, .... Writing package and patch scripts is becoming more and more difficult as we add additional installation contexts.... It seems a lot more sensible to mimic what the ZFS folks do - they make the ZFS modules handle updating on-disk format, and don't expect the upgrade process to do it for them. Installation/upgrade should be about updating the files on the disk; coping w/ old/merged config files can be deferred until the new instance is up and running. If that's not the case, the config info storage should be redesigned so that is possible. > If we're talking about compiled applications instead of scripts, we > need to be compiling those _new_ applications on the oldest systems we > support so that the binaries that perform the upgrade actions will run > on the systems we want to upgrade, and thus just forget about using > new OS features. (Or, alternatively, we just abandon the concept of > LU.) > > TANSTAAFL. > Have the app handle the upgrade once it's running, ala firefox. _ Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From sacadmin Wed Oct 11 06:27:38 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BDRc0x003010 for ; Wed, 11 Oct 2006 06:27:38 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9BDRb1o022129 for ; Wed, 11 Oct 2006 06:27:38 -0700 (PDT) Received: from relay13.sun.com (relay13.sun.com [217.140.40.54] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9BDRawj015471 for ; Wed, 11 Oct 2006 07:27:37 -0600 (MDT) Received: from mms13es.sun.com ([160.41.223.54] [160.41.223.54]) by relay13.sun.com with ESMTP for PSARC-EXT@sac.sfbay.sun.com; Wed, 11 Oct 2006 13:27:36 Z Received: from relay12.sun.com (relay12.sun.com [217.140.40.34]) by mms13es.sun.com with ESMTP for PSARC-EXT@sac.sfbay.sun.com; Wed, 11 Oct 2006 13:27:34 Z Received: from ug-out-1314.google.com ([66.249.92.173] [66.249.92.173]) by relay12.sun.com with ESMTP for PSARC-EXT@sac.sfbay.sun.com; Wed, 11 Oct 2006 13:10:34 Z Received: by ug-out-1314.google.com with SMTP id 72so92286ugd for ; Wed, 11 Oct 2006 06:09:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Bj/UEukcZaBsklzawIFJW1irqjVRWhtHp/V8pkpENGOp/pHp21VnMlZYlwdu1pXjPjFNggupjoz0V6r166HLE+5UCDjhTX0xxuWQYufMYU39Oad6i+C7rzw1dwQUV+SIfvXoez7ntNRze5Kkd4EFq1Qw9ZXstFYaXQyifgkg8LU= Received: by 10.78.204.1 with SMTP id b1mr727617hug; Wed, 11 Oct 2006 06:09:07 -0700 (PDT) Received: by 10.78.155.4 with HTTP; Wed, 11 Oct 2006 06:09:07 -0700 (PDT) Message-Id: Date: Wed, 11 Oct 2006 15:09:07 +0200 From: "I. Szczesniak" To: "Joseph Kowalski" , "Korn Shell 93 integration/migration project discussion" Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] Cc: PSARC-EXT@sac.sfbay.sun.com, Rod.Evans@sun.com, roger.faulkner@sun.com, don.cragun@sun.com, roland.mainz@nrubsig.or In-Reply-To: <200609290504.k8T542oY984779@jurassic.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200609290504.k8T542oY984779@jurassic.eng.sun.com> Status: RO Content-Length: 1212 On 9/29/06, Joseph Kowalski wrote: > > Please ignore what appears to be another initial posting of this case > automatically generated by the tools. It will only be seen by some of > you. > > I'm sponsoring this case for myself. It is the proposed resolution of > the libcmd collision issue associated with PSARC/2006/550. > > Note, that dispite the fact this discussion was characterized as "dumb", > the resolution is so simple as to almost qualify for "Closed Approved > Automatic". The only reasons I believe it doesn't is that it actually > established an interface taxonomy level for the def*() routines and > proposes to be allowed to integrate as two separate integrations rather > than the single integration standard applied to all ARC cases. > > For those unfamiliar with "Closed Approved Automatic", it is for cases > where the implementation follows well defined practices used be previous > projects and the case is strictly to record the name space implications. > Its best that this type of submission only be used by ARC Professionals > (do not attempt this at home). > > This case times out on Thursday, October 5th, 2006. Was this case approved or not? Irek From sacadmin Wed Oct 11 14:32:35 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.31]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BLWZ3u019873 for ; Wed, 11 Oct 2006 14:32:35 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9BLWUqn127958; Wed, 11 Oct 2006 14:32:33 -0700 (PDT) Message-Id: <200610112132.k9BLWUqn127958@jurassic.eng.sun.com> Date: Wed, 11 Oct 2006 11:31:48 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] To: Joseph.Kowalski@eng.sun.com, ksh93-integration-discuss@opensolaris.org, iszczesniak@gmail.com Cc: PSARC-EXT@sac.sfbay.sun.com, Rod.Evans@sun.com, roger.faulkner@sun.com, don.cragun@sun.com, roland.mainz@nrubsig.or MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: F6fCpLr3YeLAlneF6elGhA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 2447 It was approved. (The delivery was slightly broadened and the phasing removed in the final, approved spec., but the end state is the same.) We are implementing as we speak. - cheers, - jek3 > Date: Wed, 11 Oct 2006 15:09:07 +0200 > From: "I. Szczesniak" > Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] > To: Joseph Kowalski , Korn Shell 93 integration/migration project discussion > Cc: PSARC-EXT@sac.sfbay.sun.com, Rod.Evans@sun.com, roger.faulkner@sun.com, don.cragun@sun.com, roland.mainz@nrubsig.or > MIME-version: 1.0 > Content-transfer-encoding: 7BIT > Content-disposition: inline > DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-t ype:content-transfer-encoding:content-disposition:references; b=Bj/UEukcZaBsklzawIFJW1irqjVRWhtHp/V8pkpENGOp/pHp21VnMlZYlwdu1pXjPjFNggupjoz0V6 r166HLE+5UCDjhTX0xxuWQYufMYU39Oad6i+C7rzw1dwQUV+SIfvXoez7ntNRze5Kkd4EFq1Qw9ZXstF YaXQyifgkg8LU= > X-PMX-Version: 5.2.0.264296 > > On 9/29/06, Joseph Kowalski wrote: > > > > Please ignore what appears to be another initial posting of this case > > automatically generated by the tools. It will only be seen by some of > > you. > > > > I'm sponsoring this case for myself. It is the proposed resolution of > > the libcmd collision issue associated with PSARC/2006/550. > > > > Note, that dispite the fact this discussion was characterized as "dumb", > > the resolution is so simple as to almost qualify for "Closed Approved > > Automatic". The only reasons I believe it doesn't is that it actually > > established an interface taxonomy level for the def*() routines and > > proposes to be allowed to integrate as two separate integrations rather > > than the single integration standard applied to all ARC cases. > > > > For those unfamiliar with "Closed Approved Automatic", it is for cases > > where the implementation follows well defined practices used be previous > > projects and the case is strictly to record the name space implications. > > Its best that this type of submission only be used by ARC Professionals > > (do not attempt this at home). > > > > This case times out on Thursday, October 5th, 2006. > > Was this case approved or not? > > Irek From sacadmin Fri Oct 13 21:40:27 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.36]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9E4eR8t011197 for ; Fri, 13 Oct 2006 21:40:27 -0700 (PDT) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with SMTP id k9E4eHha132584; Fri, 13 Oct 2006 21:40:22 -0700 (PDT) Message-Id: <200610140440.k9E4eHha132584@jurassic.eng.sun.com> Date: Fri, 13 Oct 2006 18:39:31 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: [ksh93-integration-discuss] libcmd must die [PSARC-EXT/2006/561 Timeout: 09/05/2006] To: Joseph.Kowalski@eng.sun.com, ksh93-integration-discuss@opensolaris.org, iszczesniak@gmail.com Cc: PSARC-EXT@sac.sfbay.sun.com, Rod.Evans@sun.com, roger.faulkner@sun.com, don.cragun@sun.com, roland.mainz@nrubsig.org MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Nest_of_Mice_027_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 11002 --Nest_of_Mice_027_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5r6ZZAE6fpCT/xfdqqlxuw== The ksh integration had a dependency on PSARC/2006/561 being implemented. This was the moving of the libcmd def* routines to libc, leaving libcmd as a simple filter and removing the ON dependencies on libcmd. Roger Faulkner (whose hobby seems to be moving things to libc) graciously did the implemention and integration. Thanks Roger! This should be available in the b51 drop. The merging of the filters into the ksh:libcmd should be trivial. Call us with any problems. - Cheers! - jek3 --Nest_of_Mice_027_000 Content-Type: TEXT/plain; name=Untitled; charset=us-ascii Content-Description: Untitled Content-MD5: ip+xMQq+jdezX8k7rBj94w== Date: Fri, 13 Oct 2006 20:48:08 -0700 (PDT) From: "Roger A. Faulkner" To: onnv-gate-notify@onnv.eng.sun.com Subject: Code Manager notification (putback-to) MIME-Version: 1.0 Event: putback-to Parent workspace: /ws/onnv-gate (elpaso:/ws/onnv-gate) Child workspace: /net/train.sfbay/builds/raf/onnv-raf4 (train.sfbay:/builds/raf/onnv-raf4) User: raf Comment: PSARC 2006/561 libcmd must die 6480998 libcmd must die Files: update: usr/closed/cmd/cmd-inet/usr.lib/in.iked/Makefile update: usr/closed/cmd/fs.d/nfs/lockd/Makefile update: usr/src/Makefile.lint update: usr/src/Targetdirs update: usr/src/cmd/auths/Makefile update: usr/src/cmd/cmd-inet/usr.bin/Makefile update: usr/src/cmd/cmd-inet/usr.bin/finger.c update: usr/src/cmd/cmd-inet/usr.bin/ftp/Makefile update: usr/src/cmd/cmd-inet/usr.bin/netstat/Makefile update: usr/src/cmd/cmd-inet/usr.lib/in.mpathd/Makefile update: usr/src/cmd/cmd-inet/usr.sbin/Makefile update: usr/src/cmd/cmd-inet/usr.sbin/ifconfig/Makefile update: usr/src/cmd/cmd-inet/usr.sbin/in.telnetd.c update: usr/src/cmd/cron/Makefile update: usr/src/cmd/devfsadm/Makefile.com update: usr/src/cmd/fs.d/Makefile update: usr/src/cmd/fs.d/autofs/Makefile update: usr/src/cmd/fs.d/nfs/mount/Makefile update: usr/src/cmd/fs.d/nfs/mountd/Makefile update: usr/src/cmd/fs.d/nfs/nfsd/Makefile update: usr/src/cmd/fs.d/nfs/nfslog/Makefile update: usr/src/cmd/kbd/Makefile update: usr/src/cmd/keyserv/Makefile update: usr/src/cmd/keyserv/keyserv.c update: usr/src/cmd/login/Makefile update: usr/src/cmd/lp/cmd/lpsched/Makefile update: usr/src/cmd/mkpwdict/Makefile update: usr/src/cmd/pfexec/Makefile update: usr/src/cmd/power/Makefile update: usr/src/cmd/profiles/Makefile update: usr/src/cmd/rcm_daemon/Makefile.com update: usr/src/cmd/savecore/Makefile.com update: usr/src/cmd/ssh/sshd/Makefile update: usr/src/cmd/su/Makefile update: usr/src/cmd/sulogin/Makefile update: usr/src/cmd/tar/Makefile update: usr/src/cmd/utmpd/Makefile update: usr/src/cmd/ypcmd/yppasswd/Makefile update: usr/src/lib/Makefile update: usr/src/lib/common/inc/c_synonyms.h update: usr/src/lib/libc/amd64/Makefile update: usr/src/lib/libc/i386/Makefile.com update: usr/src/lib/libc/inc/synonyms.h update: usr/src/lib/libc/inc/tsd.h update: usr/src/lib/libc/port/gen/getgrnam_r.c update: usr/src/lib/libc/port/gen/localtime.c update: usr/src/lib/libc/port/llib-lc update: usr/src/lib/libc/port/mapfile-vers update: usr/src/lib/libc/sparc/Makefile update: usr/src/lib/libc/sparcv9/Makefile update: usr/src/lib/libcmd/Makefile.com update: usr/src/lib/libcmd/common/llib-lcmd update: usr/src/lib/libcmd/common/mapfile-vers update: usr/src/lib/libgss/Makefile.com update: usr/src/lib/libmapid/Makefile.com update: usr/src/lib/libnisdb/Makefile update: usr/src/lib/libpam/Makefile.com update: usr/src/lib/libsecdb/Makefile.com update: usr/src/lib/pam_modules/authtok_check/Makefile.com update: usr/src/lib/pam_modules/unix_account/Makefile.com update: usr/src/lib/pam_modules/unix_auth/Makefile.com update: usr/src/lib/pam_modules/unix_cred/Makefile.com update: usr/src/lib/passwdutil/Makefile.com update: usr/src/pkgdefs/SUNWarc/prototype_com update: usr/src/pkgdefs/SUNWarc/prototype_i386 update: usr/src/pkgdefs/SUNWarc/prototype_sparc update: usr/src/pkgdefs/SUNWarcr/prototype_com update: usr/src/pkgdefs/SUNWarcr/prototype_i386 update: usr/src/pkgdefs/SUNWarcr/prototype_sparc update: usr/src/pkgdefs/SUNWcsl/prototype_com update: usr/src/pkgdefs/SUNWcsl/prototype_i386 update: usr/src/pkgdefs/SUNWcsl/prototype_sparc update: usr/src/pkgdefs/SUNWcslr/prototype_com update: usr/src/pkgdefs/SUNWcslr/prototype_i386 update: usr/src/pkgdefs/SUNWcslr/prototype_sparc update: usr/src/tools/scripts/bfu.sh update: usr/src/lib/libc/port/gen/deflt.c rename from: usr/src/lib/libcmd/common/deflt.c to: usr/src/lib/libc/port/gen/deflt.c create: usr/src/lib/libcmd/common/placeholder.c Examined files: 78 Contents Summary: 1 create 77 update Names Summary: 1 renamed --Nest_of_Mice_027_000 Content-Type: TEXT/plain; name=Untitled; charset=us-ascii Content-Description: Untitled Content-MD5: k9QpJxHNhRelHd9AMdrORA== Date: Fri, 13 Oct 2006 21:51:42 -0600 (MDT) From: roger.faulkner@sun.com To: john.levon@sun.com, sriram.popuri@sun.com, Joseph.Kowalski@sun.com, roger.faulkner@sun.com, krister.johansen@sun.com, bart.smaalders@sun.com Subject: CR 6480998 Updated P3 library/libc libcmd must die Mime-Version: 1.0 Content-Transfer-Encoding: 7bit *Synopsis*: libcmd must die http://bt2ws.central.sun.com/CrPrint?id=6480998 CR 6480998 changed on Oct 14 2006 by roger.faulkner@sun.com === Field ============ === New Value ============= === Old Value ============= Fixed in Build snv_51 Status 8-Fix Available 7-Fix in Progress ====================== =========================== =========================== *Change Request ID*: 6480998 *Synopsis*: libcmd must die Product: solaris Category: library Subcategory: libc Type: RFE Subtype: Status: 8-Fix Available Substatus: Priority: 3-Medium Introduced In Release: Introduced In Build: Responsible Manager: michael.pogue@sun.com Responsible Engineer: roger.faulkner@sun.com Initial Evaluator: library-libc@piton.sfbay Keywords: === *Description* ============================================================ This CR is a place-holder for putting back the changes needed for the PSARC case: PSARC/2006/561 libcmd must die This is from the spec file in the PSARC case directory: 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. This leaves libcmd as an empty shell of a library (sorry about the pun). Add filter entries for the moved functions to this vistigial library. 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) Relocate libcmd from /lib to /usr/lib. No compatibility symbolic link will be placed into /lib. *** (#1 of 1): 2006-10-12 02:37:07 GMT+00:00 roger.faulkner@sun.com *** Last Edit: 2006-10-12 02:37:07 GMT+00:00 roger.faulkner@sun.com === *Comments* =============================================================== === *Evaluation* ============================================================= See the description and the PSARC case: PSARC/2006/561 libcmd must die *** (#1 of 1): 2006-10-12 02:39:49 GMT+00:00 roger.faulkner@sun.com *** Last Edit: 2006-10-12 02:39:49 GMT+00:00 roger.faulkner@sun.com === *Suggested Fix* ========================================================== The context diffs for the fix are too large to include here. They are contained in the attached 'diffs' file. The output of 'wx codereview' is contained in the attached postscript file, codereview.ps, for those who prefer this display mode. Also, at least temporarily, there is a webrev for the changes in: file:///net/train.sfbay/builds/raf/onnv-raf4/webrev/index.html *** (#1 of 1): 2006-10-12 05:08:35 GMT+00:00 roger.faulkner@sun.com *** Last Edit: 2006-10-12 14:23:09 GMT+00:00 roger.faulkner@sun.com === *Workaround* ============================================================= === *Justification* ========================================================== Priority changed from [] to [3-Medium] must be done before the ksh93 project can integrate. roger.faulkner@sun.com 2006-10-12 02:37:07 GMT *** (#1 of 1): 2006-10-12 02:37:07 GMT+00:00 roger.faulkner@sun.com *** Last Edit: 2006-10-12 02:37:07 GMT+00:00 roger.faulkner@sun.com === *Additional Details* ===================================================== Targeted Release: solaris_nevada Commit To Fix In Build: snv_51 Fixed In Build: snv_51 Integrated In Build: Verified In Build: See Also: Duplicate of: Hooks: Hook1: Hook2: Hook3: Hook4: Hook5: Hook6: Interest List: Joseph.Kowalski@sun.com, bart.smaalders@Sun.COM Program Management: Root Cause: Requires Security Coordination: false Fix Affects Documentation: No Fix Affects Localization: No Reported by: === *History* ================================================================ Date Submitted: 2006-10-12 02:37:00 GMT+00:00 Submitted By: roger.faulkner@sun.com Status Changed Date Updated Updated By 6-Fix Understood 2006-10-12 02:39:49 GMT+00:00 roger.faulkner@sun.com 7-Fix in Progress 2006-10-12 05:08:34 GMT+00:00 roger.faulkner@sun.com 8-Fix Available 2006-10-14 03:50:27 GMT+00:00 roger.faulkner@sun.com === *Solution* =============================================================== === *Service Request* ======================================================== ID: 1-247395805 Customer: Account Name: Sun Microsystems, Inc. Contact Role: D-Development Impact: Limited Functionality: Secondary Severity: 4 Synopsis: Product Name: solaris Product Release: solaris_nevada Product Build: Operating System: snv_50 Hardware: generic Reference Number: Sun Contact: roger.faulkner@sun.com Customer Contact: Contact Type: I-Internal (SMI) Customer Status: Open Source: BugTraq2 Reproducible: Submitted By: roger.faulkner@sun.com Submitted Date: 2006-10-12 02:37:07 GMT+00:00 Description: === *Activity* =============================================================== === *Multiple Release (MR) Cluster* - 0 ====================================== === *Escalations* ============================================================ --Nest_of_Mice_027_000--