From blu@sac.sfbay.sun.com Wed Apr 7 09:14:45 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o37GEjjV013059 for ; Wed, 7 Apr 2010 09:14:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o37GEjXA001290; Wed, 7 Apr 2010 09:14:45 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0I00G0DL4LS200@brm-avmta-1.central.sun.com>; Wed, 07 Apr 2010 10:14:45 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0I006W9L4IO760@brm-avmta-1.central.sun.com>; Wed, 07 Apr 2010 10:14:43 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o37GEgU6017537; Wed, 07 Apr 2010 09:14:42 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o37GEfSI013054; Wed, 07 Apr 2010 09:14:41 -0700 (PDT) Received: (from blu@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o37GEfdu013050; Wed, 07 Apr 2010 09:14:41 -0700 (PDT) Date: Wed, 07 Apr 2010 09:14:41 -0700 (PDT) From: Brian Utterback Subject: Move device allocation out of libbsm into libdevalloc [PSARC/2010/118 FastTrack timeout 04/14/2010] To: PSARC-ext@sun.com Cc: jan.parcel@oracle.com Message-id: <201004071614.o37GEfdu013050@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5037 I am submitting this fast track on behalf of Jan Parcel. The timer is set for April 14, 2010. The requested binding is minor. Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: Move device allocation out of libbsm into libdevalloc 1.2. Name of Document Author/Supplier: Author: Jan Parcel 1.3 Date of This Document: 07 April, 2010 4. Technical Description This is a fast track to separate device allocation out of libbsm, in Nevada only. 6908149 Create libdevalloc, get rid of problematic duplications of symbols and filenames libbsm effectively contains two unrelated libraries: one set of routines for auditing, and one for device allocation. Now that both auditing and device allocation are changing, and diverging, a build-breaking circular dependency has surfaced. This could be fixed by putting some routines into a usr/lib/common directory, but that would not solve the fact that the futures of these two subsystems are expected to continue to diverge drastically. Bottom line: these should be two different libraries, libbsm for auditing and libdevalloc for device allocation. Both libraries should be in the same packages, for simplicity and compatibility. Every manifest that shows libbsm will get identical lines made for libdevalloc, these are the affected manifest files: usr/src/pkg/manifests/SUNWcs.mf usr/src/pkg/manifests/system-library.mf usr/src/pkg/manifests/system-trusted-global-zone.mf usr/src/pkg/manifests/developer-library-lint.mf NONE of the externally-visible changes involve ARC'd public interfaces, one change involves an accidentally-public interface (getdevicerange(3TSOL)) My inquiries, tree searches, and ldd/nm/grep research strongly indicate that ALL of the affected interfaces except getdevicerange() are only used inside the ON consolidation, as far as the WOS goes. I propose to fix all of that in the same putback. usr/src/cmd/devfsadm (extensive dependencies) usr/src/cmd/allocate (extensive dependencies) usr/lib/lp/local/lpsched (getdevicerange) Some name changes were made to avoid ambiguity, such as libbsm's devinfo_t, which is different from libdevinfo's devinfo_t. Getdevicerange should be Contracted Project Private in the future. Known consumers are these programs which Stephen Browne covers: metacity tsoldtlabel (defunct soon now that dt is gone from Nevada ????) tsoljdslabel-ui Sun Ray, which is not part of the WOS, shows no sign of referencing any of the moved routines in the source tree I was shown. It is unknown what third-party programs might reference these routines, but man page correction should handle those. Past PSARC cases: PSARC/2002/142 Device Allocation Updates - by Ashish Joshi, closed withdrawn 01/09/2007 PSARC/2005/691 Trusted Extensions for Device Allocation - by Ashish Joshi, waiting need opinion 03/01/2006 PSARC/2002/762 Layered Trusted Solaris - by Glenn Faden, waiting need spec Related to: PSARC/2005/259 Layered Trusted Solaris Label Interfaces - by Gary Winiger, waiting need draft opinion 03/07/2006 PSARC/2005/573 Solaris Trusted Extensions for Printing - by Glenn Faden, closed approved 05/17/2006 FILES: Added to create a new library libdevalloc: usr/src/lib/libdevalloc/Makefile usr/src/lib/libdevalloc/Makefile.com usr/src/lib/libdevalloc/amd64/Makefile usr/src/lib/libdevalloc/common/llib-ldevalloc usr/src/lib/libdevalloc/common/mapfile-vers usr/src/lib/libdevalloc/i386/Makefile usr/src/lib/libdevalloc/sparc/Makefile usr/src/lib/libdevalloc/sparcv9/Makefile Moved from libbsm to libdevalloc with filename change: usr/src/lib/libdevalloc/common/libdevalloc.c (was devalloc.c) (There is also a devalloc.c in usr/src/cmd/devfsadm.) usr/src/lib/libdevalloc/common/dev_alloc.h (was bsm/devices.h) usr/src/lib/libdevalloc/common/devalloc_impl.h (was $ROOT: bsm/devalloc.h) Moved from libbsm to libdevalloc: usr/src/lib/libdevalloc/common/getdadefs.c usr/src/lib/libdevalloc/common/getdaent.c usr/src/lib/libdevalloc/common/getdevicerange.c usr/src/lib/libdevalloc/common/getdment.c In addition, we need to remove the long-since-defunct man getddent(3BSM), since those routines do not even exist in s10 or Nevada. And I'll file a bug to make this change to man getdevicerange(3TSOL): diff getdevicerange.man future-getdevicerange.man 12c12 < cc [flag...] file... -lbsm -ltsol [library...] --- > cc [flag...] file... -ldevalloc -ltsol [library...] 45a46 > getdevicerange() is a Private interface. 79c80 < butes: --- > butes, including Private interfaces: 86c87 < | Interface Stability | Committed | --- > | Interface Stability | Private | 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From gww@sac.sfbay.sun.com Wed Apr 7 10:57:29 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o37HvTr9017858 for ; Wed, 7 Apr 2010 10:57:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o37HvSOu024215 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 7 Apr 2010 10:57:29 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L0I00415PVSAO00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Apr 2010 11:57:28 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L0I006K0PVRO6E0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 07 Apr 2010 11:57:27 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o37HvQIO003817; Wed, 07 Apr 2010 10:57:26 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o37HvQ3Q017856; Wed, 07 Apr 2010 10:57:26 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o37HvQlK017855; Wed, 07 Apr 2010 10:57:26 -0700 (PDT) Date: Wed, 07 Apr 2010 10:57:26 -0700 (PDT) From: Gary Winiger Subject: Re: Move device allocation out of libbsm into libdevalloc [PSARC/2010/118 FastTrack timeout 04/14/2010] To: PSARC-ext@sun.com, blu@sac.sfbay.sun.com Cc: jan.parcel@oracle.com Message-id: <201004071757.o37HvQlK017855@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 675 > Bottom line: these should be two different libraries, libbsm for auditing and > libdevalloc for device allocation. Both libraries should be in the same > packages, for simplicity and compatibility. Great ;-) > NONE of the externally-visible changes involve ARC'd public interfaces, > one change involves an accidentally-public interface (getdevicerange(3TSOL)) I see no issue here; getdevicerange is scoped private in libbsm. > And I'll file a bug to make this change to man getdevicerange(3TSOL): Just remove the man page. getdevicerange is scoped private. Project Private interfaces should not have published man pages. +1 with the man page removed. Gary.. From brian.utterback@oracle.com Mon Apr 19 05:19:36 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3JCJa9G006109 for ; Mon, 19 Apr 2010 05:19:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o3JCJXSa010487 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 19 Apr 2010 06:19:35 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1400947I8NS100@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 19 Apr 2010 05:19:35 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L14007JLI8MHSE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 19 Apr 2010 05:19:34 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o3JCJTD6008469; Mon, 19 Apr 2010 12:19:29 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3JBQoa1000525; Mon, 19 Apr 2010 12:19:28 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt354.oracle.com with ESMTP id 187215261271679564; Mon, 19 Apr 2010 05:19:24 -0700 Received: from [129.148.9.178] (/129.148.9.178) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Apr 2010 05:19:24 -0700 Date: Mon, 19 Apr 2010 08:19:22 -0400 From: Brian Utterback Subject: Re: Move device allocation out of libbsm into libdevalloc [PSARC/2010/118 FastTrack timeout 04/14/2010] In-reply-to: <201004071614.o37GEfdu013050@sac.sfbay.sun.com> To: Brian Utterback Cc: PSARC-ext@sun.com, jan.parcel@oracle.com Message-id: <4BCC4A4A.5080100@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BCC4A51.0061:SCFMA4539814,ss=1,fgs=0 References: <201004071614.o37GEfdu013050@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4v; en-US; rv:1.9.1.9) Gecko/20100318 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 5876 The timer has past, the case had a least one +1 and the project team agrees to remove the man page as requested by Gar Winiger. There are no other outstanding issues, so I am marking this case as closed approved. On 04/07/10 12:14, Brian Utterback wrote: > I am submitting this fast track on behalf of Jan Parcel. The timer is set for April 14, 2010. > The requested binding is minor. > > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > 1. Introduction > 1.1. Project/Component Working Name: > Move device allocation out of libbsm into libdevalloc > 1.2. Name of Document Author/Supplier: > Author: Jan Parcel > 1.3 Date of This Document: > 07 April, 2010 > 4. Technical Description > This is a fast track to separate device allocation out of libbsm, in > Nevada only. > > 6908149 Create libdevalloc, get rid of problematic duplications of symbols and filenames > > libbsm effectively contains two unrelated libraries: one set of routines > for auditing, and one for device allocation. Now that both auditing and > device allocation are changing, and diverging, a build-breaking circular > dependency has surfaced. This could be fixed by putting some routines into > a usr/lib/common directory, but that would not solve the fact that the futures > of these two subsystems are expected to continue to diverge drastically. > > Bottom line: these should be two different libraries, libbsm for auditing and > libdevalloc for device allocation. Both libraries should be in the same > packages, for simplicity and compatibility. Every manifest that shows libbsm > will get identical lines made for libdevalloc, these are the affected > manifest files: > > usr/src/pkg/manifests/SUNWcs.mf > usr/src/pkg/manifests/system-library.mf > usr/src/pkg/manifests/system-trusted-global-zone.mf > usr/src/pkg/manifests/developer-library-lint.mf > > NONE of the externally-visible changes involve ARC'd public interfaces, > one change involves an accidentally-public interface (getdevicerange(3TSOL)) > > My inquiries, tree searches, and ldd/nm/grep research strongly indicate that > ALL of the affected interfaces except getdevicerange() are only used inside > the ON consolidation, as far as the WOS goes. I propose to fix all of that > in the same putback. > > usr/src/cmd/devfsadm (extensive dependencies) > usr/src/cmd/allocate (extensive dependencies) > usr/lib/lp/local/lpsched (getdevicerange) > > Some name changes were made to avoid ambiguity, such as libbsm's devinfo_t, > which is different from libdevinfo's devinfo_t. > > Getdevicerange should be Contracted Project Private in the future. > Known consumers are these programs which Stephen Browne covers: > > metacity > tsoldtlabel (defunct soon now that dt is gone from Nevada ????) > tsoljdslabel-ui > > Sun Ray, which is not part of the WOS, shows no sign of referencing > any of the moved routines in the source tree I was shown. > > It is unknown what third-party programs might reference these routines, > but man page correction should handle those. > > Past PSARC cases: > > PSARC/2002/142 Device Allocation Updates - by Ashish Joshi, closed withdrawn 01/09/2007 > PSARC/2005/691 Trusted Extensions for Device Allocation - by Ashish Joshi, waiting need opinion 03/01/2006 > PSARC/2002/762 Layered Trusted Solaris - by Glenn Faden, waiting need spec > > Related to: > > PSARC/2005/259 Layered Trusted Solaris Label Interfaces - by Gary Winiger, waiting need draft opinion 03/07/2006 > PSARC/2005/573 Solaris Trusted Extensions for Printing - by Glenn Faden, closed approved 05/17/2006 > > FILES: > > Added to create a new library libdevalloc: > usr/src/lib/libdevalloc/Makefile > usr/src/lib/libdevalloc/Makefile.com > usr/src/lib/libdevalloc/amd64/Makefile > usr/src/lib/libdevalloc/common/llib-ldevalloc > usr/src/lib/libdevalloc/common/mapfile-vers > usr/src/lib/libdevalloc/i386/Makefile > usr/src/lib/libdevalloc/sparc/Makefile > usr/src/lib/libdevalloc/sparcv9/Makefile > > Moved from libbsm to libdevalloc with filename change: > usr/src/lib/libdevalloc/common/libdevalloc.c (was devalloc.c) > (There is also a devalloc.c in usr/src/cmd/devfsadm.) > usr/src/lib/libdevalloc/common/dev_alloc.h (was bsm/devices.h) > usr/src/lib/libdevalloc/common/devalloc_impl.h (was $ROOT: bsm/devalloc.h) > > Moved from libbsm to libdevalloc: > usr/src/lib/libdevalloc/common/getdadefs.c > usr/src/lib/libdevalloc/common/getdaent.c > usr/src/lib/libdevalloc/common/getdevicerange.c > usr/src/lib/libdevalloc/common/getdment.c > > > In addition, we need to remove the long-since-defunct man getddent(3BSM), > since those routines do not even exist in s10 or Nevada. > > And I'll file a bug to make this change to man getdevicerange(3TSOL): > > diff getdevicerange.man future-getdevicerange.man > 12c12 > < cc [flag...] file... -lbsm -ltsol [library...] > --- > >> cc [flag...] file... -ldevalloc -ltsol [library...] >> > 45a46 > >> getdevicerange() is a Private interface. >> > 79c80 > < butes: > --- > >> butes, including Private interfaces: >> > 86c87 > < | Interface Stability | Committed | > --- > >> | Interface Stability | Private | >> > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > -- blu It's bad civic hygiene to build technologies that could someday be used to facilitate a police state. - Bruce Schneier ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Oracle Corporation. Ph:877-259-7345, Em:brian.utterback@oracle.com From jan.parcel@oracle.com Fri Apr 23 10:36:20 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3NHaKM2003525 for ; Fri, 23 Apr 2010 10:36:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3NHaKGi023058 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 23 Apr 2010 10:36:20 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1C0000VBKKAB00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 23 Apr 2010 10:36:20 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1C00GHCBKJ0J70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 23 Apr 2010 10:36:19 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3NHaIkk004409; Fri, 23 Apr 2010 17:36:18 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3NHaFPq024263; Fri, 23 Apr 2010 17:36:15 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 184902661272044135; Fri, 23 Apr 2010 10:35:35 -0700 Received: from [129.146.56.140] (/129.146.56.140) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Apr 2010 10:35:34 -0700 Date: Fri, 23 Apr 2010 10:34:34 -0700 From: "jan.parcel@oracle.com" Subject: Re: Move device allocation out of libbsm into libdevalloc [PSARC/2010/118 FastTrack timeout 04/14/2010] In-reply-to: <4BCC4A4A.5080100@oracle.com> To: Brian Utterback Cc: Brian Utterback , PSARC-ext@sun.com Reply-to: jan.parcel@oracle.com Message-id: <4BD1DA2A.3010101@oracle.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ZwJGMQCjif2yi0UO9L9QLQ)" X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BD1DA92.0099:SCFMA4539814,ss=1,fgs=0 References: <201004071614.o37GEfdu013050@sac.sfbay.sun.com> <4BCC4A4A.5080100@oracle.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090910) Status: RO Content-Length: 13343 This is a multi-part message in MIME format. --Boundary_(ID_ZwJGMQCjif2yi0UO9L9QLQ) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT They changed bsmconv from enabling auditing (future libbsm) to enabling device allocation (future libdevalloc) -- something I did not know. This means I *also* need to change the name of bsmconv to devalloc_enable and bsmunconv to devalloc_disable (as well as look for or file bugs to change the enabling method to a service or something) Can we consider this renaming to be part of the PSARC case or do I need another one? On 04/19/10 05:19, Brian Utterback wrote: > The timer has past, the case had a least one +1 and the project team > agrees to remove the man page as requested by Gar Winiger. There are no > other outstanding issues, so I am marking this case as closed approved. > > > On 04/07/10 12:14, Brian Utterback wrote: > >> I am submitting this fast track on behalf of Jan Parcel. The timer is set for April 14, 2010. >> The requested binding is minor. >> >> Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >> This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. >> 1. Introduction >> 1.1. Project/Component Working Name: >> Move device allocation out of libbsm into libdevalloc >> 1.2. Name of Document Author/Supplier: >> Author: Jan Parcel >> 1.3 Date of This Document: >> 07 April, 2010 >> 4. Technical Description >> This is a fast track to separate device allocation out of libbsm, in >> Nevada only. >> >> 6908149 Create libdevalloc, get rid of problematic duplications of symbols and filenames >> >> libbsm effectively contains two unrelated libraries: one set of routines >> for auditing, and one for device allocation. Now that both auditing and >> device allocation are changing, and diverging, a build-breaking circular >> dependency has surfaced. This could be fixed by putting some routines into >> a usr/lib/common directory, but that would not solve the fact that the futures >> of these two subsystems are expected to continue to diverge drastically. >> >> Bottom line: these should be two different libraries, libbsm for auditing and >> libdevalloc for device allocation. Both libraries should be in the same >> packages, for simplicity and compatibility. Every manifest that shows libbsm >> will get identical lines made for libdevalloc, these are the affected >> manifest files: >> >> usr/src/pkg/manifests/SUNWcs.mf >> usr/src/pkg/manifests/system-library.mf >> usr/src/pkg/manifests/system-trusted-global-zone.mf >> usr/src/pkg/manifests/developer-library-lint.mf >> >> NONE of the externally-visible changes involve ARC'd public interfaces, >> one change involves an accidentally-public interface (getdevicerange(3TSOL)) >> >> My inquiries, tree searches, and ldd/nm/grep research strongly indicate that >> ALL of the affected interfaces except getdevicerange() are only used inside >> the ON consolidation, as far as the WOS goes. I propose to fix all of that >> in the same putback. >> >> usr/src/cmd/devfsadm (extensive dependencies) >> usr/src/cmd/allocate (extensive dependencies) >> usr/lib/lp/local/lpsched (getdevicerange) >> >> Some name changes were made to avoid ambiguity, such as libbsm's devinfo_t, >> which is different from libdevinfo's devinfo_t. >> >> Getdevicerange should be Contracted Project Private in the future. >> Known consumers are these programs which Stephen Browne covers: >> >> metacity >> tsoldtlabel (defunct soon now that dt is gone from Nevada ????) >> tsoljdslabel-ui >> >> Sun Ray, which is not part of the WOS, shows no sign of referencing >> any of the moved routines in the source tree I was shown. >> >> It is unknown what third-party programs might reference these routines, >> but man page correction should handle those. >> >> Past PSARC cases: >> >> PSARC/2002/142 Device Allocation Updates - by Ashish Joshi, closed withdrawn 01/09/2007 >> PSARC/2005/691 Trusted Extensions for Device Allocation - by Ashish Joshi, waiting need opinion 03/01/2006 >> PSARC/2002/762 Layered Trusted Solaris - by Glenn Faden, waiting need spec >> >> Related to: >> >> PSARC/2005/259 Layered Trusted Solaris Label Interfaces - by Gary Winiger, waiting need draft opinion 03/07/2006 >> PSARC/2005/573 Solaris Trusted Extensions for Printing - by Glenn Faden, closed approved 05/17/2006 >> >> FILES: >> >> Added to create a new library libdevalloc: >> usr/src/lib/libdevalloc/Makefile >> usr/src/lib/libdevalloc/Makefile.com >> usr/src/lib/libdevalloc/amd64/Makefile >> usr/src/lib/libdevalloc/common/llib-ldevalloc >> usr/src/lib/libdevalloc/common/mapfile-vers >> usr/src/lib/libdevalloc/i386/Makefile >> usr/src/lib/libdevalloc/sparc/Makefile >> usr/src/lib/libdevalloc/sparcv9/Makefile >> >> Moved from libbsm to libdevalloc with filename change: >> usr/src/lib/libdevalloc/common/libdevalloc.c (was devalloc.c) >> (There is also a devalloc.c in usr/src/cmd/devfsadm.) >> usr/src/lib/libdevalloc/common/dev_alloc.h (was bsm/devices.h) >> usr/src/lib/libdevalloc/common/devalloc_impl.h (was $ROOT: bsm/devalloc.h) >> >> Moved from libbsm to libdevalloc: >> usr/src/lib/libdevalloc/common/getdadefs.c >> usr/src/lib/libdevalloc/common/getdaent.c >> usr/src/lib/libdevalloc/common/getdevicerange.c >> usr/src/lib/libdevalloc/common/getdment.c >> >> >> In addition, we need to remove the long-since-defunct man getddent(3BSM), >> since those routines do not even exist in s10 or Nevada. >> >> And I'll file a bug to make this change to man getdevicerange(3TSOL): >> >> diff getdevicerange.man future-getdevicerange.man >> 12c12 >> < cc [flag...] file... -lbsm -ltsol [library...] >> --- >> >> >>> cc [flag...] file... -ldevalloc -ltsol [library...] >>> >>> >> 45a46 >> >> >>> getdevicerange() is a Private interface. >>> >>> >> 79c80 >> < butes: >> --- >> >> >>> butes, including Private interfaces: >>> >>> >> 86c87 >> < | Interface Stability | Committed | >> --- >> >> >>> | Interface Stability | Private | >>> >>> >> 6. Resources and Schedule >> 6.4. Steering Committee requested information >> 6.4.1. Consolidation C-team Name: >> ON >> 6.5. ARC review type: FastTrack >> 6.6. ARC Exposure: open >> >> >> > > > --Boundary_(ID_ZwJGMQCjif2yi0UO9L9QLQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT They changed bsmconv from enabling auditing (future libbsm) to enabling
device allocation (future libdevalloc)  -- something I did not know.

