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:[email protected]

_______________________________________________
opensolaris-arc mailing list
[email protected]

Reply via email to