This means I *also* need to change the name of bsmconv to devalloc_enable
and bsmunconv to devalloc_disable (as well as look for or file bugs to
change the enabling method to a service or something)

Can we consider this renaming to be part of the PSARC case or do I need another
one?

On 04/19/10 05:19, Brian Utterback wrote: 
The timer has past, the case had a least one +1 and the project team
agrees to remove the man page as requested by Gar Winiger. There are no
other outstanding issues, so I am marking this case as closed approved.


On 04/07/10 12:14, Brian Utterback wrote:
  
I am submitting this fast track on behalf of Jan Parcel. The timer is set for April 14, 2010. 
The requested binding is minor.

Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
1. Introduction
    1.1. Project/Component Working Name:
	 Move device allocation out of libbsm into libdevalloc
    1.2. Name of Document Author/Supplier:
	 Author:  Jan Parcel
    1.3  Date of This Document:
	07 April, 2010
4. Technical Description
This is a fast track to separate device allocation out of libbsm, in
Nevada only.

6908149 Create libdevalloc, get rid of problematic duplications of symbols and filenames

libbsm effectively contains two unrelated libraries:  one set of routines
for auditing, and one for device allocation.  Now that both auditing and
device allocation are changing, and diverging, a build-breaking circular
dependency has surfaced.  This could be fixed by putting some routines into
a usr/lib/common directory, but that would not solve the fact that the futures
of these two subsystems are expected to continue to diverge drastically.

Bottom line: these should be two different libraries, libbsm for auditing and
libdevalloc for device allocation.   Both libraries should be in the same
packages, for simplicity and compatibility.  Every manifest that shows libbsm
will get identical lines made for libdevalloc, these are the affected
manifest files:

usr/src/pkg/manifests/SUNWcs.mf
usr/src/pkg/manifests/system-library.mf
usr/src/pkg/manifests/system-trusted-global-zone.mf
usr/src/pkg/manifests/developer-library-lint.mf

NONE of the externally-visible changes involve ARC'd public interfaces,
one change involves an accidentally-public interface  (getdevicerange(3TSOL))

My inquiries, tree searches, and ldd/nm/grep research strongly indicate that
ALL of the affected interfaces except getdevicerange() are only used inside
the ON consolidation, as far as the WOS goes.  I propose to fix all of that
in the same putback. 

    usr/src/cmd/devfsadm  (extensive dependencies)
    usr/src/cmd/allocate  (extensive dependencies)
    usr/lib/lp/local/lpsched (getdevicerange)

Some name changes were made to avoid ambiguity, such as libbsm's devinfo_t,
which is different from libdevinfo's devinfo_t.

Getdevicerange should be Contracted Project Private in the future.
Known consumers are these programs which Stephen Browne covers:

    metacity
    tsoldtlabel (defunct soon now that dt is gone from Nevada ????)
    tsoljdslabel-ui

Sun Ray, which is not part of the WOS, shows no sign of referencing
any of the moved routines in the source tree I was shown.

It is unknown what third-party programs might reference these routines,
but man page correction should handle those.

Past PSARC cases:
	
PSARC/2002/142 Device Allocation Updates - by Ashish Joshi, closed withdrawn 01/09/2007
PSARC/2005/691  Trusted Extensions for Device Allocation - by Ashish Joshi, waiting need opinion 03/01/2006
PSARC/2002/762  Layered Trusted Solaris - by Glenn Faden, waiting need spec

Related to:

PSARC/2005/259  Layered Trusted Solaris Label Interfaces - by Gary Winiger, waiting need draft opinion 03/07/2006
PSARC/2005/573  Solaris Trusted Extensions for Printing - by Glenn Faden, closed approved 05/17/2006

FILES:

Added to create a new library libdevalloc:
usr/src/lib/libdevalloc/Makefile
usr/src/lib/libdevalloc/Makefile.com
usr/src/lib/libdevalloc/amd64/Makefile
usr/src/lib/libdevalloc/common/llib-ldevalloc
usr/src/lib/libdevalloc/common/mapfile-vers
usr/src/lib/libdevalloc/i386/Makefile
usr/src/lib/libdevalloc/sparc/Makefile
usr/src/lib/libdevalloc/sparcv9/Makefile

Moved from libbsm to libdevalloc with filename change:
usr/src/lib/libdevalloc/common/libdevalloc.c  (was devalloc.c)
   (There is also a devalloc.c in usr/src/cmd/devfsadm.)
usr/src/lib/libdevalloc/common/dev_alloc.h	(was bsm/devices.h)
usr/src/lib/libdevalloc/common/devalloc_impl.h  (was $ROOT: bsm/devalloc.h)

Moved from libbsm to libdevalloc:
usr/src/lib/libdevalloc/common/getdadefs.c
usr/src/lib/libdevalloc/common/getdaent.c
usr/src/lib/libdevalloc/common/getdevicerange.c
usr/src/lib/libdevalloc/common/getdment.c


In addition, we need to remove the long-since-defunct man getddent(3BSM),
since those routines do not even exist in s10 or Nevada.

And I'll file a bug to make this change to man getdevicerange(3TSOL):

diff getdevicerange.man future-getdevicerange.man 
12c12
<      cc [flag...] file... -lbsm -ltsol [library...]
---
  
    
     cc [flag...] file... -ldevalloc -ltsol [library...]
    
      
45a46
  
    
     getdevicerange() is a Private interface.
    
      
79c80
<      butes:
---
  
    
     butes, including Private interfaces:
    
      
86c87
<     | Interface Stability   |  Committed                        |
---
  
    
    | Interface Stability   |  Private                        |
    
      
6. Resources and Schedule
    6.4. Steering Committee requested information
   	6.4.1. Consolidation C-team Name:
		ON
    6.5. ARC review type: FastTrack
    6.6. ARC Exposure: open

--Boundary_(ID_ZwJGMQCjif2yi0UO9L9QLQ)-- From sacadmin Fri Apr 23 12:07:47 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3NJ7lLp006185 for ; Fri, 23 Apr 2010 12:07:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3NJ7kku025162 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Fri, 23 Apr 2010 12:07:46 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1C00F0DFSYWS00@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 23 Apr 2010 12:07:46 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1C009T1FSXVA00@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 23 Apr 2010 12:07:46 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3NJ7j5m022511; Fri, 23 Apr 2010 19:07:45 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3NJ7hWT003624; Fri, 23 Apr 2010 19:07:43 +0000 (GMT) Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 185155671272049612; Fri, 23 Apr 2010 12:06:52 -0700 Received: from [129.146.108.166] (/129.146.108.166) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Apr 2010 12:06:51 -0700 Date: Fri, 23 Apr 2010 12:08:54 -0700 From: Gary Winiger Subject: Re: Move device allocation out of libbsm into libdevalloc [PSARC/2010/118 FastTrack timeout 04/14/2010] In-reply-to: <4BD1DA2A.3010101@oracle.com> To: jan.parcel@oracle.com Cc: Brian Utterback , Brian Utterback , psarc@sun.com Message-id: <4BD1F046.3010407@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090203.4BD1EFFF.0185:SCFMA4539814,ss=1,fgs=0 References: <201004071614.o37GEfdu013050@sac.sfbay.sun.com> <4BCC4A4A.5080100@oracle.com> <4BD1DA2A.3010101@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.1.8) Gecko/20100329 Thunderbird/3.0.3 Status: RO Content-Length: 993 On 04/23/10 10:34, jan.parcel@oracle.com wrote: > They changed bsmconv from enabling auditing (future libbsm) to enabling > device allocation (future libdevalloc) -- something I did not know. HUH????? As you told me a couple days ago, you are only in the S10 support area. Solaris Next changes are not backported to S10 except by escalation. > This means I *also* need to change the name of bsmconv to devalloc_enable > and bsmunconv to devalloc_disable (as well as look for or file bugs to > change the enabling method to a service or something) Again HUH????? Why? None of that affects S10. > Can we consider this renaming to be part of the PSARC case or do I need > another > one? NO, NO, NO do not do that. If you intend to do anything in Solaris Next, do the full job..... If you want to know what that is, discuss it with Darren and me and get management to buy into your job of working in Solaris Next. BTW, see PSARC/2008/787 PSARC/2009/354, PSARC/2010/098 Gary.. From sacadmin Fri Apr 23 14:07:48 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o3NL7ms2008445 for ; Fri, 23 Apr 2010 14:07:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o3NL7m1b027161 for <@sunmail2sca.sfbay.sun.com:psarc@sun.com>; Fri, 23 Apr 2010 14:07:48 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1C0020NLD0L000@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 23 Apr 2010 14:07:48 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1C009CSLCZVO90@nwk-avmta-1.sfbay.Sun.COM> for psarc@sun.com (ORCPT psarc@sun.com); Fri, 23 Apr 2010 14:07:47 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3NL7ksY000466; Fri, 23 Apr 2010 21:07:46 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3NEM1mS024508; Fri, 23 Apr 2010 21:07:44 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt354.oracle.com with ESMTP id 185414091272056803; Fri, 23 Apr 2010 14:06:43 -0700 Received: from [129.146.56.140] (/129.146.56.140) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 23 Apr 2010 14:06:43 -0700 Date: Fri, 23 Apr 2010 14:05:49 -0700 From: "jan.parcel@oracle.com" Subject: Re: Move device allocation out of libbsm into libdevalloc [PSARC/2010/118 FastTrack timeout 04/14/2010] In-reply-to: <4BD1F046.3010407@oracle.com> To: Gary Winiger Cc: Brian Utterback , Brian Utterback , psarc@sun.com Reply-to: jan.parcel@oracle.com Message-id: <4BD20BAD.70905@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BD20C21.0050:SCFMA4539814,ss=1,fgs=0 References: <201004071614.o37GEfdu013050@sac.sfbay.sun.com> <4BCC4A4A.5080100@oracle.com> <4BD1DA2A.3010101@oracle.com> <4BD1F046.3010407@oracle.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090910) Status: RO Content-Length: 2089 I take it from this email that I should simply file a CR that it is confusing for bsmconv to have nothing to do with libbsm after my libdevalloc fix. OK, agreed. I have to do this PSARC because the code reviewers and CRT for my last project require it as a condition of the ugly putback of 6920272 libdevinfo is too connected, libbsm must not depend upon it. The ugly fix will stay in s10, because 1. the source is not public, and 2. It's not stretching into the future. Bottom line: I "play my position" which means as a sustaining engineer I put customer schedules ahead of taking on development projects, but once in awhile I have no choice. When I'm doing a minor bug fix for s10, I am required to put it back for 1 month soak in Nevada before I put it back to s10, and it is the s10 putback date my customer is judging me on. On 04/23/10 12:08, Gary Winiger wrote: > On 04/23/10 10:34, jan.parcel@oracle.com wrote: >> They changed bsmconv from enabling auditing (future libbsm) to enabling >> device allocation (future libdevalloc) -- something I did not know. > > HUH????? As you told me a couple days ago, you are only in the > S10 support area. Solaris Next changes are not backported to > S10 except by escalation. > >> This means I *also* need to change the name of bsmconv to >> devalloc_enable >> and bsmunconv to devalloc_disable (as well as look for or file bugs to >> change the enabling method to a service or something) > > Again HUH????? Why? None of that affects S10. > >> Can we consider this renaming to be part of the PSARC case or do I need >> another >> one? > > NO, NO, NO do not do that. If you intend to do anything in > Solaris Next, do the full job..... > If you want to know what that is, discuss it with Darren and me > and get management to buy into your job of working in Solaris > Next. > > BTW, see PSARC/2008/787 PSARC/2009/354, PSARC/2010/098 > > Gary.. OK, can I just tell Jeff Beck that per Gary Winiger I don't have to keep my word about the final fix for the Netscape crashes?