--- old/usr/src/cmd/mandoc/msec.in	Wed Sep 30 19:35:35 2015
+++ new/usr/src/cmd/mandoc/msec.in	Wed Sep 30 19:35:35 2015
@@ -18,6 +18,7 @@
 LINE("1C",		"Communication Commands")
 LINE("1HAS",		"User Commands")
 LINE("1M",		"Maintenance Commands")
+LINE("1ONBLD",		"illumos Build Tools")
 LINE("1S",		"illumos Specific Commands")
 LINE("2",		"System Calls")
 LINE("3",		"Introduction to Library Functions")
--- old/usr/src/pkg/manifests/developer-build-onbld.mf	Wed Sep 30 19:35:35 2015
+++ new/usr/src/pkg/manifests/developer-build-onbld.mf	Wed Sep 30 19:35:35 2015
@@ -57,7 +57,7 @@
 dir path=opt/onbld/lib/python2.6/onbld/Scm
 dir path=opt/onbld/lib/python2.6/onbld/hgext
 dir path=opt/onbld/man
-dir path=opt/onbld/man/man1
+dir path=opt/onbld/man/man1onbld
 dir path=opt/onbld/share
 $(i386_ONLY)file path=opt/onbld/bin/$(ARCH)/aw mode=0555
 $(sparc_ONLY)file path=opt/onbld/bin/$(ARCH)/chk4ubin mode=0555
@@ -185,39 +185,39 @@
 file path=opt/onbld/lib/python2.6/onbld/hgext/__init__.py mode=0444
 file path=opt/onbld/lib/python2.6/onbld/hgext/__init__.pyc mode=0444
 file path=opt/onbld/lib/python2.6/onbld/hgext/cdm.py mode=0444
-file path=opt/onbld/man/man1/Install.1
-file path=opt/onbld/man/man1/bldenv.1
-file path=opt/onbld/man/man1/bringovercheck.1
-file path=opt/onbld/man/man1/cddlchk.1
-file path=opt/onbld/man/man1/check_rtime.1
-file path=opt/onbld/man/man1/checkpaths.1
-file path=opt/onbld/man/man1/codereview.1
-file path=opt/onbld/man/man1/cstyle.1
-file path=opt/onbld/man/man1/cw.1
-file path=opt/onbld/man/man1/find_elf.1
-file path=opt/onbld/man/man1/findunref.1
-file path=opt/onbld/man/man1/flg.flp.1
-file path=opt/onbld/man/man1/get_depend_info.1
-file path=opt/onbld/man/man1/git-pbchk.1
-file path=opt/onbld/man/man1/hdrchk.1
-file path=opt/onbld/man/man1/hgsetup.1
-file path=opt/onbld/man/man1/interface_check.1
-file path=opt/onbld/man/man1/interface_cmp.1
-file path=opt/onbld/man/man1/jstyle.1
-file path=opt/onbld/man/man1/lintdump.1
-file path=opt/onbld/man/man1/make_pkg_db.1
-file path=opt/onbld/man/man1/mapfilechk.1
-file path=opt/onbld/man/man1/ndrgen.1
-file path=opt/onbld/man/man1/nightly.1
-file path=opt/onbld/man/man1/onu.1
-file path=opt/onbld/man/man1/sccscheck.1
-file path=opt/onbld/man/man1/signit.1
-file path=opt/onbld/man/man1/signproto.1
-file path=opt/onbld/man/man1/webrev.1
-file path=opt/onbld/man/man1/which_scm.1
-file path=opt/onbld/man/man1/ws.1
-file path=opt/onbld/man/man1/wsdiff.1
-file path=opt/onbld/man/man1/xref.1
+file path=opt/onbld/man/man1onbld/Install.1onbld
+file path=opt/onbld/man/man1onbld/bldenv.1onbld
+file path=opt/onbld/man/man1onbld/bringovercheck.1onbld
+file path=opt/onbld/man/man1onbld/cddlchk.1onbld
+file path=opt/onbld/man/man1onbld/check_rtime.1onbld
+file path=opt/onbld/man/man1onbld/checkpaths.1onbld
+file path=opt/onbld/man/man1onbld/codereview.1onbld
+file path=opt/onbld/man/man1onbld/cstyle.1onbld
+file path=opt/onbld/man/man1onbld/cw.1onbld
+file path=opt/onbld/man/man1onbld/find_elf.1onbld
+file path=opt/onbld/man/man1onbld/findunref.1onbld
+file path=opt/onbld/man/man1onbld/flg.flp.1onbld
+file path=opt/onbld/man/man1onbld/get_depend_info.1onbld
+file path=opt/onbld/man/man1onbld/git-pbchk.1onbld
+file path=opt/onbld/man/man1onbld/hdrchk.1onbld
+file path=opt/onbld/man/man1onbld/hgsetup.1onbld
+file path=opt/onbld/man/man1onbld/interface_check.1onbld
+file path=opt/onbld/man/man1onbld/interface_cmp.1onbld
+file path=opt/onbld/man/man1onbld/jstyle.1onbld
+file path=opt/onbld/man/man1onbld/lintdump.1onbld
+file path=opt/onbld/man/man1onbld/make_pkg_db.1onbld
+file path=opt/onbld/man/man1onbld/mapfilechk.1onbld
+file path=opt/onbld/man/man1onbld/ndrgen.1onbld
+file path=opt/onbld/man/man1onbld/nightly.1onbld
+file path=opt/onbld/man/man1onbld/onu.1onbld
+file path=opt/onbld/man/man1onbld/sccscheck.1onbld
+file path=opt/onbld/man/man1onbld/signit.1onbld
+file path=opt/onbld/man/man1onbld/signproto.1onbld
+file path=opt/onbld/man/man1onbld/webrev.1onbld
+file path=opt/onbld/man/man1onbld/which_scm.1onbld
+file path=opt/onbld/man/man1onbld/ws.1onbld
+file path=opt/onbld/man/man1onbld/wsdiff.1onbld
+file path=opt/onbld/man/man1onbld/xref.1onbld
 file path=opt/onbld/share/make.rules mode=0444
 hardlink path=opt/onbld/bin/$(ARCH)/install.bin target=./install
 legacy pkg=SUNWonbld desc="tools used to build the OS-Net consolidation" \
@@ -231,7 +231,7 @@
 link path=opt/onbld/bin/$(ARCH)/dmake target=make
 link path=opt/onbld/bin/git-nits target=git-pbchk
 link path=opt/onbld/lib/python target=python2.6
-link path=opt/onbld/man/man1/git-nits.1 target=git-pbchk.1
+link path=opt/onbld/man/man1onbld/git-nits.1onbld target=git-pbchk.1onbld
 # webrev(1) requires ps2pdf
 depend fmri=print/filter/ghostscript type=require
 # nightly(1) uses wget
--- old/usr/src/tools/Makefile	Wed Sep 30 19:35:35 2015
+++ new/usr/src/tools/Makefile	Wed Sep 30 19:35:35 2015
@@ -105,7 +105,7 @@
 	$(ROOTONBLD)/share \
 	$(ROOTONBLD)/gk \
 	$(ROOTONBLD)/man \
-	$(ROOTONBLD)/man/man1
+	$(ROOTONBLD)/man/man1onbld
 
 all :=		TARGET= install
 install :=	TARGET= install
--- old/usr/src/tools/Makefile.tools	Wed Sep 30 19:35:35 2015
+++ new/usr/src/tools/Makefile.tools	Wed Sep 30 19:35:35 2015
@@ -43,7 +43,7 @@
 ROOTONBLDENV=		$(ROOTONBLD)/env
 ROOTONBLDGK=		$(ROOTONBLD)/gk
 ROOTONBLDMAN=		$(ROOTONBLD)/man
-ROOTONBLDMAN1=		$(ROOTONBLD)/man/man1
+ROOTONBLDMAN1ONBLD=	$(ROOTONBLD)/man/man1onbld
 ROOTONBLDETCABI=	$(ROOTONBLD)/etc/abi
 ROOTONBLDETCEXCEPT=	$(ROOTONBLD)/etc/exception_lists
 ROOTONBLDSHARE=		$(ROOTONBLD)/share
@@ -67,7 +67,7 @@
 ROOTONBLDPERLFILES=	$(PERLFILES:%=$(ROOTONBLDBIN)/%)
 ROOTONBLDPERLMODULES=	$(PERLMODULES:%=$(ROOTONBLDLIBPERL)/%)
 ROOTONBLDPYFILES=	$(PYFILES:%=$(ROOTONBLDBIN)/%)
-ROOTONBLDMAN1FILES=	$(MAN1FILES:%=$(ROOTONBLDMAN1)/%)
+ROOTONBLDMAN1ONBLDFILES=$(MAN1ONBLDFILES:%=$(ROOTONBLDMAN1ONBLD)/%)
 ROOTONBLDABIAUDITFILES=	$(ABI_AUDITFILES:%=$(ROOTONBLDETCABI)/%)
 ROOTONBLDEXCEPTFILES=	$(EXCEPTFILES:%=$(ROOTONBLDETCEXCEPT)/%)
 
@@ -92,7 +92,7 @@
 $(ROOTONBLDLIBPERL)/%: %
 	$(INS.file)
 
-$(ROOTONBLDMAN1)/%: %
+$(ROOTONBLDMAN1ONBLD)/%: %
 	$(INS.file)
 
 $(ROOTONBLDENV)/%: %
--- old/usr/src/tools/codereview/Makefile	Wed Sep 30 19:35:35 2015
+++ new/usr/src/tools/codereview/Makefile	Wed Sep 30 19:35:35 2015
@@ -34,9 +34,9 @@
 
 CERRWARN += -_gcc=-Wno-parentheses
 
-MAN1FILES= codereview.1
+MAN1ONBLDFILES= codereview.1onbld
 
-$(ROOTONBLDMAN1FILES) := FILEMODE=      644
+$(ROOTONBLDMAN1ONBLDFILES) := FILEMODE=      644
 
 COPTS=	-O
 
@@ -50,7 +50,7 @@
 	$(LINK.c) -o $@ $(OBJS) $(LDLIBS)
 	$(POST_PROCESS)
 
-install: all .WAIT  $(ROOTONBLDMACHPROG) $(ROOTONBLDMAN1FILES)
+install: all .WAIT  $(ROOTONBLDMACHPROG) $(ROOTONBLDMAN1ONBLDFILES)
 
 clean:
 	$(RM) $(CLEANFILES)
--- old/usr/src/tools/codereview/codereview.1	Wed Sep 30 19:35:35 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,93 +0,0 @@
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.TH codereview 1 "August 5, 2008"
-.UC
-.SH NAME
-codereview \- Diff list generator
-.SH SYNOPSIS
-.B codereview
-[-e] [-h\f2heading\fP] [-r]
-.I oldfile
-.I newfile
-.SH DESCRIPTION
-.PP
-The
-.I codereview
-command expects two ASCII text files as input
-and produces Postscript describing the differences between the files.
-The first file is assumed to be the older version,
-and the second file is assumed to be the newer version.
-If either
-.I oldfile
-or
-.I newfile
-is
-.BR - ,
-the corresponding file is taken from the standard input.
-The output goes to standard output and lists all lines from both files,
-with lines changed from the first to the second being highlighted in gray.
-Lines deleted from the first file are listed in italic,
-while lines added to the second file are listed in bold.
-.SH OPTIONS
-.TP 10
-.B \-e
-Elide unchanged functions.
-Functions which are unchanged will be heuristically eliminated from the listing.
-Only the function end is parsed.
-The assumption is that a brace ('}')
-in column one represents the end of a function.
-Thus unchanged structure definitions may be elided also.
-For support of assembly language files,
-the string "SET_SIZE(" occurring in a line is assumed
-to mark the end of a function also.
-.TP
-.BI \-h heading
-Put a header on each page.
-The
-.I heading
-string appears at the upper left of each page,
-and the page number appears at the upper right.
-.TP
-.B \-r
-Enable page reversal so that the pages appear in the correct sequence
-in the output tray of printers like the Apple LaserWriter.
-The default is not to perform page reversal,
-which is correct for printers like the NEC Silentwriter LC-890.
-.SH FILES
-/tmp/lwlpXXXXXX		\- temporary file used for page reversal
-.SH LIMITATIONS
-The maximum input line length is 1024 characters.
-This should not present a problem
-since the corresponding output line length would be too long to be printed.
-The program silently truncates input lines that are too long.
-.SH NOTES
-The command
-.sp 0.5v
-.ti +0.4i
-pageview -right -h 17 -w 11 -Ws 1100 850 -dpi 100 out.ps
-.sp 0.5v
-is useful for displaying the results of
-.IR codereview .
-.SH AUTHOR
-John Zolnowsky
-.br
-SunSoft, Inc.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/codereview/codereview.1onbld	Wed Sep 30 19:35:35 2015
@@ -0,0 +1,93 @@
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.TH codereview 1ONBLD "August 5, 2008"
+.UC
+.SH NAME
+codereview \- Diff list generator
+.SH SYNOPSIS
+.B codereview
+[-e] [-h\f2heading\fP] [-r]
+.I oldfile
+.I newfile
+.SH DESCRIPTION
+.PP
+The
+.I codereview
+command expects two ASCII text files as input
+and produces Postscript describing the differences between the files.
+The first file is assumed to be the older version,
+and the second file is assumed to be the newer version.
+If either
+.I oldfile
+or
+.I newfile
+is
+.BR - ,
+the corresponding file is taken from the standard input.
+The output goes to standard output and lists all lines from both files,
+with lines changed from the first to the second being highlighted in gray.
+Lines deleted from the first file are listed in italic,
+while lines added to the second file are listed in bold.
+.SH OPTIONS
+.TP 10
+.B \-e
+Elide unchanged functions.
+Functions which are unchanged will be heuristically eliminated from the listing.
+Only the function end is parsed.
+The assumption is that a brace ('}')
+in column one represents the end of a function.
+Thus unchanged structure definitions may be elided also.
+For support of assembly language files,
+the string "SET_SIZE(" occurring in a line is assumed
+to mark the end of a function also.
+.TP
+.BI \-h heading
+Put a header on each page.
+The
+.I heading
+string appears at the upper left of each page,
+and the page number appears at the upper right.
+.TP
+.B \-r
+Enable page reversal so that the pages appear in the correct sequence
+in the output tray of printers like the Apple LaserWriter.
+The default is not to perform page reversal,
+which is correct for printers like the NEC Silentwriter LC-890.
+.SH FILES
+/tmp/lwlpXXXXXX		\- temporary file used for page reversal
+.SH LIMITATIONS
+The maximum input line length is 1024 characters.
+This should not present a problem
+since the corresponding output line length would be too long to be printed.
+The program silently truncates input lines that are too long.
+.SH NOTES
+The command
+.sp 0.5v
+.ti +0.4i
+pageview -right -h 17 -w 11 -Ws 1100 850 -dpi 100 out.ps
+.sp 0.5v
+is useful for displaying the results of
+.IR codereview .
+.SH AUTHOR
+John Zolnowsky
+.br
+SunSoft, Inc.
--- old/usr/src/tools/codesign/Makefile	Wed Sep 30 19:35:35 2015
+++ new/usr/src/tools/codesign/Makefile	Wed Sep 30 19:35:35 2015
@@ -30,22 +30,22 @@
 PERLFILES= \
 	signit
 
-MAN1FILES= \
-	signit.1 \
-	signproto.1
+MAN1ONBLDFILES= \
+	signit.1onbld \
+	signproto.1onbld
 
 CLEANFILES = $(SHFILES) $(PERLFILES)
 
 include ../Makefile.tools
 
-$(ROOTONBLDMAN1FILES) := FILEMODE=	644
+$(ROOTONBLDMAN1ONBLDFILES) := FILEMODE=	644
 
 .KEEP_STATE:
 
-all:	$(SHFILES) $(PERLFILES) $(MAN1FILES)
+all:	$(SHFILES) $(PERLFILES) $(MAN1ONBLDFILES)
 
 install: all .WAIT $(ROOTONBLDSHFILES) $(ROOTONBLDPERLFILES) \
-		$(ROOTONBLDMAN1FILES)
+		$(ROOTONBLDMAN1ONBLDFILES)
 
 clean:
 	$(RM) $(CLEANFILES)
--- old/usr/src/tools/codesign/signit.1	Wed Sep 30 19:35:36 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,88 +0,0 @@
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2007 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.\" ident	"%Z%%M%	%I%	%E% SMI"
-.TH signit 1 "13 June 2007"
-.SH NAME
-.I signit
-\- sign files using code signing server
-.SH SYNOPSIS
-\fBsignit [-q] [-i dir] [-o dir] [-l user]\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "signit" "" "\fBsignit\fP"
-.LP
-.I signit
-is the client program for use with Sun's code signing server. It
-reads a list of signing credential names and relative pathnames
-from standard input. Each file is read from the input directory,
-sent to the signing server, signed with the specified credential,
-and written to the output directory.
-.LP
-.SH OPTIONS
-.LP
-The following options are supported:
-.TP 4
-.B \-q
-Quiet operation: This option suppresses printing the names of files
-that are signed successfully.
-.LP
-.TP 4
-.B -i \fIdir\fP
-Specifies the base input directory from which the relative pathnames
-of files to be signed are interpreted. If not specified, the
-input directory defaults to the current directory.
-.LP
-.TP 4
-.B -o \fIdir\fP
-Specifies the base output directory to which signed files
-are written.  If not specified, the
-output directory matches the input directory.
-.LP
-.TP 4
-.B -l \fIuser\fP
-Specifies the user login name on the code signing server. If not
-specified, the login name of the user running
-.I signit
-is used.
-.LP
-.SH ENVIRONMENT
-.LP
-.TP 4
-.B CODESIGN_SERVER
-Specifies the hostname or IP address of the code signing server. If
-this variable is not set, it defaults to quill.sfbay.
-.LP
-.SH EXIT STATUS
-.LP
-The following exit status values are returned:
-.IP "\fB0\fR" 4
-.IX Item "0"
-All specified files were signed successfully.
-.IP "\fB1\fR" 4
-.IX Item "1"
-One or more files were not signed successfully.
-.LP
-.SH SEE ALSO
-.LP
-signproto(1)
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/codesign/signit.1onbld	Wed Sep 30 19:35:36 2015
@@ -0,0 +1,87 @@
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2007 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.TH signit 1ONBLD "13 June 2007"
+.SH NAME
+.I signit
+\- sign files using code signing server
+.SH SYNOPSIS
+\fBsignit [-q] [-i dir] [-o dir] [-l user]\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "signit" "" "\fBsignit\fP"
+.LP
+.I signit
+is the client program for use with Sun's code signing server. It
+reads a list of signing credential names and relative pathnames
+from standard input. Each file is read from the input directory,
+sent to the signing server, signed with the specified credential,
+and written to the output directory.
+.LP
+.SH OPTIONS
+.LP
+The following options are supported:
+.TP 4
+.B \-q
+Quiet operation: This option suppresses printing the names of files
+that are signed successfully.
+.LP
+.TP 4
+.B -i \fIdir\fP
+Specifies the base input directory from which the relative pathnames
+of files to be signed are interpreted. If not specified, the
+input directory defaults to the current directory.
+.LP
+.TP 4
+.B -o \fIdir\fP
+Specifies the base output directory to which signed files
+are written.  If not specified, the
+output directory matches the input directory.
+.LP
+.TP 4
+.B -l \fIuser\fP
+Specifies the user login name on the code signing server. If not
+specified, the login name of the user running
+.I signit
+is used.
+.LP
+.SH ENVIRONMENT
+.LP
+.TP 4
+.B CODESIGN_SERVER
+Specifies the hostname or IP address of the code signing server. If
+this variable is not set, it defaults to quill.sfbay.
+.LP
+.SH EXIT STATUS
+.LP
+The following exit status values are returned:
+.IP "\fB0\fR" 4
+.IX Item "0"
+All specified files were signed successfully.
+.IP "\fB1\fR" 4
+.IX Item "1"
+One or more files were not signed successfully.
+.LP
+.SH SEE ALSO
+.LP
+signproto(1ONBLD)
--- old/usr/src/tools/codesign/signproto.1	Wed Sep 30 19:35:36 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,75 +0,0 @@
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2007 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.\" ident	"%Z%%M%	%I%	%E% SMI"
-.TH signproto 1 "13 June 2007"
-.SH NAME
-.I signproto
-\- sign ELF objects in proto area
-.SH SYNOPSIS
-\fBsignproto \fIcred_file\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "signproto" "" "\fBsignproto\fP"
-.LP
-.I signproto
-finds ELF objects in the ON proto area and re-signs them
-using 
-.IR signit (1).
-This operation is normally invoked only for
-release builds, as it replaces the internal development
-signatures with official Sun signatures. The actual signing using
-Sun's private key is performed by a code signing server which
-is accessed via
-.IR signit .
-.LP
-Cryptographic modules are identified by examining the signature
-embedded by
-.IR elfsign (1)
-during the build process. 
-.I signproto
-requires a single command-line argument, which is a file containing
-the mapping between each signing server credential name and the Subject
-Distinguished Name (DN) of the certificate used to 
-sign the ELF file. Each line in the file contains a credential name
-followed by a regular expression. The first regular expression that
-matches the Subject DN embedded in the ELF file determines the 
-credential name passed to
-.I signit
-to re-sign the file.
-.LP
-.SH ENVIRONMENT
-.LP
-.TP 4
-.B CODESIGN_USER
-Login name for the code signing server passed to
-.I signit .
-If this variable is not set, the value in LOGNAME is used instead.
-.LP
-.TP 4
-.B ROOT
-Location of ON proto area containing files to be signed.
-.LP
-.SH SEE ALSO
-.LP
-signit(1), elfsign(1)
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/codesign/signproto.1onbld	Wed Sep 30 19:35:36 2015
@@ -0,0 +1,74 @@
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2007 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.TH signproto 1ONBLD "13 June 2007"
+.SH NAME
+.I signproto
+\- sign ELF objects in proto area
+.SH SYNOPSIS
+\fBsignproto \fIcred_file\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "signproto" "" "\fBsignproto\fP"
+.LP
+.I signproto
+finds ELF objects in the ON proto area and re-signs them
+using 
+.IR signit (1ONBLD).
+This operation is normally invoked only for
+release builds, as it replaces the internal development
+signatures with official Sun signatures. The actual signing using
+Sun's private key is performed by a code signing server which
+is accessed via
+.IR signit .
+.LP
+Cryptographic modules are identified by examining the signature
+embedded by
+.IR elfsign (1)
+during the build process. 
+.I signproto
+requires a single command-line argument, which is a file containing
+the mapping between each signing server credential name and the Subject
+Distinguished Name (DN) of the certificate used to 
+sign the ELF file. Each line in the file contains a credential name
+followed by a regular expression. The first regular expression that
+matches the Subject DN embedded in the ELF file determines the 
+credential name passed to
+.I signit
+to re-sign the file.
+.LP
+.SH ENVIRONMENT
+.LP
+.TP 4
+.B CODESIGN_USER
+Login name for the code signing server passed to
+.I signit .
+If this variable is not set, the value in LOGNAME is used instead.
+.LP
+.TP 4
+.B ROOT
+Location of ON proto area containing files to be signed.
+.LP
+.SH SEE ALSO
+.LP
+signit(1ONBLD), elfsign(1)
--- old/usr/src/tools/cw/Makefile	Wed Sep 30 19:35:36 2015
+++ new/usr/src/tools/cw/Makefile	Wed Sep 30 19:35:36 2015
@@ -25,7 +25,7 @@
 
 PROG	= cw
 
-MAN1FILES=	cw.1
+MAN1ONBLDFILES=	cw.1onbld
 
 include ../Makefile.tools
 
@@ -52,13 +52,13 @@
 CPPFLAGS += -DDEFAULT_CPLUSPLUS_DIR='"$(SPRO_VROOT)/bin"'
 CPPFLAGS += -DDEFAULT_GPLUSPLUS_DIR='"$(GCC_ROOT)/bin"'
 
-$(ROOTONBLDMAN1FILES) := FILEMODE=      644
+$(ROOTONBLDMAN1ONBLDFILES) := FILEMODE=      644
 
 .KEEP_STATE:
 
-all: $(PROG) $(MAN1FILES)
+all: $(PROG) $(MAN1ONBLDFILES)
 
-install: all .WAIT $(ROOTONBLDMACHPROG) $(ROOTONBLDMAN1FILES)
+install: all .WAIT $(ROOTONBLDMACHPROG) $(ROOTONBLDMAN1ONBLDFILES)
 
 lint: lint_PROG
 
--- old/usr/src/tools/cw/cw.1	Wed Sep 30 19:35:36 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,261 +0,0 @@
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2010 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.TH cw 1 "22 March 2010"
-.SH NAME
-.I cw
-\- invoke one or more compilers with argument translation
-.SH SYNOPSIS
-\fBcw {-_cc|-_gcc|-_CC|-_g++} [options] [compiler args...]\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "cw" "" "\fBcw\fP"
-.LP
-.I cw
-is a facility for invoking one or more compilers, providing
-translation from Sun Studio arguments as appropriate.  This allows
-the use of arbitrary compilers without the need to alter large
-numbers of makefiles.  A mode called shadow compilation, the default,
-invokes two different compilers so that warnings and errors may be
-obtained from both.  See SHADOW COMPILATION for details.  This version
-of cw supports Sun Studio 10 and 11 and gcc 3.4.3 as shipped in
-Solaris.
-.LP
-.SH ARGUMENTS
-.LP
-Exactly one of the following arguments is required, and must appear
-immediately following \fBcw\fP in the argument list:
-.TP 4
-.B \-_cc
-Select Sun Studio C (cc) as the primary compiler.
-.TP 4
-.B \-_gcc
-Select GNU C (gcc) as the primary compiler.
-.TP 4
-.B \-_CC
-Select Sun Studio C++ (CC) as the primary compiler.
-.TP 4
-.B \-_g++
-Select GNU C++ (g++) as the primary compiler.
-.LP
-.SH OPTIONS
-.LP
-The following options are supported:
-.TP 4
-.B \-_compiler
-Do not invoke any compiler; instead, write to standard output the
-full path to the primary compiler that would be invoked.  If this
-option is given, it must appear immediately following the compiler
-selection argument, and all other options will be disregarded.
-.LP
-.TP 4
-.B \-_versions
-Print the cw version, followed in turn by the path to and versions
-of each compiler which would be invoked.  If this option is given,
-it must appear immediately following the compiler selection argument,
-and all other options will be disregarded.
-.LP
-.TP 4
-.B \-_noecho
-Normally, cw writes to standard error the actual compiler commands
-invoked, each prefixed with '+'.  This option suppresses these
-messages.
-.LP
-.TP 4
-.B \-_cc=,\-_gcc=,\-_CC=,\-g++=
-Pass compiler-dependent options.  See ARGUMENT TRANSLATION.
-.LP
-.SH SHADOW COMPILATION
-.LP
-Unless otherwise directed by environment variables (see ENVIRONMENT),
-\fBcw\fP will invoke both the compiler specified by its first argument
-(primary) and a designated alternate compiler (shadow).  The primary
-compiler will be invoked with the arguments given to cw, translated
-as described in ARGUMENT TRANSLATION.  The secondary compiler will be
-invoked in parallel with the primary (but see ENVIRONMENT); its
-arguments will likewise be translated.  However, the shadow compiler's
-arguments will also be modified as follows:
-.LP
-.TP 4
-.B 1.
-If none of \fI-c\fP, \fI-E\fP, \fI-P\fP, or \fI-S\fP appears in the
-argument list (that is, linking is attempted), the shadow compiler
-will not be invoked.  This is because the objects built with that
-compiler which would be linked have been previously discarded.
-.LP
-.TP 4
-.B 2.
-If an option of the form \fI-ofilename\fP was provided, it will be
-replaced by two options of the form \fI-o\fP \fItempfile\fP.
-.LP
-.TP 4
-.B 3.
-If the option \fI-o\fP was provided, its following argument will be
-replaced by \fItempfile\fP.
-.LP
-.TP 4
-.B 4.
-If neither of the above options was provided, two options of the
-form \fI-o\fP \fItempfile\fP will be added to the end of the argument
-list used to invoke the shadow compiler.
-.LP
-In all three cases, \fItempfile\fP is the name of a temporary file
-which will be removed by \fBcw\fP before it terminates.
-.LP
-When shadow compilation is in effect, \fBcw\fP writes to standard error
-each compiler's standard error output following its argument list.
-Messages from the two compilers will not be interleaved.  If \fBcw\fP
-is used to invoke the preprocessor and no output location is specified,
-\fBcw\fP will write to standard output the primary compiler's
-standard output, and the secondary compiler's standard output will
-be discarded.
-.LP
-Because the Studio compilers write intermediate objects to fixed
-filenames in the current directory when instructed to compile and
-link multiple source files via a single command line, it would be
-unsafe to invoke more than one compiler in this fashion.  Therefore
-\fBcw\fP does not accept multiple source files unless the
-preprocessor is to be invoked.  An attempt to invoke \fBcw\fP in
-this manner will result in an error.
-.LP
-.SH ARGUMENT TRANSLATION
-.LP
-The arguments provided to \fBcw\fP will be passed through to each
-compiler invoked, altered as follows:
-.LP
-.TP 4
-.B 1.
-Options intended for \fBcw\fP itself are removed.
-.LP
-.TP 4
-.B 2.
-The shadow compiler's arguments are modified as described in
-SHADOW COMPILATION so that its output is discarded.
-.LP
-.TP 4
-.B 3.
-If the compiler to be invoked is a GNU C or C++ compiler, a set of
-default flags is added to the beginning of the argument list, and the
-remaining arguments are translated to their closest appropriate
-semantic equivalents and passed in the same order as their
-counterparts given to \fBcw\fP.  Arguments which begin with
-\fI-_gcc=\fP or \fI-_g++=\fP will be passed in place with the
-leading portion removed.  Arguments which begin with \fI-_cc=\fP or
-\fI-_CC=\fP will be discarded.  See the comments at the head of
-\fIusr/src/tools/cw/cw.c\fP for a detailed list of translations.
-.LP
-.TP 4
-.B 4.
-If the compiler to be invoked is a Studio C or C++ compiler, the
-remaining arguments are passed unmodified and in the same order as
-given to \fBcw\fP.  Arguments which begin with \fI-_cc=\fP or
-\fI-_CC=\fP will be passed in place with the leading portion removed.
-Arguments which begin with \fI-_gcc=\fP or \fI-_g++=\fP will be
-discarded.
-.LP
-.SH ENVIRONMENT
-.LP
-.TP 4
-.B CW_NO_SHADOW
-If this variable is set in the environment, invoke only the
-primary compiler.
-.LP
-.TP 4
-.B CW_SHADOW_SERIAL
-If this variable is set in the environment, invoke the primary compiler,
-wait for it to complete, then invoke the shadow compiler.  Normally
-the two compilers are invoked in parallel.  If CW_NO_SHADOW is set,
-this has no effect.
-.LP
-.TP 4
-.B CW_NO_EXEC
-If this variable is set in the environment, write the usual output to
-standard error but do not actually invoke any compiler.  This is
-useful for debugging the translation engine.
-.LP
-.TP 4
-.B CW_CC, CW_CPLUSPLUS
-If these variables are set in the environment, they specify the full
-pathname for the Studio C and C++ compilers, respectively.
-.LP
-.TP 4
-.B CW_CC_DIR, CW_CPLUSPLUS_DIR, SPRO_VROOT, SPRO_ROOT, BUILD_TOOLS
-If CW_CC or CW_CPLUSPLUS are not set,
-these variables define the search path for Studio compilers as
-follows:
-.B
-If CW_CC_DIR is set, the Studio C compiler in \fI$CW_CC_DIR\fP
-will be used.  Likewise, if CW_CPLUSPLUS_DIR is set, the Studio C++
-compiler in \fI$CW_CPLUSPLUS_DIR\fP will be used.
-Otherwise, if SPRO_VROOT is set, the Studio C and C++ compilers
-in \fI$SPRO_VROOT/bin\fP will be used.
-Otherwise, if SPRO_ROOT is set, the Studio C and C++ compilers
-in \fI$SPRO_ROOT/SS12/bin\fP will be used.
-Otherwise, if BUILD_TOOLS is set, the Studio C and C++ compilers
-in \fI$BUILD_TOOLS/SUNWspro/SS12/bin\fP will be used.
-Otherwise, the Studio compilers in a predefined default location
-will be used.
-.LP
-.TP 4
-.B CW_GCC, CW_GPLUSPLUS
-If these variables are set in the environment, they specify the full
-pathname for the GNU C and C++ compilers, respectively.
-.LP
-.TP 4
-.B CW_GCC_DIR, CW_GPLUSPLUS_DIR, GNU_ROOT
-If CW_GCC or CW_GPLUSPLUS are not set,
-these variables alter the search path for GNU compilers in a manner
-similar to that described above for the Studio compilers.  Specifically:
-.B
-If CW_GCC_DIR is set, the GNU C compiler in \fI$CW_GCC_DIR\fP
-will be used.  Likewise, if CW_GPLUSPLUS_DIR is set, the GNU C++
-compiler in \fI$CW_GPLUSPLUS_DIR\fP will be used.
-Otherwise, if GNU_ROOT is set, the GNU C and C++ compilers
-in \fI$GCC_ROOT/bin\fP will be used.
-Otherwise, the GNU compilers in a predefined default location
-will be used.
-.LP
-.SH EXIT STATUS
-.LP
-The following exit status values are returned:
-.IP "\fB0\fR" 4
-.IX Item "0"
-The primary compiler, and shadow compiler if invoked, both completed
-successfully.
-.IP "\fB>0\fR" 4
-.IX Item ">0"
-A usage error occurred, or one or more compilers returned a nonzero
-exit status.
-.LP
-.SH BUGS
-.LP
-The translations provided for gcc are not always exact and in some
-cases reflect local ON policy rather than actual equivalence.
-.LP
-Additional compiler types should be supported.
-.LP
-The translation engine is hacky.
-.LP
-.SH SEE ALSO
-.LP
-cc(1), CC(1), gcc(1)
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/cw/cw.1onbld	Wed Sep 30 19:35:36 2015
@@ -0,0 +1,261 @@
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2010 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.TH cw 1ONBLD "22 March 2010"
+.SH NAME
+.I cw
+\- invoke one or more compilers with argument translation
+.SH SYNOPSIS
+\fBcw {-_cc|-_gcc|-_CC|-_g++} [options] [compiler args...]\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "cw" "" "\fBcw\fP"
+.LP
+.I cw
+is a facility for invoking one or more compilers, providing
+translation from Sun Studio arguments as appropriate.  This allows
+the use of arbitrary compilers without the need to alter large
+numbers of makefiles.  A mode called shadow compilation, the default,
+invokes two different compilers so that warnings and errors may be
+obtained from both.  See SHADOW COMPILATION for details.  This version
+of cw supports Sun Studio 10 and 11 and gcc 3.4.3 as shipped in
+Solaris.
+.LP
+.SH ARGUMENTS
+.LP
+Exactly one of the following arguments is required, and must appear
+immediately following \fBcw\fP in the argument list:
+.TP 4
+.B \-_cc
+Select Sun Studio C (cc) as the primary compiler.
+.TP 4
+.B \-_gcc
+Select GNU C (gcc) as the primary compiler.
+.TP 4
+.B \-_CC
+Select Sun Studio C++ (CC) as the primary compiler.
+.TP 4
+.B \-_g++
+Select GNU C++ (g++) as the primary compiler.
+.LP
+.SH OPTIONS
+.LP
+The following options are supported:
+.TP 4
+.B \-_compiler
+Do not invoke any compiler; instead, write to standard output the
+full path to the primary compiler that would be invoked.  If this
+option is given, it must appear immediately following the compiler
+selection argument, and all other options will be disregarded.
+.LP
+.TP 4
+.B \-_versions
+Print the cw version, followed in turn by the path to and versions
+of each compiler which would be invoked.  If this option is given,
+it must appear immediately following the compiler selection argument,
+and all other options will be disregarded.
+.LP
+.TP 4
+.B \-_noecho
+Normally, cw writes to standard error the actual compiler commands
+invoked, each prefixed with '+'.  This option suppresses these
+messages.
+.LP
+.TP 4
+.B \-_cc=,\-_gcc=,\-_CC=,\-g++=
+Pass compiler-dependent options.  See ARGUMENT TRANSLATION.
+.LP
+.SH SHADOW COMPILATION
+.LP
+Unless otherwise directed by environment variables (see ENVIRONMENT),
+\fBcw\fP will invoke both the compiler specified by its first argument
+(primary) and a designated alternate compiler (shadow).  The primary
+compiler will be invoked with the arguments given to cw, translated
+as described in ARGUMENT TRANSLATION.  The secondary compiler will be
+invoked in parallel with the primary (but see ENVIRONMENT); its
+arguments will likewise be translated.  However, the shadow compiler's
+arguments will also be modified as follows:
+.LP
+.TP 4
+.B 1.
+If none of \fI-c\fP, \fI-E\fP, \fI-P\fP, or \fI-S\fP appears in the
+argument list (that is, linking is attempted), the shadow compiler
+will not be invoked.  This is because the objects built with that
+compiler which would be linked have been previously discarded.
+.LP
+.TP 4
+.B 2.
+If an option of the form \fI-ofilename\fP was provided, it will be
+replaced by two options of the form \fI-o\fP \fItempfile\fP.
+.LP
+.TP 4
+.B 3.
+If the option \fI-o\fP was provided, its following argument will be
+replaced by \fItempfile\fP.
+.LP
+.TP 4
+.B 4.
+If neither of the above options was provided, two options of the
+form \fI-o\fP \fItempfile\fP will be added to the end of the argument
+list used to invoke the shadow compiler.
+.LP
+In all three cases, \fItempfile\fP is the name of a temporary file
+which will be removed by \fBcw\fP before it terminates.
+.LP
+When shadow compilation is in effect, \fBcw\fP writes to standard error
+each compiler's standard error output following its argument list.
+Messages from the two compilers will not be interleaved.  If \fBcw\fP
+is used to invoke the preprocessor and no output location is specified,
+\fBcw\fP will write to standard output the primary compiler's
+standard output, and the secondary compiler's standard output will
+be discarded.
+.LP
+Because the Studio compilers write intermediate objects to fixed
+filenames in the current directory when instructed to compile and
+link multiple source files via a single command line, it would be
+unsafe to invoke more than one compiler in this fashion.  Therefore
+\fBcw\fP does not accept multiple source files unless the
+preprocessor is to be invoked.  An attempt to invoke \fBcw\fP in
+this manner will result in an error.
+.LP
+.SH ARGUMENT TRANSLATION
+.LP
+The arguments provided to \fBcw\fP will be passed through to each
+compiler invoked, altered as follows:
+.LP
+.TP 4
+.B 1.
+Options intended for \fBcw\fP itself are removed.
+.LP
+.TP 4
+.B 2.
+The shadow compiler's arguments are modified as described in
+SHADOW COMPILATION so that its output is discarded.
+.LP
+.TP 4
+.B 3.
+If the compiler to be invoked is a GNU C or C++ compiler, a set of
+default flags is added to the beginning of the argument list, and the
+remaining arguments are translated to their closest appropriate
+semantic equivalents and passed in the same order as their
+counterparts given to \fBcw\fP.  Arguments which begin with
+\fI-_gcc=\fP or \fI-_g++=\fP will be passed in place with the
+leading portion removed.  Arguments which begin with \fI-_cc=\fP or
+\fI-_CC=\fP will be discarded.  See the comments at the head of
+\fIusr/src/tools/cw/cw.c\fP for a detailed list of translations.
+.LP
+.TP 4
+.B 4.
+If the compiler to be invoked is a Studio C or C++ compiler, the
+remaining arguments are passed unmodified and in the same order as
+given to \fBcw\fP.  Arguments which begin with \fI-_cc=\fP or
+\fI-_CC=\fP will be passed in place with the leading portion removed.
+Arguments which begin with \fI-_gcc=\fP or \fI-_g++=\fP will be
+discarded.
+.LP
+.SH ENVIRONMENT
+.LP
+.TP 4
+.B CW_NO_SHADOW
+If this variable is set in the environment, invoke only the
+primary compiler.
+.LP
+.TP 4
+.B CW_SHADOW_SERIAL
+If this variable is set in the environment, invoke the primary compiler,
+wait for it to complete, then invoke the shadow compiler.  Normally
+the two compilers are invoked in parallel.  If CW_NO_SHADOW is set,
+this has no effect.
+.LP
+.TP 4
+.B CW_NO_EXEC
+If this variable is set in the environment, write the usual output to
+standard error but do not actually invoke any compiler.  This is
+useful for debugging the translation engine.
+.LP
+.TP 4
+.B CW_CC, CW_CPLUSPLUS
+If these variables are set in the environment, they specify the full
+pathname for the Studio C and C++ compilers, respectively.
+.LP
+.TP 4
+.B CW_CC_DIR, CW_CPLUSPLUS_DIR, SPRO_VROOT, SPRO_ROOT, BUILD_TOOLS
+If CW_CC or CW_CPLUSPLUS are not set,
+these variables define the search path for Studio compilers as
+follows:
+.B
+If CW_CC_DIR is set, the Studio C compiler in \fI$CW_CC_DIR\fP
+will be used.  Likewise, if CW_CPLUSPLUS_DIR is set, the Studio C++
+compiler in \fI$CW_CPLUSPLUS_DIR\fP will be used.
+Otherwise, if SPRO_VROOT is set, the Studio C and C++ compilers
+in \fI$SPRO_VROOT/bin\fP will be used.
+Otherwise, if SPRO_ROOT is set, the Studio C and C++ compilers
+in \fI$SPRO_ROOT/SS12/bin\fP will be used.
+Otherwise, if BUILD_TOOLS is set, the Studio C and C++ compilers
+in \fI$BUILD_TOOLS/SUNWspro/SS12/bin\fP will be used.
+Otherwise, the Studio compilers in a predefined default location
+will be used.
+.LP
+.TP 4
+.B CW_GCC, CW_GPLUSPLUS
+If these variables are set in the environment, they specify the full
+pathname for the GNU C and C++ compilers, respectively.
+.LP
+.TP 4
+.B CW_GCC_DIR, CW_GPLUSPLUS_DIR, GNU_ROOT
+If CW_GCC or CW_GPLUSPLUS are not set,
+these variables alter the search path for GNU compilers in a manner
+similar to that described above for the Studio compilers.  Specifically:
+.B
+If CW_GCC_DIR is set, the GNU C compiler in \fI$CW_GCC_DIR\fP
+will be used.  Likewise, if CW_GPLUSPLUS_DIR is set, the GNU C++
+compiler in \fI$CW_GPLUSPLUS_DIR\fP will be used.
+Otherwise, if GNU_ROOT is set, the GNU C and C++ compilers
+in \fI$GCC_ROOT/bin\fP will be used.
+Otherwise, the GNU compilers in a predefined default location
+will be used.
+.LP
+.SH EXIT STATUS
+.LP
+The following exit status values are returned:
+.IP "\fB0\fR" 4
+.IX Item "0"
+The primary compiler, and shadow compiler if invoked, both completed
+successfully.
+.IP "\fB>0\fR" 4
+.IX Item ">0"
+A usage error occurred, or one or more compilers returned a nonzero
+exit status.
+.LP
+.SH BUGS
+.LP
+The translations provided for gcc are not always exact and in some
+cases reflect local ON policy rather than actual equivalence.
+.LP
+Additional compiler types should be supported.
+.LP
+The translation engine is hacky.
+.LP
+.SH SEE ALSO
+.LP
+cc(1), CC(1), gcc(1)
--- old/usr/src/tools/depcheck/Makefile	Wed Sep 30 19:35:36 2015
+++ new/usr/src/tools/depcheck/Makefile	Wed Sep 30 19:35:36 2015
@@ -31,21 +31,21 @@
 	SampleLinks \
 	SamplePkgLinks
 
-MAN1FILES= \
-	get_depend_info.1 \
-	make_pkg_db.1
+MAN1ONBLDFILES= \
+	get_depend_info.1onbld \
+	make_pkg_db.1onbld
 
 include ../Makefile.tools
 
 $(ROOTONBLDETCFILES) := FILEMODE=	644
-$(ROOTONBLDMAN1FILES) := FILEMODE=	644
+$(ROOTONBLDMAN1ONBLDFILES) := FILEMODE=	644
 
 .KEEP_STATE:
 
-all:	$(SHFILES) $(MAN1FILES)
+all:	$(SHFILES) $(MAN1ONBLDFILES)
 
 install: all .WAIT $(ROOTONBLDSHFILES) $(ROOTONBLDETCFILES) \
-	$(ROOTONBLDMAN1FILES)
+	$(ROOTONBLDMAN1ONBLDFILES)
 
 clean:
 	$(RM) $(CLEANFILES)
--- old/usr/src/tools/depcheck/get_depend_info.1	Wed Sep 30 19:35:36 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,200 +0,0 @@
-'\" t
-.\" 
-.\" CDDL HEADER START
-.\" 
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License, Version 1.0 only
-.\" (the "License").  You may not use this file except in compliance
-.\" with the License.
-.\" 
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\" 
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\" 
-.\" CDDL HEADER END
-.\" 
-.\" 
-.\" Copyright (c) 2005 Sun Microsystems, Inc. All rights reserved.
-.\" Use is subject to license terms.
-.\" 
-.TH GET_DEPEND_INFO 1 "Nov 2, 2000"
-.SH "NAME"
-get_depend_info \- get dependency information about a package or a file
-.SH "SYNOPSIS"
-.PP
-.nf
-\fBget_depend_info\fR [-\fBcons\fR] \-\fBdbdir\fR \fIdbm_database_pathname\fR
-                [-\fBf\fR | -\fBp\fR] [-\fBh\fR] [-\fBroot\fR \fIroot_pathname\fR]
-                [-\fBs\fR] [-\fBpkg\fR \fISUN_package\fR | \fIfilename\fR \&...]
-.fi
-.SH "DESCRIPTION"
-.PP
-The \fBget_depend_info\fR command prints dependency information about a package,
-a file, or a set of files on the standard output\&.
-.SH "OPTIONS"
-.PP
-The following options are supported:
-.sp
-.ne 2
-\fB-\fBcons\fR\fR
-.in +16n
-Turns on conservative mode, that is, refrains from using
-\fB/usr/bin/strings\fR\&.
-.sp
-.sp 1
-.in -16n
-.sp
-.ne 2
-\fB-\fBdbdir\fR\fR
-.in +16n
-Specifies the directory in which the Perl DBM databases generated by
-\fBmake_pkg_db\fR(1) are located\&.
-.sp
-.sp 1
-.in -16n
-.sp
-.ne 2
-\fB-\fBf\fR\fR
-.in +16n
-Outputs file dependencies only\&.
-.sp
-.sp 1
-.in -16n
-.sp
-.ne 2
-\fB-\fBh\fR\fR
-.in +16n
-Displays help\&.
-.sp
-.sp 1
-.in -16n
-.sp
-.ne 2
-\fB-\fBp\fR\fR
-.in +16n
-Outputs package dependencies only\&.
-.sp
-.sp 1
-.in -16n
-.sp
-.ne 2
-\fB-\fBpkg\fR\fR
-.in +16n
-Specifies a particular package on which you want to run the dependency
-analysis\&. You must specify this option if you specify either a Sun software
-package or a third-party software package that conforms with the Sun package
-format (\fISUN_package\fR)\&.
-.sp
-.sp 1
-.in -16n
-.sp
-.ne 2
-\fB-\fBroot\fR\fR
-.in +16n
-Specifies an alternate root\&. You must also use the -\fBpkg\fR option if you
-use this option\&.
-.sp
-.sp 1
-.in -16n
-.sp
-.ne 2
-\fB-\fBs\fR\fR
-.in +16n
-Outputs symbolic links for files or packages only\&.
-.sp
-.sp 1
-.in -16n
-.SH "OPERANDS"
-.PP
-The following operands are supported:
-.sp
-.ne 2
-\fB\fIdbm_database_pathname\fR\fR
-.in +24n
-Specifies the path name of the directory in which the Perl DBM databases
-generated by \fBmake_pkg_db\fR are located\&.
-.sp
-.sp 1
-.in -24n
-.sp
-.ne 2
-\fB\fIfilename\fR\fR
-.in +24n
-Specifies the name of a file or files on which you want to run the dependency
-analysis\&.
-.sp
-.sp 1
-.in -24n
-.sp
-.ne 2
-\fB\fIroot_pathname\fR\fR
-.in +24n
-Specifies the path name of an alternate root you want to use\&.
-.sp
-.sp 1
-.in -24n
-.sp
-.ne 2
-\fB\fISUN_package\fR\fR
-.in +24n
-Specifies the name of a particular Sun software package (or any third-party
-software package that conforms with the Sun package format) on which you want
-to run the dependency analysis\&. You must use the -\fBpkg\fR option if you
-specify this operand\&.
-.sp
-.sp 1
-.in -24n
-.PP
-You can specify either a Sun software package or a file name, but not both\&.
-.SH "EXAMPLES"
-.PP
-\fBExample 1:\fR To Get a Dependency Analysis of Two Particular Files
-.PP
-.nf
-% get_depend_info -dbdir MyDir /usr/bin/ls /usr/bin/man
-.fi
-.PP
-\fBExample 2:\fR To Get a Dependency Analysis of Files Using a Wild Card
-.PP
-.nf
-% get_depend_info -dbdir MyDir /usr/sbin/*
-.fi
-.PP
-\fBExample 3:\fR To Get a Dependency Analysis of a Package in Sun Format
-.PP
-.nf
-% get_depend_info -dbdir MyDir -pkg NSCPcom
-% get_depend_info -dbdir MyDir -pkg SUNWnisu
-.fi
-.PP
-\fBExample 4:\fR To Display Help
-.PP
-.nf
-% get_depend_info -h
-.fi
-.SH "ATTRIBUTES"
-.PP
-See \fBattributes\fR(5) for descriptions of the following attributes:
-.sp
-.TS
-box;
-c | c
-l | l .
-ATTRIBUTE TYPE	ATTRIBUTE VALUE
-_
-Availability	SUNWonbld
-CSI	Enabled
-Interface Stability	Evolving
-MT-Level	Unsafe
-.TE
-.sp
-.SH "SEE ALSO"
-.PP
-\fBmake_pkg_db\fR(1), \fBattributes\fR(5)
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/depcheck/get_depend_info.1onbld	Wed Sep 30 19:35:36 2015
@@ -0,0 +1,200 @@
+'\" t
+.\" 
+.\" CDDL HEADER START
+.\" 
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License, Version 1.0 only
+.\" (the "License").  You may not use this file except in compliance
+.\" with the License.
+.\" 
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\" 
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\" 
+.\" CDDL HEADER END
+.\" 
+.\" 
+.\" Copyright (c) 2005 Sun Microsystems, Inc. All rights reserved.
+.\" Use is subject to license terms.
+.\" 
+.TH GET_DEPEND_INFO 1ONBLD "Nov 2, 2000"
+.SH "NAME"
+get_depend_info \- get dependency information about a package or a file
+.SH "SYNOPSIS"
+.PP
+.nf
+\fBget_depend_info\fR [-\fBcons\fR] \-\fBdbdir\fR \fIdbm_database_pathname\fR
+                [-\fBf\fR | -\fBp\fR] [-\fBh\fR] [-\fBroot\fR \fIroot_pathname\fR]
+                [-\fBs\fR] [-\fBpkg\fR \fISUN_package\fR | \fIfilename\fR \&...]
+.fi
+.SH "DESCRIPTION"
+.PP
+The \fBget_depend_info\fR command prints dependency information about a package,
+a file, or a set of files on the standard output\&.
+.SH "OPTIONS"
+.PP
+The following options are supported:
+.sp
+.ne 2
+\fB-\fBcons\fR\fR
+.in +16n
+Turns on conservative mode, that is, refrains from using
+\fB/usr/bin/strings\fR\&.
+.sp
+.sp 1
+.in -16n
+.sp
+.ne 2
+\fB-\fBdbdir\fR\fR
+.in +16n
+Specifies the directory in which the Perl DBM databases generated by
+\fBmake_pkg_db\fR(1ONBLD) are located\&.
+.sp
+.sp 1
+.in -16n
+.sp
+.ne 2
+\fB-\fBf\fR\fR
+.in +16n
+Outputs file dependencies only\&.
+.sp
+.sp 1
+.in -16n
+.sp
+.ne 2
+\fB-\fBh\fR\fR
+.in +16n
+Displays help\&.
+.sp
+.sp 1
+.in -16n
+.sp
+.ne 2
+\fB-\fBp\fR\fR
+.in +16n
+Outputs package dependencies only\&.
+.sp
+.sp 1
+.in -16n
+.sp
+.ne 2
+\fB-\fBpkg\fR\fR
+.in +16n
+Specifies a particular package on which you want to run the dependency
+analysis\&. You must specify this option if you specify either a Sun software
+package or a third-party software package that conforms with the Sun package
+format (\fISUN_package\fR)\&.
+.sp
+.sp 1
+.in -16n
+.sp
+.ne 2
+\fB-\fBroot\fR\fR
+.in +16n
+Specifies an alternate root\&. You must also use the -\fBpkg\fR option if you
+use this option\&.
+.sp
+.sp 1
+.in -16n
+.sp
+.ne 2
+\fB-\fBs\fR\fR
+.in +16n
+Outputs symbolic links for files or packages only\&.
+.sp
+.sp 1
+.in -16n
+.SH "OPERANDS"
+.PP
+The following operands are supported:
+.sp
+.ne 2
+\fB\fIdbm_database_pathname\fR\fR
+.in +24n
+Specifies the path name of the directory in which the Perl DBM databases
+generated by \fBmake_pkg_db\fR are located\&.
+.sp
+.sp 1
+.in -24n
+.sp
+.ne 2
+\fB\fIfilename\fR\fR
+.in +24n
+Specifies the name of a file or files on which you want to run the dependency
+analysis\&.
+.sp
+.sp 1
+.in -24n
+.sp
+.ne 2
+\fB\fIroot_pathname\fR\fR
+.in +24n
+Specifies the path name of an alternate root you want to use\&.
+.sp
+.sp 1
+.in -24n
+.sp
+.ne 2
+\fB\fISUN_package\fR\fR
+.in +24n
+Specifies the name of a particular Sun software package (or any third-party
+software package that conforms with the Sun package format) on which you want
+to run the dependency analysis\&. You must use the -\fBpkg\fR option if you
+specify this operand\&.
+.sp
+.sp 1
+.in -24n
+.PP
+You can specify either a Sun software package or a file name, but not both\&.
+.SH "EXAMPLES"
+.PP
+\fBExample 1:\fR To Get a Dependency Analysis of Two Particular Files
+.PP
+.nf
+% get_depend_info -dbdir MyDir /usr/bin/ls /usr/bin/man
+.fi
+.PP
+\fBExample 2:\fR To Get a Dependency Analysis of Files Using a Wild Card
+.PP
+.nf
+% get_depend_info -dbdir MyDir /usr/sbin/*
+.fi
+.PP
+\fBExample 3:\fR To Get a Dependency Analysis of a Package in Sun Format
+.PP
+.nf
+% get_depend_info -dbdir MyDir -pkg NSCPcom
+% get_depend_info -dbdir MyDir -pkg SUNWnisu
+.fi
+.PP
+\fBExample 4:\fR To Display Help
+.PP
+.nf
+% get_depend_info -h
+.fi
+.SH "ATTRIBUTES"
+.PP
+See \fBattributes\fR(5) for descriptions of the following attributes:
+.sp
+.TS
+box;
+c | c
+l | l .
+ATTRIBUTE TYPE	ATTRIBUTE VALUE
+_
+Availability	SUNWonbld
+CSI	Enabled
+Interface Stability	Evolving
+MT-Level	Unsafe
+.TE
+.sp
+.SH "SEE ALSO"
+.PP
+\fBmake_pkg_db\fR(1ONBLD), \fBattributes\fR(5)
--- old/usr/src/tools/depcheck/make_pkg_db.1	Wed Sep 30 19:35:37 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,196 +0,0 @@
-'\" t
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License, Version 1.0 only
-.\" (the "License").  You may not use this file except in compliance
-.\" with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\"
-.\" Copyright (c) 2005 Sun Microsystems, Inc. All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.TH MAKE_PKG_DB 1 "Nov 2, 2000"
-.SH "NAME"
-make_pkg_db \- create a Perl DBM database of installed software
-.SH "SYNOPSIS"
-.PP
-.nf
-\fBmake_pkg_db\fR \-\fBdbdir\fR \fIdbm_database_pathname\fR\ [-\fBh\fR]
-            [-\fBifiles\fR \fIfilename\fR\&...]
-            [-\fBpkgdef\fR \fIpackage_pool_pathname\fR]
-.fi
-.SH "DESCRIPTION"
-.PP
-The \fBmake_pkg_db\fR command (a Perl script) generates a Perl DBM database of
-software installed on a system based on \fB/var/sadm/install/contents\fR or the
-contents of a package pool directory\&. The Perl DBM database files are used by
-\fBget_depend_info\fR(1)\&.
-.PP
-The Perl DBM database files contain information keyed on a file name\&. Some
-files, for example, list the package in which a file is included and the
-permissions of the file\&.
-.PP
-If you run \fBmake_pkg_db\ -dbdir\ \fIdbm_database_pathname\fR\fR, an error
-message such as:
-.PP
-\fB***CANNOT RESOLVE ABSOLUTE PATH /usr/java/bin/appletviewer\fR
-.PP
-is generated because the script cannot resolve symbolic links based on the
-information in \fB/var/sadm/install/contents\fR\&. In
-\fB/var/sadm/install/contents\fR, for example, \fBappletviewer\fR is specified
-as a symbolic link:
-.sp
-.nf
-\f(CW/usr/bin/appletviewer=\&.\&./java/bin/appletviewer s none SUNWj2dev\fR
-.fi
-.sp
-.PP
-Unfortunately, \fB/usr/java\fR is a symbolic link to \fB/usr/java1\&.2\fR\&.
-The correct file entry in \fB/var/sadm/install/contents\fR is therefore
-\fB/usr/java1\&.2/bin/appletviewer\fR\&. It is impossible for this script to
-resolve this link based on the information in
-\fB/var/sadm/install/contents\fR\&.
-.PP
-To correct this problem, create a file named \fBMyLinkResolution\fR and add
-this entry:
-.sp
-.nf
-\f(CW/usr/bin/appletviewer=\&.\&./java1\&.2/bin/appletviewer s none SUNWj2dev\fR
-.fi
-.sp
-.PP
-Then enter this command:
-.PP
-.sp
-.nf
-\f(CWmake_pkg_db -dbdir \fIdbm_database_pathname\fR -ifiles MyLinkResolution\fR
-.fi
-.sp
-When you execute this command, the following message is displayed:
-.sp
-.nf
-\f(CW\&.\&.\&.OVERRIDDEN: /usr/bin/appletviewer=
-\&.\&./java/bin/appletviewer s none SUNWj2dev\fR
-.fi
-.sp
-.PP
-This message indicates that the original entry in
-\fB/var/sadm/install/contents\fR is ignored and your new entry in
-\fBMyLinkResolution\fR is used instead\&.
-.PP
-\fBSampleLinks\fR is a file you can use to resolve links in
-\fB/var/sadm/install/contents\fR for Solaris (Intel Platform Edition)\&.
-\fBSamplePkgLinks\fR is a file you can use to resolve some of the links used on
-the Solaris 8 Software 1 of 2 Intel Platform Edition CD\&. You might want to
-modify these two preceding files for SPARC or for your particular environment\&.
-.PP
-The \fBmake_pkg_db\fR script verifies the files it finds against the software
-that is actually installed on the system\&. The more complete the information,
-the more accurate the output of the script\&.
-.SH "OPTIONS"
-.PP
-The following options are supported:
-.sp
-.ne 2
-\fB-\fBdbdir\fR\fR
-.in +16n
-Specifies the directory in which you want to place the output Perl DBM
-databases\&.
-.sp
-.sp 1
-.in -16n
-.sp
-.ne 2
-\fB-\fBh\fR\fR
-.in +16n
-Displays help\&.
-.sp
-.sp 1
-.in -16n
-.sp
-.ne 2
-\fB-\fBifiles\fR\fR
-.in +16n
-Specifies the name of an input file you want to use to help in resolving
-symbolic links\&.
-.sp
-.sp 1
-.in -16n
-.sp
-.ne 2
-\fB-\fBpkgdef\fR\fR
-.in +16n
-Specifies the path name of the package pool you want to use instead of
-\fB/var/sadm/install/contents\fR\&.
-.sp
-.sp 1
-.in -16n
-.SH "OPERANDS"
-.PP
-The following operands are supported:
-.sp
-.ne 2
-\fB\fIdbm_database_pathname\fR\fR
-.in +24n
-Specifies the directory in which you want to place the output Perl DBM
-databases\&.
-.sp
-.sp 1
-.in -24n
-.sp
-.ne 2
-\fB\fIfilename\fR\fR
-.in +24n
-Specifies the name of a file or files that contain data in the format used in
-\fB/var/sadm/install/contents\fR\&.
-.sp
-.sp 1
-.in -24n
-.sp
-.ne 2
-\fB\fIpackage_pool_pathname\fR\fR
-.in +24n
-Specifies the path name of the package pool you want to use instead of
-\fB/var/sadm/install/contents\fR\&.
-.sp
-.sp 1
-.in -24n
-.SH "ATTRIBUTES"
-.PP
-See \fBattributes\fR(5) for descriptions of the following attributes:
-.sp
-.TS
-box;
-cw | cw
-lw | lw .
-ATTRIBUTE TYPE	ATTRIBUTE VALUE
-Availability	SUNWonbld
-CSI	Enabled
-Interface Stability	Evolving
-MT-Level	Unsafe
-.TE
-.sp
-.SH "SEE ALSO"
-.PP
-\fBget_depend_info\fR(1), \fBattributes\fR(5)
-.SH "NOTES"
-.PP
-DBM database files are platform dependent\&. DBM database files you generate on
-a SPARC machine, for example, do not work on an IA machine (and vice-versa)\&.
-.PP
-This script might not resolve all symbolic links\&.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/depcheck/make_pkg_db.1onbld	Wed Sep 30 19:35:37 2015
@@ -0,0 +1,196 @@
+'\" t
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License, Version 1.0 only
+.\" (the "License").  You may not use this file except in compliance
+.\" with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\"
+.\" Copyright (c) 2005 Sun Microsystems, Inc. All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.TH MAKE_PKG_DB 1ONBLD "Nov 2, 2000"
+.SH "NAME"
+make_pkg_db \- create a Perl DBM database of installed software
+.SH "SYNOPSIS"
+.PP
+.nf
+\fBmake_pkg_db\fR \-\fBdbdir\fR \fIdbm_database_pathname\fR\ [-\fBh\fR]
+            [-\fBifiles\fR \fIfilename\fR\&...]
+            [-\fBpkgdef\fR \fIpackage_pool_pathname\fR]
+.fi
+.SH "DESCRIPTION"
+.PP
+The \fBmake_pkg_db\fR command (a Perl script) generates a Perl DBM database of
+software installed on a system based on \fB/var/sadm/install/contents\fR or the
+contents of a package pool directory\&. The Perl DBM database files are used by
+\fBget_depend_info\fR(1ONBLD)\&.
+.PP
+The Perl DBM database files contain information keyed on a file name\&. Some
+files, for example, list the package in which a file is included and the
+permissions of the file\&.
+.PP
+If you run \fBmake_pkg_db\ -dbdir\ \fIdbm_database_pathname\fR\fR, an error
+message such as:
+.PP
+\fB***CANNOT RESOLVE ABSOLUTE PATH /usr/java/bin/appletviewer\fR
+.PP
+is generated because the script cannot resolve symbolic links based on the
+information in \fB/var/sadm/install/contents\fR\&. In
+\fB/var/sadm/install/contents\fR, for example, \fBappletviewer\fR is specified
+as a symbolic link:
+.sp
+.nf
+\f(CW/usr/bin/appletviewer=\&.\&./java/bin/appletviewer s none SUNWj2dev\fR
+.fi
+.sp
+.PP
+Unfortunately, \fB/usr/java\fR is a symbolic link to \fB/usr/java1\&.2\fR\&.
+The correct file entry in \fB/var/sadm/install/contents\fR is therefore
+\fB/usr/java1\&.2/bin/appletviewer\fR\&. It is impossible for this script to
+resolve this link based on the information in
+\fB/var/sadm/install/contents\fR\&.
+.PP
+To correct this problem, create a file named \fBMyLinkResolution\fR and add
+this entry:
+.sp
+.nf
+\f(CW/usr/bin/appletviewer=\&.\&./java1\&.2/bin/appletviewer s none SUNWj2dev\fR
+.fi
+.sp
+.PP
+Then enter this command:
+.PP
+.sp
+.nf
+\f(CWmake_pkg_db -dbdir \fIdbm_database_pathname\fR -ifiles MyLinkResolution\fR
+.fi
+.sp
+When you execute this command, the following message is displayed:
+.sp
+.nf
+\f(CW\&.\&.\&.OVERRIDDEN: /usr/bin/appletviewer=
+\&.\&./java/bin/appletviewer s none SUNWj2dev\fR
+.fi
+.sp
+.PP
+This message indicates that the original entry in
+\fB/var/sadm/install/contents\fR is ignored and your new entry in
+\fBMyLinkResolution\fR is used instead\&.
+.PP
+\fBSampleLinks\fR is a file you can use to resolve links in
+\fB/var/sadm/install/contents\fR for Solaris (Intel Platform Edition)\&.
+\fBSamplePkgLinks\fR is a file you can use to resolve some of the links used on
+the Solaris 8 Software 1 of 2 Intel Platform Edition CD\&. You might want to
+modify these two preceding files for SPARC or for your particular environment\&.
+.PP
+The \fBmake_pkg_db\fR script verifies the files it finds against the software
+that is actually installed on the system\&. The more complete the information,
+the more accurate the output of the script\&.
+.SH "OPTIONS"
+.PP
+The following options are supported:
+.sp
+.ne 2
+\fB-\fBdbdir\fR\fR
+.in +16n
+Specifies the directory in which you want to place the output Perl DBM
+databases\&.
+.sp
+.sp 1
+.in -16n
+.sp
+.ne 2
+\fB-\fBh\fR\fR
+.in +16n
+Displays help\&.
+.sp
+.sp 1
+.in -16n
+.sp
+.ne 2
+\fB-\fBifiles\fR\fR
+.in +16n
+Specifies the name of an input file you want to use to help in resolving
+symbolic links\&.
+.sp
+.sp 1
+.in -16n
+.sp
+.ne 2
+\fB-\fBpkgdef\fR\fR
+.in +16n
+Specifies the path name of the package pool you want to use instead of
+\fB/var/sadm/install/contents\fR\&.
+.sp
+.sp 1
+.in -16n
+.SH "OPERANDS"
+.PP
+The following operands are supported:
+.sp
+.ne 2
+\fB\fIdbm_database_pathname\fR\fR
+.in +24n
+Specifies the directory in which you want to place the output Perl DBM
+databases\&.
+.sp
+.sp 1
+.in -24n
+.sp
+.ne 2
+\fB\fIfilename\fR\fR
+.in +24n
+Specifies the name of a file or files that contain data in the format used in
+\fB/var/sadm/install/contents\fR\&.
+.sp
+.sp 1
+.in -24n
+.sp
+.ne 2
+\fB\fIpackage_pool_pathname\fR\fR
+.in +24n
+Specifies the path name of the package pool you want to use instead of
+\fB/var/sadm/install/contents\fR\&.
+.sp
+.sp 1
+.in -24n
+.SH "ATTRIBUTES"
+.PP
+See \fBattributes\fR(5) for descriptions of the following attributes:
+.sp
+.TS
+box;
+cw | cw
+lw | lw .
+ATTRIBUTE TYPE	ATTRIBUTE VALUE
+Availability	SUNWonbld
+CSI	Enabled
+Interface Stability	Evolving
+MT-Level	Unsafe
+.TE
+.sp
+.SH "SEE ALSO"
+.PP
+\fBget_depend_info\fR(1ONBLD), \fBattributes\fR(5)
+.SH "NOTES"
+.PP
+DBM database files are platform dependent\&. DBM database files you generate on
+a SPARC machine, for example, do not work on an IA machine (and vice-versa)\&.
+.PP
+This script might not resolve all symbolic links\&.
--- old/usr/src/tools/findunref/Makefile	Wed Sep 30 19:35:37 2015
+++ new/usr/src/tools/findunref/Makefile	Wed Sep 30 19:35:37 2015
@@ -25,13 +25,13 @@
 #
 
 PROG	  = findunref
-MAN1FILES = findunref.1
+MAN1ONBLDFILES = findunref.1onbld
 CFLAGS += $(CCVERBOSE)
 LINTFLAGS += -ux
 
 include ../Makefile.tools
 
-$(ROOTONBLDMAN1FILES) := FILEMODE=      644
+$(ROOTONBLDMAN1ONBLDFILES) := FILEMODE=      644
 
 EXCEPTION_SRC= common open
 EXCEPTION_LISTS=	$(EXCEPTION_SRC:%=exception_list.%)
@@ -42,7 +42,7 @@
 
 all:    $(PROG) exception_list
 
-install: all .WAIT $(ROOTONBLDMACHPROG) $(ROOTONBLDMAN1FILES)
+install: all .WAIT $(ROOTONBLDMACHPROG) $(ROOTONBLDMAN1ONBLDFILES)
 
 lint:	lint_PROG
 
--- old/usr/src/tools/findunref/findunref.1	Wed Sep 30 19:35:37 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,101 +0,0 @@
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.TH findunref 1 "Oct 30, 2012"
-.I findunref
-\- find unused files in a source tree
-.SH SYNOPSIS
-findunref [\fB-s\fP \fIsubtree\fP] [\fB-t\fP \fItstampfile\fP]
-[\fB-S\fP \fBhg\fP|\fBtw\fP|\fBgit\fP] \fIsrcroot\fP \fIexceptfile\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "findunref" "" "\fBfindunref\fP"
-.LP
-The findunref utility lists the files in a source tree which have not been
-accessed more recently than a particular timestamp file.  Although
-findunref may be used on its own, it is usually invoked by
-\fBnightly\fP(1) to find files that are never referenced during a given
-build (see \fB-f\fP in \fBnightly\fP(1)).
-.LP
-The root of the source tree to examine is specified by \fIsrcroot\fP.  To
-simplify comparing findunref output from different source trees, findunref
-outputs all filenames relative to \fIsrcroot\fP.
-.LP
-Some files in a source tree may be intentionally unreferenced (e.g.,
-documentation) or only referenced during specialized types of builds.
-Accordingly, \fIexceptfile\fP names a file containing a list of pathname
-globs that will be ignored by findunref.  Within \fIexceptfile\fP, any
-lines consisting solely of whitespace or starting with \fB#\fP will be
-ignored.  Directory globs may also be specified, which will cause any
-matching directories to be skipped entirely.  If no exceptions are
-desired, \fIexceptfile\fP can be \fB/dev/null\fP.
-.LP
-Depending on how findunref is invoked, it can either check all files, or
-limit its checks to files under control of a specific source code
-management (SCM) system.
-.LP
-To limit checks to files managed by Mercurial, the \fBhg\fP(1) utility must be
-present in \fB$PATH\fP and any relevant repositories must be located at or
-under \fIsrcroot\fP.  Nested Mercurial repositories are supported.
-.LP
-To limit checks to files managed by Git, the \fBgit\fP(1) utility must be
-present in \fB$PATH\fP and any relevant repositories must be located at or
-under \fIsrcroot\fP.  Nested Git repositories are \fInot\fR supported.
-.SH OPTIONS
-.TP 10
-.B -s \fIsubtree\fP
-Only look under \fIsubtree\fP for unreferenced files.  By default, all
-directories under \fIsrcroot\fP are examined.
-.TP 10
-.B -t \fItstampfile\fP
-Consider files older than \fItstampfile\fP to be unreferenced.
-By default, \fIsrcroot\fB/.build.tstamp\fR is used.
-.TP 10
-.B -S \fBhg\fP|\fBtw\fP|\fBgit\fP
-Only check files that are managed by the specified SCM.  To simplify
-interaction with \fBwhich_scm\fP(1), the SCM names "mercurial" and
-"teamware" may also be specified for "hg" and "tw", respectively.
-By default, all files are checked.
-.SH SEE ALSO
-.LP
-\fBgit\fP(1),
-\fBhg\fP(1),
-\fBnightly\fP(1),
-\fBwhich_scm\fP(1)
-.SH NOTES
-Since many files are only used when building for a particular ISA (e.g.,
-Makefiles that are specific to x86 or SPARC), builds must be done on all
-applicable ISAs and the results merged.  For instance, if nightly builds
-(with \fB-f\fP) are done on both SPARC and x86, \fBusr/src\fP will be
-populated with a corresponding \fBunref-\fIisa\fB.out\fR file, which can
-be merged with \fBcomm\fP(1):
-.LP
-.nf
-comm -12 /path/to/unref-i386.out
-         /path/to/unref-sparc.out > unref.out
-.fi
-.LP
-This merged file can then be compared against the gate's latest
-unreferenced file list (e.g. \fB/ws/onnv-gate/usr/src/unrefmaster.out\fP).
-.LP
-Different gates have different unreferenced file policies.  Any changes to
-\fIexceptfile\fP that would define new unreferenced file policies for a
-given gate must be cleared with the appropriate gatekeepers.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/findunref/findunref.1onbld	Wed Sep 30 19:35:37 2015
@@ -0,0 +1,101 @@
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.TH findunref 1ONBLD "Oct 30, 2012"
+.I findunref
+\- find unused files in a source tree
+.SH SYNOPSIS
+findunref [\fB-s\fP \fIsubtree\fP] [\fB-t\fP \fItstampfile\fP]
+[\fB-S\fP \fBhg\fP|\fBtw\fP|\fBgit\fP] \fIsrcroot\fP \fIexceptfile\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "findunref" "" "\fBfindunref\fP"
+.LP
+The findunref utility lists the files in a source tree which have not been
+accessed more recently than a particular timestamp file.  Although
+findunref may be used on its own, it is usually invoked by
+\fBnightly\fP(1ONBLD) to find files that are never referenced during a given
+build (see \fB-f\fP in \fBnightly\fP(1ONBLD)).
+.LP
+The root of the source tree to examine is specified by \fIsrcroot\fP.  To
+simplify comparing findunref output from different source trees, findunref
+outputs all filenames relative to \fIsrcroot\fP.
+.LP
+Some files in a source tree may be intentionally unreferenced (e.g.,
+documentation) or only referenced during specialized types of builds.
+Accordingly, \fIexceptfile\fP names a file containing a list of pathname
+globs that will be ignored by findunref.  Within \fIexceptfile\fP, any
+lines consisting solely of whitespace or starting with \fB#\fP will be
+ignored.  Directory globs may also be specified, which will cause any
+matching directories to be skipped entirely.  If no exceptions are
+desired, \fIexceptfile\fP can be \fB/dev/null\fP.
+.LP
+Depending on how findunref is invoked, it can either check all files, or
+limit its checks to files under control of a specific source code
+management (SCM) system.
+.LP
+To limit checks to files managed by Mercurial, the \fBhg\fP(1) utility must be
+present in \fB$PATH\fP and any relevant repositories must be located at or
+under \fIsrcroot\fP.  Nested Mercurial repositories are supported.
+.LP
+To limit checks to files managed by Git, the \fBgit\fP(1) utility must be
+present in \fB$PATH\fP and any relevant repositories must be located at or
+under \fIsrcroot\fP.  Nested Git repositories are \fInot\fR supported.
+.SH OPTIONS
+.TP 10
+.B -s \fIsubtree\fP
+Only look under \fIsubtree\fP for unreferenced files.  By default, all
+directories under \fIsrcroot\fP are examined.
+.TP 10
+.B -t \fItstampfile\fP
+Consider files older than \fItstampfile\fP to be unreferenced.
+By default, \fIsrcroot\fB/.build.tstamp\fR is used.
+.TP 10
+.B -S \fBhg\fP|\fBtw\fP|\fBgit\fP
+Only check files that are managed by the specified SCM.  To simplify
+interaction with \fBwhich_scm\fP(1ONBLD), the SCM names "mercurial" and
+"teamware" may also be specified for "hg" and "tw", respectively.
+By default, all files are checked.
+.SH SEE ALSO
+.LP
+\fBgit\fP(1),
+\fBhg\fP(1),
+\fBnightly\fP(1ONBLD),
+\fBwhich_scm\fP(1ONBLD)
+.SH NOTES
+Since many files are only used when building for a particular ISA (e.g.,
+Makefiles that are specific to x86 or SPARC), builds must be done on all
+applicable ISAs and the results merged.  For instance, if nightly builds
+(with \fB-f\fP) are done on both SPARC and x86, \fBusr/src\fP will be
+populated with a corresponding \fBunref-\fIisa\fB.out\fR file, which can
+be merged with \fBcomm\fP(1):
+.LP
+.nf
+comm -12 /path/to/unref-i386.out
+         /path/to/unref-sparc.out > unref.out
+.fi
+.LP
+This merged file can then be compared against the gate's latest
+unreferenced file list (e.g. \fB/ws/onnv-gate/usr/src/unrefmaster.out\fP).
+.LP
+Different gates have different unreferenced file policies.  Any changes to
+\fIexceptfile\fP that would define new unreferenced file policies for a
+given gate must be cleared with the appropriate gatekeepers.
--- old/usr/src/tools/lintdump/Makefile	Wed Sep 30 19:35:37 2015
+++ new/usr/src/tools/lintdump/Makefile	Wed Sep 30 19:35:37 2015
@@ -25,18 +25,18 @@
 #
 
 PROG      = lintdump
-MAN1FILES = lintdump.1
+MAN1ONBLDFILES = lintdump.1onbld
 CFLAGS   += $(CCVERBOSE)
 
 include ../Makefile.tools
 
-$(ROOTONBLDMAN1FILES) := FILEMODE=	644
+$(ROOTONBLDMAN1ONBLDFILES) := FILEMODE=	644
 
 .KEEP_STATE:
 
 all:    $(PROG)
 
-install: all .WAIT $(ROOTONBLDMACHPROG) $(ROOTONBLDMAN1FILES)
+install: all .WAIT $(ROOTONBLDMACHPROG) $(ROOTONBLDMAN1ONBLDFILES)
 
 lint:	lint_PROG
 
--- old/usr/src/tools/lintdump/lintdump.1	Wed Sep 30 19:35:37 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,326 +0,0 @@
-.\" ident	"%Z%%M%	%I%	%E% SMI"
-.\" " CDDL HEADER START
-.\" "
-.\" " The contents of this file are subject to the terms of the
-.\" " Common Development and Distribution License (the "License").
-.\" " You may not use this file except in compliance with the License.
-.\" "
-.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" " or http://www.opensolaris.org/os/licensing.
-.\" " See the License for the specific language governing permissions
-.\" " and limitations under the License.
-.\" "
-.\" " When distributing Covered Code, include this CDDL HEADER in each
-.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" " If applicable, add the following below this CDDL HEADER, with the
-.\" " fields enclosed by brackets "[]" replaced with your own identifying
-.\" " information: Portions Copyright [yyyy] [name of copyright owner]
-.\" "
-.\" " CDDL HEADER END
-.\" "
-.\" "Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
-.\" "Use is subject to license terms.
-.TH lintdump 1 "28 Mar 2008"
-.I lintdump
-\- dump the contents of one or more lint objects
-.SH SYNOPSIS
-\fBlintdump [-i] [-p 1|2|3] [-r] \fIlintobj\fP [ \fIlintobj\fP ... ]
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "lintdump" "" "\fBlintdump\fP"
-.LP
-The lintdump utility dumps the contents of one or more lint
-objects.  This is chiefly useful when trying to understand the cause of
-unexpected or obtuse lint warnings (see EXAMPLES), but can also be used to
-find differences between lint objects across builds or releases, or to
-debug problems in lint itself.
-.LP
-A lint object is a binary file (typically suffixed with ".ln") constructed
-from a C source file via the "-c" option to lint(1).  Multiple lint
-objects may be combined into a lint library object (typically prefixed
-with "llib-l" and suffixed with ".ln") using the "-o" option to lint.  (As
-a convenience, lint "-o" allows a lint library object to be built directly
-from C source files). The lintdump utility is capable of dumping both
-traditional lint objects and lint library objects.
-.LP
-The format of a lint object is unstable and subject to change at any time,
-but its current structure is summarized here in order to aid in
-understanding the current output of lintdump.  A lint object consists of
-one or more lint modules (one per C source file).  Each lint module
-consists of a header and four sections, called PASS1, PASS2, PASS3, and
-STRINGS.  Generally speaking, PASS1 contains definitions, PASS2 contains
-declarations, and PASS3 contains information on whether or how functions
-or variables are used.  The STRINGS section holds the strings for
-printf(3C)/scanf(3C) checking.
-.LP
-Each PASS section consists of a sequence of binary records of assorted
-types.  The sequence of records is further partitioned by FILE records,
-which indicate the source or header file that is responsible for the
-records that follow.  The remaining record types provide lint with
-information about the functions, variables, and structures defined or used
-by the object. 
-.SH OPTIONS
-.TP 10
-.B -i
-Do not output structure tag IDs (see EXAMPLES).
-.TP 10
-.B -p 1|2|3
-Just output the PASS1, PASS2, or PASS3 section.
-.TP 10
-.B -r
-Output records using relative paths (see EXAMPLES).
-.LP
-.SH OUTPUT
-.LP
-The contents of each specified \fIlintobj\fP is dumped in command-line
-order.  For each \fIlintobj\fP, lintdump outputs a single line beginning
-with "LINTOBJ:" that provides its name.  For each lint module within that
-object, lintdump outputs a single line beginning with "LINTMOD:" that
-provides its module ID, the size of its PASS1, PASS2, PASS3, STRING
-sections, and its total size, in that order.
-.LP
-Next, unless the -p option is used, the contents of the PASS1, PASS2, and
-PASS3 sections are dumped, in order.  Before each section is dumped,
-lintdump outputs a single line beginning with "SECTION:" that
-provides the name and size of the section.  For each section,
-lintdump outputs each record in order.  The display format of each
-record depends on its type:
-.LP
-.B FILE RECORDS
-.RS 4
-Each FILE record is displayed on a single line beginning with "FILE:".
-Note that FILE records are often found in pairs, the first providing the
-absolute path to the file.  FILE records containing absolute paths are
-omitted if -r is used.  Other record types following a FILE record are
-indented to show their relationship to the FILE record.
-.RE
-.LP
-.B FUNCTION AND VARIABLE RECORDS
-.RS 4
-Each function or variable record is displayed on a single line using an
-extended version of the format used in The C Programming Language, Second
-Edition.  In particular, properties contained in the record that cannot be
-conveyed in C are displayed in angle brackets following definition or
-declaration; a full list of these and their meanings are given below in
-RECORD PROPERTIES.  In addition, note that some structures or unions may
-only be known by a numeric \fIID\fP, and thus output as "struct <tag
-\fIID\fP>".  This ID can be used to pair the structure with its definition
-via structure records.  If -i is used, then "struct <anon>" is printed
-instead.
-.RE
-.LP
-.B STRUCTURE AND UNION RECORDS
-.RS 4
-Each structure or union record is displayed using an extended version of
-the standard multi-line format used in The C Programming Language, Second
-Edition.  In particular, to facilitate problem analysis, unless -i is
-used, each structure or union definition includes a numeric ID enclosed in
-angle-brackets, such as "struct FILE <tag 1298> {".
-.RE
-.LP
-To illustrate each of the common record formats, suppose the following
-lint library is built:
-.LP
-.nf
-$ cat > liba.c
-/* LINTLIBRARY */
-/* PROTOLIB1 */
-int af(int);
-struct as {
-        char as_name[32];
-        int  as_flag;
-} as;
-$ lint -oa liba.c
-.fi
-.LP
-Then lintdump will produce the following output:
-.LP
-.nf
-LINTOBJ: llib-la.ln
-LINTMOD: 6484: 268+24+130+9 = 431 bytes
-SECTION: PASS1: 268 bytes
-   FILE: /home/meem/hacks/liba.c
-   FILE: liba.c
-         extern int af(int);
-         struct as as;
-         struct as <tag 98> {
-             char as_name[];
-             int as_flag;
-         };
-SECTION: PASS2: 24 bytes
-SECTION: PASS3: 130 bytes
-   FILE: /home/meem/hacks/liba.c
-   FILE: liba.c
-         int af(void) <returns value>;
-.fi
-.LP
-.SH RECORD PROPERTIES
-.LP
-As discussed in OUTPUT, some records are displayed using an extended
-format to convey information that cannot be expressed in C.  The following
-extended information may be displayed:
-.RE
-.LP
-.B <PRINTFLIKE\fIn\fP>
-.RS 4
-Indicates to lint that argument \fIn\fP to the variable-argument function
-is a format string in printf(3C) format, which enhances lint's argument
-checking.
-.RE
-.LP
-.B <SCANFLIKE\fIn\fP>
-.RS 4
-Indicates to lint that argument \fIn\fP to the variable-argument function
-is a format string in scanf(3C) format, which enhances lint's argument
-checking.
-.RE
-.LP
-.B <definition>
-.RS 4
-Indicates to lint that this record represents the definition of the given
-variable or function (rather than a declaration).
-.RE
-.LP
-.B <use: side-effects context>
-.RS 4
-Indicates to lint that the associated function is called in a context that
-suggests it has side effects.
-.RE
-.LP
-.B <use: return value context>
-.RS 4
-Indicates to lint that the associated function is called in a context where
-its return value is used.
-.RE
-.LP
-.B <use: unspecified context>
-.RS 4
-Indicates to lint that the associated function is used in an unspecified
-manner.
-.RE
-.LP
-.B <returns value>
-.RS 4
-Indicates to lint that the function returns a value.
-.RE
-.LP
-.SH EXAMPLES
-.LP
-One common problem is that lint does not always provide sufficient
-information to understand the reason for a type mismatch.  For instance,
-sometimes lint will confusingly report a type mismatch between
-apparently-identical types:
-.LP
-.nf
-$ lint msghdr.c -lsocket
-function argument ( number ) used inconsistently
-    recvmsg (arg 2) llib-lsocket:socket.h(437) struct msghdr * ::
-                                 msghdr.c(12)  struct msghdr *
-.fi
-.LP
-By using lintdump, we can pinpoint the problem by examining both
-definitions for \fIstruct msghdr\fP:
-.LP
-.nf
-$ lintdump /lib/llib-lsocket.ln
-   \fI[ ... ]\fP
-   FILE: llib-lsocket:socket.h
-         struct msghdr <tag 4532> {
-             void *msg_name;
-             unsigned int msg_namelen;
-             struct iovec *msg_iov;
-             int msg_iovlen;
-             \fBchar *msg_accrights;\fP
-             \fBint msg_accrightslen;\fP
-         };
-.fi
-.LP
-.nf
-$ lint -omsghdr msghdr.c -lsocket
-$ lintdump llib-lmsghdr.ln
-   \fI[ ... ]\fP
-   FILE: socket.h
-         struct msghdr <tag 1315> {
-             void *msg_name;
-             unsigned int msg_namelen;
-             struct iovec *msg_iov;
-             int msg_iovlen;
-             \fBvoid *msg_control;\fP
-             \fBunsigned int msg_controllen;\fP
-             \fBint msg_flags;\fP
-         };
-.fi
-.LP
-Looking at <sys/socket.h>, the problem becomes apparent: the structure
-changes depending on compile-time options, which clearly differ between
-the application and the library:
-.LP
-.nf
-struct msghdr {
-        void            *msg_name;
-        socklen_t       msg_namelen;
-        struct iovec    *msg_iov;
-        int             msg_iovlen;
-
-#if defined(_XPG4_2) || defined(_KERNEL)
-        void            *msg_control;
-        socklen_t       msg_controllen;
-        int             msg_flags;
-#else
-        caddr_t         msg_accrights;
-        int             msg_accrightslen;
-#endif  /* defined(_XPG4_2) || defined(_KERNEL) */
-};
-.fi
-.LP
-Another use of lintdump is to compare two versions of a lint object to
-see whether anything of significance has changed.  For instance, lintdump
-can be used to understand why a lint library is different between a
-project gate and a patch gate, and thus to determine whether the library
-will need to be redelivered in the patch including the project:
-.LP
-.nf
-$ PATCHROOT=/ws/on10-patch/proto/root_i386
-$ diff llib-lkstat.ln $PATCHROOT/lib/llib-lkstat.ln
-Binary files llib-lkstat.ln and
-             /ws/on10-patch/proto/root_i386/lib/llib-lkstat.ln differ
-$ lintdump -ir llib-lkstat.ln > /tmp/proj-kstat.out
-$ lintdump -ir $PATCHROOT/lib/llib-lkstat.ln > /tmp/patch-kstat.out
-.fi
-.LP
-.nf
-$ diff /tmp/patch-kstat.out /tmp/proj-kstat.out
-1,2c1,2
-< LINTMOD: 3675: 4995+26812+1045+9 = 32861 bytes
-< SECTION: PASS1: 4995 bytes
----
-> LINTMOD: 39982: 5144+27302+1057+9 = 33512 bytes
-> SECTION: PASS1: 5144 bytes
-19c19
-<              unsigned char _file;
----
->              unsigned char _magic;
-22a23,24
->              unsigned int __extendedfd;
->              unsigned int __xf_nocheck;
-\fI[ ... ]\fP
-.fi
-.LP
-Note that -r option removes spurious differences that would otherwise
-arise from different absolute paths to the same source file, and the -i
-option removes spurious differences due to ID generation inside lint.
-.LP
-.SH SEE ALSO
-.LP
-.IR lint(1),
-.IR printf(3C),
-.IR scanf(3C)
-.SH NOTES
-This utility is provided as an interim solution until a stable utility
-can be bundled with Sun Studio.  As such, any use of this utility in
-scripts or embedded inside programs should be done with knowledge that
-subsequent changes will be required in order to transition to the stable
-solution.
-.LP
-The lint object file format does not have a way to represent bitfields. As
-such, bitfield size information cannot be displayed by lintdump.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/lintdump/lintdump.1onbld	Wed Sep 30 19:35:37 2015
@@ -0,0 +1,325 @@
+.\" " CDDL HEADER START
+.\" "
+.\" " The contents of this file are subject to the terms of the
+.\" " Common Development and Distribution License (the "License").
+.\" " You may not use this file except in compliance with the License.
+.\" "
+.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" " or http://www.opensolaris.org/os/licensing.
+.\" " See the License for the specific language governing permissions
+.\" " and limitations under the License.
+.\" "
+.\" " When distributing Covered Code, include this CDDL HEADER in each
+.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" " If applicable, add the following below this CDDL HEADER, with the
+.\" " fields enclosed by brackets "[]" replaced with your own identifying
+.\" " information: Portions Copyright [yyyy] [name of copyright owner]
+.\" "
+.\" " CDDL HEADER END
+.\" "
+.\" "Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
+.\" "Use is subject to license terms.
+.TH lintdump 1ONBLD "28 Mar 2008"
+.I lintdump
+\- dump the contents of one or more lint objects
+.SH SYNOPSIS
+\fBlintdump [-i] [-p 1|2|3] [-r] \fIlintobj\fP [ \fIlintobj\fP ... ]
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "lintdump" "" "\fBlintdump\fP"
+.LP
+The lintdump utility dumps the contents of one or more lint
+objects.  This is chiefly useful when trying to understand the cause of
+unexpected or obtuse lint warnings (see EXAMPLES), but can also be used to
+find differences between lint objects across builds or releases, or to
+debug problems in lint itself.
+.LP
+A lint object is a binary file (typically suffixed with ".ln") constructed
+from a C source file via the "-c" option to lint(1).  Multiple lint
+objects may be combined into a lint library object (typically prefixed
+with "llib-l" and suffixed with ".ln") using the "-o" option to lint.  (As
+a convenience, lint "-o" allows a lint library object to be built directly
+from C source files). The lintdump utility is capable of dumping both
+traditional lint objects and lint library objects.
+.LP
+The format of a lint object is unstable and subject to change at any time,
+but its current structure is summarized here in order to aid in
+understanding the current output of lintdump.  A lint object consists of
+one or more lint modules (one per C source file).  Each lint module
+consists of a header and four sections, called PASS1, PASS2, PASS3, and
+STRINGS.  Generally speaking, PASS1 contains definitions, PASS2 contains
+declarations, and PASS3 contains information on whether or how functions
+or variables are used.  The STRINGS section holds the strings for
+printf(3C)/scanf(3C) checking.
+.LP
+Each PASS section consists of a sequence of binary records of assorted
+types.  The sequence of records is further partitioned by FILE records,
+which indicate the source or header file that is responsible for the
+records that follow.  The remaining record types provide lint with
+information about the functions, variables, and structures defined or used
+by the object. 
+.SH OPTIONS
+.TP 10
+.B -i
+Do not output structure tag IDs (see EXAMPLES).
+.TP 10
+.B -p 1|2|3
+Just output the PASS1, PASS2, or PASS3 section.
+.TP 10
+.B -r
+Output records using relative paths (see EXAMPLES).
+.LP
+.SH OUTPUT
+.LP
+The contents of each specified \fIlintobj\fP is dumped in command-line
+order.  For each \fIlintobj\fP, lintdump outputs a single line beginning
+with "LINTOBJ:" that provides its name.  For each lint module within that
+object, lintdump outputs a single line beginning with "LINTMOD:" that
+provides its module ID, the size of its PASS1, PASS2, PASS3, STRING
+sections, and its total size, in that order.
+.LP
+Next, unless the -p option is used, the contents of the PASS1, PASS2, and
+PASS3 sections are dumped, in order.  Before each section is dumped,
+lintdump outputs a single line beginning with "SECTION:" that
+provides the name and size of the section.  For each section,
+lintdump outputs each record in order.  The display format of each
+record depends on its type:
+.LP
+.B FILE RECORDS
+.RS 4
+Each FILE record is displayed on a single line beginning with "FILE:".
+Note that FILE records are often found in pairs, the first providing the
+absolute path to the file.  FILE records containing absolute paths are
+omitted if -r is used.  Other record types following a FILE record are
+indented to show their relationship to the FILE record.
+.RE
+.LP
+.B FUNCTION AND VARIABLE RECORDS
+.RS 4
+Each function or variable record is displayed on a single line using an
+extended version of the format used in The C Programming Language, Second
+Edition.  In particular, properties contained in the record that cannot be
+conveyed in C are displayed in angle brackets following definition or
+declaration; a full list of these and their meanings are given below in
+RECORD PROPERTIES.  In addition, note that some structures or unions may
+only be known by a numeric \fIID\fP, and thus output as "struct <tag
+\fIID\fP>".  This ID can be used to pair the structure with its definition
+via structure records.  If -i is used, then "struct <anon>" is printed
+instead.
+.RE
+.LP
+.B STRUCTURE AND UNION RECORDS
+.RS 4
+Each structure or union record is displayed using an extended version of
+the standard multi-line format used in The C Programming Language, Second
+Edition.  In particular, to facilitate problem analysis, unless -i is
+used, each structure or union definition includes a numeric ID enclosed in
+angle-brackets, such as "struct FILE <tag 1298> {".
+.RE
+.LP
+To illustrate each of the common record formats, suppose the following
+lint library is built:
+.LP
+.nf
+$ cat > liba.c
+/* LINTLIBRARY */
+/* PROTOLIB1 */
+int af(int);
+struct as {
+        char as_name[32];
+        int  as_flag;
+} as;
+$ lint -oa liba.c
+.fi
+.LP
+Then lintdump will produce the following output:
+.LP
+.nf
+LINTOBJ: llib-la.ln
+LINTMOD: 6484: 268+24+130+9 = 431 bytes
+SECTION: PASS1: 268 bytes
+   FILE: /home/meem/hacks/liba.c
+   FILE: liba.c
+         extern int af(int);
+         struct as as;
+         struct as <tag 98> {
+             char as_name[];
+             int as_flag;
+         };
+SECTION: PASS2: 24 bytes
+SECTION: PASS3: 130 bytes
+   FILE: /home/meem/hacks/liba.c
+   FILE: liba.c
+         int af(void) <returns value>;
+.fi
+.LP
+.SH RECORD PROPERTIES
+.LP
+As discussed in OUTPUT, some records are displayed using an extended
+format to convey information that cannot be expressed in C.  The following
+extended information may be displayed:
+.RE
+.LP
+.B <PRINTFLIKE\fIn\fP>
+.RS 4
+Indicates to lint that argument \fIn\fP to the variable-argument function
+is a format string in printf(3C) format, which enhances lint's argument
+checking.
+.RE
+.LP
+.B <SCANFLIKE\fIn\fP>
+.RS 4
+Indicates to lint that argument \fIn\fP to the variable-argument function
+is a format string in scanf(3C) format, which enhances lint's argument
+checking.
+.RE
+.LP
+.B <definition>
+.RS 4
+Indicates to lint that this record represents the definition of the given
+variable or function (rather than a declaration).
+.RE
+.LP
+.B <use: side-effects context>
+.RS 4
+Indicates to lint that the associated function is called in a context that
+suggests it has side effects.
+.RE
+.LP
+.B <use: return value context>
+.RS 4
+Indicates to lint that the associated function is called in a context where
+its return value is used.
+.RE
+.LP
+.B <use: unspecified context>
+.RS 4
+Indicates to lint that the associated function is used in an unspecified
+manner.
+.RE
+.LP
+.B <returns value>
+.RS 4
+Indicates to lint that the function returns a value.
+.RE
+.LP
+.SH EXAMPLES
+.LP
+One common problem is that lint does not always provide sufficient
+information to understand the reason for a type mismatch.  For instance,
+sometimes lint will confusingly report a type mismatch between
+apparently-identical types:
+.LP
+.nf
+$ lint msghdr.c -lsocket
+function argument ( number ) used inconsistently
+    recvmsg (arg 2) llib-lsocket:socket.h(437) struct msghdr * ::
+                                 msghdr.c(12)  struct msghdr *
+.fi
+.LP
+By using lintdump, we can pinpoint the problem by examining both
+definitions for \fIstruct msghdr\fP:
+.LP
+.nf
+$ lintdump /lib/llib-lsocket.ln
+   \fI[ ... ]\fP
+   FILE: llib-lsocket:socket.h
+         struct msghdr <tag 4532> {
+             void *msg_name;
+             unsigned int msg_namelen;
+             struct iovec *msg_iov;
+             int msg_iovlen;
+             \fBchar *msg_accrights;\fP
+             \fBint msg_accrightslen;\fP
+         };
+.fi
+.LP
+.nf
+$ lint -omsghdr msghdr.c -lsocket
+$ lintdump llib-lmsghdr.ln
+   \fI[ ... ]\fP
+   FILE: socket.h
+         struct msghdr <tag 1315> {
+             void *msg_name;
+             unsigned int msg_namelen;
+             struct iovec *msg_iov;
+             int msg_iovlen;
+             \fBvoid *msg_control;\fP
+             \fBunsigned int msg_controllen;\fP
+             \fBint msg_flags;\fP
+         };
+.fi
+.LP
+Looking at <sys/socket.h>, the problem becomes apparent: the structure
+changes depending on compile-time options, which clearly differ between
+the application and the library:
+.LP
+.nf
+struct msghdr {
+        void            *msg_name;
+        socklen_t       msg_namelen;
+        struct iovec    *msg_iov;
+        int             msg_iovlen;
+
+#if defined(_XPG4_2) || defined(_KERNEL)
+        void            *msg_control;
+        socklen_t       msg_controllen;
+        int             msg_flags;
+#else
+        caddr_t         msg_accrights;
+        int             msg_accrightslen;
+#endif  /* defined(_XPG4_2) || defined(_KERNEL) */
+};
+.fi
+.LP
+Another use of lintdump is to compare two versions of a lint object to
+see whether anything of significance has changed.  For instance, lintdump
+can be used to understand why a lint library is different between a
+project gate and a patch gate, and thus to determine whether the library
+will need to be redelivered in the patch including the project:
+.LP
+.nf
+$ PATCHROOT=/ws/on10-patch/proto/root_i386
+$ diff llib-lkstat.ln $PATCHROOT/lib/llib-lkstat.ln
+Binary files llib-lkstat.ln and
+             /ws/on10-patch/proto/root_i386/lib/llib-lkstat.ln differ
+$ lintdump -ir llib-lkstat.ln > /tmp/proj-kstat.out
+$ lintdump -ir $PATCHROOT/lib/llib-lkstat.ln > /tmp/patch-kstat.out
+.fi
+.LP
+.nf
+$ diff /tmp/patch-kstat.out /tmp/proj-kstat.out
+1,2c1,2
+< LINTMOD: 3675: 4995+26812+1045+9 = 32861 bytes
+< SECTION: PASS1: 4995 bytes
+---
+> LINTMOD: 39982: 5144+27302+1057+9 = 33512 bytes
+> SECTION: PASS1: 5144 bytes
+19c19
+<              unsigned char _file;
+---
+>              unsigned char _magic;
+22a23,24
+>              unsigned int __extendedfd;
+>              unsigned int __xf_nocheck;
+\fI[ ... ]\fP
+.fi
+.LP
+Note that -r option removes spurious differences that would otherwise
+arise from different absolute paths to the same source file, and the -i
+option removes spurious differences due to ID generation inside lint.
+.LP
+.SH SEE ALSO
+.LP
+.IR lint(1),
+.IR printf(3C),
+.IR scanf(3C)
+.SH NOTES
+This utility is provided as an interim solution until a stable utility
+can be bundled with Sun Studio.  As such, any use of this utility in
+scripts or embedded inside programs should be done with knowledge that
+subsequent changes will be required in order to transition to the stable
+solution.
+.LP
+The lint object file format does not have a way to represent bitfields. As
+such, bitfield size information cannot be displayed by lintdump.
--- old/usr/src/tools/ndrgen/Makefile	Wed Sep 30 19:35:37 2015
+++ new/usr/src/tools/ndrgen/Makefile	Wed Sep 30 19:35:37 2015
@@ -25,7 +25,7 @@
 
 PROG=	ndrgen ndrgen1
 
-MAN1FILES=	ndrgen.1
+MAN1ONBLDFILES=	ndrgen.1onbld
 
 OBJS=	ndr_main.o ndr_lex.o ndr_anal.o \
 	ndr_gen.o ndr_parse.o ndr_print.o
@@ -39,15 +39,15 @@
 
 CLEANFILES += $(OBJS) y.tab.c y.tab.h
 
-$(ROOTONBLDMAN1FILES) := FILEMODE=      644
+$(ROOTONBLDMAN1ONBLDFILES) := FILEMODE=      644
 
 .KEEP_STATE:
 
 .PARALLEL: $(OBJS)
 
-all:	$(PROG) $(MAN1FILES)
+all:	$(PROG) $(MAN1ONBLDFILES)
 
-install: all .WAIT $(ROOTONBLDMACHPROG) $(ROOTONBLDMAN1FILES)
+install: all .WAIT $(ROOTONBLDMACHPROG) $(ROOTONBLDMAN1ONBLDFILES)
 
 lint:	lint_SRCS
 
--- old/usr/src/tools/ndrgen/ndrgen.1	Wed Sep 30 19:35:37 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,514 +0,0 @@
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2007 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.\" ident	"%Z%%M%	%I%	%E% SMI"
-'\" te
-.TH ndrgen 1 "22 October 2007" "SunOS 5.11" "User Commands"
-.SH NAME
-ndrgen \- NDL RPC protocol compiler
-.SH SYNOPSIS
-.LP
-.nf
-\fBndrgen\fR [ -Y \fIcpp-path\fR ] \fIfile\fR [ \fIfile\fR ] \&.\|.\|.
-.fi
-
-.SH DESCRIPTION
-.sp
-.LP
-The \fBndrgen\fR utility is a tool that generates C code to implement a DCERPC/MSRPC Network Data Representation (NDR) protocol. The input to \fBndrgen\fR is a language similar to C known as Network Data Language (NDL).
-.sp
-.LP
-The \fBndrgen\fR utility takes an input protocol definition file and generates an output C source file that contains the marshalling routines to implement the RPC protocol. If the input file is named \fBproto.ndl\fR, \fBndrgen\fR generates NDR routines in \fBproto_ndr.c\fR. Applications must define the service definition and server-side stub table for use with the RPC protocol.
-.sp
-.LP
-The following is an example stub table and service definition:
-.sp
-.in +2
-.nf
-static stub_table_t net_svc_stub_table[] = {
-   { svc_close, SVC_CLOSE },
-   { svc_open,  SVC_OPEN },
-   { svc_read,  SVC_READ },
-   { svc_write, SVC_WRITE },
-   {0}
-};
-
-static service_t net_svc = {
-   "NETSVC",                    /* name */
-   "Network Service",           /* description */
-   "\e\enetsvc",                  /* endpoint */
-   "\e\epipe\e\enetsvc",            /* secondary address port */
-   "12345678-1234-abcd-ef0001234567abcd", 1,    /* abstract syntax */
-   "8a885d04-1ceb-11c9-9fe808002b104860", 2,    /* transfer syntax */
-   0,                           /* bind_instance_size */
-   0,                           /* bind_req() */
-   0,                           /* unbind_and_close() */
-   0,                           /* call_stub() */
-   &TYPEINFO(svc_interface),    /* interface ti */
-   net_svc_stub_table           /* stub_table */
-};
-.fi
-.in -2
-
-.sp
-.LP
-The C preprocessor, which can be specified in the \fBCC\fR environment variable or on the command line, is run on the input file before it is interpreted by \fBndrgen\fR. The \fBNDRGEN\fR preprocessor symbol is defined by \fBndrgen\fR for use by the \fBndrgen\fR programmer.
-.sp
-.LP
-The NDR generated by \fBndrgen\fR is an MSRPC compatible implementation of OSF DCE NDR. This implementation is based on the X/Open DCE: Remote Procedure Call specification (CAE Specification (1997), DCE 1.1: Remote Procedure Call Document Number: C706), enhanced for compatibility with MSRPC Unicode (UCS-2) strings.
-.sp
-.LP
-The following table shows the DCE RPC layering compared against ONC RPC.
-.sp
-.in +2
-.nf
- DCE RPC Layers          ONC RPC Layers	             Remark
-+---------------+       +---------------+     +----------------+
-+---------------+       +---------------+
-| Application   |       | Application 	|       The application
-+---------------+       +---------------+
-| Hand coded    |       | RPCGEN gen'd  |
-| client/server |       | client/server |       Generated stubs
-| proto.ndl     |       | *_svc.c *_clnt|
-| proto.c       |       |               |
-+---------------+       +---------------+
-|               |       |               |       Binding/PMAP
-| RPC Library   |       | RPC Library   |       Calls/Return
-+---------------+       +---------------+
-| RPC Protocol  |       | RPC Protocol  |       Headers
-| rpcpdu.ndl    |       |               |       Authentication
-+---------------+       +---------------+
-| NDRGEN gen'd  |       | RPCGEN gen'd  |       Aggregation
-| NDR stubs     |       | XDR stubs     |       Composition
-| *__ndr.c      |       | *_xdr.c       |
-+---------------+       +---------------+
-| NDR           |       | XDR           |       Byte order, padding
-+---------------+       +---------------+
-|               |       | Network Conn  |       Large difference:
-| Heap          |       | clnt_tcp      |       see below.
-| Management    |       | clnt_udp      |
-+---------------+       +---------------+
-.fi
-.in -2
-
-.sp
-.LP
-There are two major differences between the DCE RPC and ONC RPC:
-.RS +4
-.TP
-1.
-DCE RPC only generates or processes packets from buffers. Other layers must take care of packet transmission and reception. The packet heaps are managed through a simple interface provided by NDR streams.
-.sp
-ONC RPC communicates directly with the network. The programmer must do specific setup for the RPC packet to be placed in a buffer rather than sent to the wire.
-.RE
-.RS +4
-.TP
-2.
-DCE RPC uses application provided heaps to support operations. A heap is a managed chunk of memory that NDR manages as it allocates. When the operation and its result are complete, the heap is disposed of as a single item. Transactions, which are the anchor of most operations, perform heap bookkeeping.
-.sp
-ONC RPC uses \fBmalloc()\fR liberally throughout its run-time system. To free results, ONC RPC supports an \fBXDR_FREE\fR operation that traverses data structures freeing memory as it goes.
-.RE
-.sp
-.LP
-The following terminology is used in the subsequent discussion of NDR.
-.sp
-.ne 2
-.mk
-.na
-\fBSize\fR
-.ad
-.sp .6
-.RS 4n
-The size of an array in elements, such as the amount to \fBmalloc()\fR.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBLength\fR
-.ad
-.sp .6
-.RS 4n
-The number of significant elements of an array.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBKnown\fR
-.ad
-.sp .6
-.RS 4n
-Size or Length is known at build time.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBDetermined\fR
-.ad
-.sp .6
-.RS 4n
-Size or Length is determined at run time.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBFixed\fR
-.ad
-.sp .6
-.RS 4n
-The Size and Length are Known, such as a string constant:
-.sp
-.in +2
-.nf
-char array[] = "A constant Size/Length";
-.fi
-.in -2
-
-.RE
-
-.sp
-.LP
-The following DCE RPC terminology is used in the subsequent discussion.
-.sp
-.ne 2
-.mk
-.na
-\fBConformant\fR
-.ad
-.sp .6
-.RS 4n
-The Size is Determined. The Length is the same as Size.
-.sp
-
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBVarying\fR
-.ad
-.sp .6
-.RS 4n
-The Size is Known. The Length is Determined, such as a \fBstrcpy()\fR of a variable length string into a fixed length buffer:
-.sp
-.in +2
-.nf
-char array[100];
-strcpy(array, "very short string");
-.fi
-.in -2
-
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBVarying and Conformant\fR
-.ad
-.sp .6
-.RS 4n
-The Size is Determined. The Length is separately Determined, such as:
-.sp
-.in +2
-.nf
-char *array = malloc(size);
-strcpy(array, "short string");
-.fi
-.in -2
-
-.RE
-
-.SS "Strings"
-.sp
-.LP
-DCE RPC strings are represented as varying or varying and conformant one-dimensional arrays. Characters can be single-byte or multi-byte as long as all characters conform to a fixed element size. For instance, UCS-2 is valid, but UTF-8 is not a valid DCE RPC string format. The string is terminated by a null character of the appropriate element size.
-.sp
-.LP
-MSRPC strings are always varying and conformant format and not null terminated. This format uses the \fIsize_is\fR, \fIfirst_is\fR, and \fIlength_is\fR attributes:
-.sp
-.in +2
-.nf
-typedef struct string {
-   DWORD size_is;
-   DWORD first_is;
-   DWORD length_is;
-   wchar_t string[ANY_SIZE_ARRAY];
-} string_t;
-.fi
-.in -2
-
-.sp
-.LP
-The \fIsize_is\fR attribute is used to specify the number of data elements in each dimension of an array.
-.sp
-.LP
-The \fIfirst_is\fR attribute is used to define the lower bound for significant elements in each dimension of an array. For strings, this value is always zero.
-.sp
-.LP
-The \fIlength_is\fR attribute is used to define the number of significant elements in each dimension of an array.  For strings, this value is typically the same as \fIsize_is\fR, although it might be (\fIsize_is\fR - 1) if the string is null terminated.
-.sp
-.LP
-MSRPC Unicode strings are not null terminated, which means that the recipient must manually null-terminate the string after it has been received. Note that there is often a wide-char pad following a string, which might contain zero but this situation is not guaranteed.
-.sp
-.in +2
-.nf
- 4 bytes   4 bytes   4 bytes   2bytes 2bytes 2bytes 2bytes
-+---------+---------+---------+------+------+------+------+
-|size_is  |first_is |length_is| char | char | char | char |
-+---------+---------+---------+------+------+------+------+
-.fi
-.in -2
-
-.sp
-.LP
-Despite the general rule, some MSRPC services use null-terminated Unicode strings. To compensate, MSRPC uses the following additional string wrapper with two additional fields. Note that LPTSTR is automatically converted to \fBstring_t\fR by the NDR library.
-.sp
-.in +2
-.nf
-typedef struct msrpc_string {
-   WORD length;
-   WORD maxlen;
-   LPTSTR str;
-} msrpc_string_t;
-.fi
-.in -2
-
-.sp
-.LP
-Here, \fIlength\fR is the array length in bytes excluding any terminating null bytes and \fImaxlen\fR is the array length in bytes including the terminating null bytes.
-.SS "NDL Syntax"
-.sp
-.LP
-The \fBndrgen\fR input must be a valid C header file. Thus, NDL is defined by using macros to map to DCE RPC IDL. The following shows the mappings:
-.sp
-.in +2
-.nf
-NDRGEN NDL	DCE RPC IDL
-================================
-OPERATION(X)    [operation(X)]
-IN              [in]
-OUT             [out]
-INOUT           [in out]
-STRING          [string]
-SIZE_IS(X)      [size_is(X)]
-SWITCH(X)       [switch_is(X)]
-CASE(X)         [case(X)]
-DEFAULT         [default]
-INTERFACE(X)    [interface(X)]
-UUID(X)         [uuid(X)]
-ARG_IS(X)       [arg_is(X)]
-REFERENCE       [reference]
-ANY_SIZE_ARRAY  *
-IMPORT_EXTERN   [extern]
-.fi
-.in -2
-
-.sp
-.LP
-The following shows the C data type associated with the NDRGEN NDL:
-.sp
-.in +2
-.nf
-NDRGEN NDL	C Data Type
-==============================
-BYTE            unsigned char
-WORD            unsigned short
-DWORD           unsigned long
-LPTSTR          wchar_t *
-LPBYTE          unsigned char *
-LPWORD          unsigned short *
-LPDWORD         unsigned long *
-.fi
-.in -2
-
-.SH OPTIONS
-.sp
-.LP
-The \fBsmbutil\fR command supports the following global option:
-.sp
-.ne 2
-.mk
-.na
-\fB\fB-Y\fR\fR
-.ad
-.RS 13n
-.rt  
-Specifies the path to the \fBcpp\fR program.
-.RE
-
-.SH EXAMPLES
-.sp
-.LP
-The following is an example NDL header file:
-.sp
-.in +2
-.nf
-#ifndef _SVC_NDL_
-#define	_SVC_NDL_
-
-#include "ndrtypes.ndl"
-
-/*
-* Opnums: note that ndrgen does not automatically number
-* operations and the values do not have to be sequential.
-*/
-#define	SVC_CLOSE 0x00
-#define	SVC_OPEN 0x01
-#define	SVC_READ 0x02
-#define	SVC_WRITE 0x03
-
-/*
-* Define a file handle - choice of UUID format is
-* arbitrary.  Note that typedef's cannot be declared
-* with the struct definition.
-*/
-struct svc_uuid {
-   DWORD data1;
-   DWORD data2;
-   WORD  data3[2];
-   BYTE  data4[8];
-};
-typedef struct svc_uuid svc_handle_t;
-
-struct xferbuf {
-   DWORD nbytes;
-   DWORD offset;
-   SIZE_IS(nbytes) BYTE *data;
-};
-typedef struct xferbuf xferbuf_t;
-
-/*
-* Define the RPC operations.
-*/
-OPERATION(SVC_CLOSE)
-struct svc_close {
-   IN	svc_handle_t handle;
-   OUT	DWORD status;
-};
-
-OPERATION(SVC_OPEN)
-struct svc_open {
-   IN	LPTSTR servername;
-   IN	LPTSTR path;
-   OUT	svc_handle_t handle;
-   OUT	DWORD status;
-};
-
-OPERATION(SVC_READ)
-struct svc_read {
-   IN	svc_handle_t handle;
-   IN	DWORD nbytes;
-   IN	DWORD offset;
-   OUT	xferbuf_t buf;
-   OUT	DWORD status;
-};
-
-OPERATION(SVC_WRITE)
-struct svc_write {
-   IN	svc_handle_t handle;
-   IN	xferbuf_t buf;
-   OUT	DWORD nbytes;
-   OUT	DWORD status;
-};
-
-/*
-* Define the interface.
-*/
-INTERFACE(0)
-union svc_interface {
-CASE(SVC_CLOSE)
-   struct svc_close net_close;
-CASE(SVC_OPEN)
-   struct svc_open net_open;
-CASE(SVC_READ)
-   struct svc_read net_read;
-CASE(SVC_WRITE)
-   struct svc_write net_write;
-};
-typedef union svc_interface svc_interface_t;
-EXTERNTYPEINFO(svc_interface)
-
-#endif /* _SVC_NDL_ */
-.fi
-.in -2
-
-.SH EXIT STATUS
-.sp
-.LP
-The following exit values are returned:
-.sp
-.ne 2
-.mk
-.na
-\fB0\fR
-.ad
-.RS 13n
-.rt  
-Successful operation.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fB>0\fR
-.ad
-.RS 13n
-.rt  
-An error occurred.
-.RE
-
-.SH ATTRIBUTES
-.sp
-.LP
-See the \fBattributes\fR(5) man page for descriptions of the following attributes:
-.sp
-
-.sp
-.TS
-tab() box;
-cw(2.75i) |cw(2.75i) 
-lw(2.75i) |lw(2.75i) 
-.
-ATTRIBUTE TYPEATTRIBUTE VALUE
-_
-AvailabilitySUNWbtool
-.TE
-
-.SH SEE ALSO
-.sp
-.LP
-\fBcpp\fR(1), \fBrpcgen\fR(1), \fBcc\fR(1B), \fBattributes\fR(5)
-.SH BUGS
-.sp
-.LP
-Some \fBcpp\fR(1) macros used by \fBndrgen\fR are not understood by \fB/usr/bin/cpp\fR or \fB/usr/sfw/bin/cpp\fR. Simple NDL files generally do not pose a problem. If problems occur, for example, when using unions, use \fB/usr/libexec/cpp\fR or \fBcw\fR.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/ndrgen/ndrgen.1onbld	Wed Sep 30 19:35:37 2015
@@ -0,0 +1,513 @@
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2007 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+'\" te
+.TH ndrgen 1ONBLD "22 October 2007" "SunOS 5.11" "User Commands"
+.SH NAME
+ndrgen \- NDL RPC protocol compiler
+.SH SYNOPSIS
+.LP
+.nf
+\fBndrgen\fR [ -Y \fIcpp-path\fR ] \fIfile\fR [ \fIfile\fR ] \&.\|.\|.
+.fi
+
+.SH DESCRIPTION
+.sp
+.LP
+The \fBndrgen\fR utility is a tool that generates C code to implement a DCERPC/MSRPC Network Data Representation (NDR) protocol. The input to \fBndrgen\fR is a language similar to C known as Network Data Language (NDL).
+.sp
+.LP
+The \fBndrgen\fR utility takes an input protocol definition file and generates an output C source file that contains the marshalling routines to implement the RPC protocol. If the input file is named \fBproto.ndl\fR, \fBndrgen\fR generates NDR routines in \fBproto_ndr.c\fR. Applications must define the service definition and server-side stub table for use with the RPC protocol.
+.sp
+.LP
+The following is an example stub table and service definition:
+.sp
+.in +2
+.nf
+static stub_table_t net_svc_stub_table[] = {
+   { svc_close, SVC_CLOSE },
+   { svc_open,  SVC_OPEN },
+   { svc_read,  SVC_READ },
+   { svc_write, SVC_WRITE },
+   {0}
+};
+
+static service_t net_svc = {
+   "NETSVC",                    /* name */
+   "Network Service",           /* description */
+   "\e\enetsvc",                  /* endpoint */
+   "\e\epipe\e\enetsvc",            /* secondary address port */
+   "12345678-1234-abcd-ef0001234567abcd", 1,    /* abstract syntax */
+   "8a885d04-1ceb-11c9-9fe808002b104860", 2,    /* transfer syntax */
+   0,                           /* bind_instance_size */
+   0,                           /* bind_req() */
+   0,                           /* unbind_and_close() */
+   0,                           /* call_stub() */
+   &TYPEINFO(svc_interface),    /* interface ti */
+   net_svc_stub_table           /* stub_table */
+};
+.fi
+.in -2
+
+.sp
+.LP
+The C preprocessor, which can be specified in the \fBCC\fR environment variable or on the command line, is run on the input file before it is interpreted by \fBndrgen\fR. The \fBNDRGEN\fR preprocessor symbol is defined by \fBndrgen\fR for use by the \fBndrgen\fR programmer.
+.sp
+.LP
+The NDR generated by \fBndrgen\fR is an MSRPC compatible implementation of OSF DCE NDR. This implementation is based on the X/Open DCE: Remote Procedure Call specification (CAE Specification (1997), DCE 1.1: Remote Procedure Call Document Number: C706), enhanced for compatibility with MSRPC Unicode (UCS-2) strings.
+.sp
+.LP
+The following table shows the DCE RPC layering compared against ONC RPC.
+.sp
+.in +2
+.nf
+ DCE RPC Layers          ONC RPC Layers	             Remark
++---------------+       +---------------+     +----------------+
++---------------+       +---------------+
+| Application   |       | Application 	|       The application
++---------------+       +---------------+
+| Hand coded    |       | RPCGEN gen'd  |
+| client/server |       | client/server |       Generated stubs
+| proto.ndl     |       | *_svc.c *_clnt|
+| proto.c       |       |               |
++---------------+       +---------------+
+|               |       |               |       Binding/PMAP
+| RPC Library   |       | RPC Library   |       Calls/Return
++---------------+       +---------------+
+| RPC Protocol  |       | RPC Protocol  |       Headers
+| rpcpdu.ndl    |       |               |       Authentication
++---------------+       +---------------+
+| NDRGEN gen'd  |       | RPCGEN gen'd  |       Aggregation
+| NDR stubs     |       | XDR stubs     |       Composition
+| *__ndr.c      |       | *_xdr.c       |
++---------------+       +---------------+
+| NDR           |       | XDR           |       Byte order, padding
++---------------+       +---------------+
+|               |       | Network Conn  |       Large difference:
+| Heap          |       | clnt_tcp      |       see below.
+| Management    |       | clnt_udp      |
++---------------+       +---------------+
+.fi
+.in -2
+
+.sp
+.LP
+There are two major differences between the DCE RPC and ONC RPC:
+.RS +4
+.TP
+1.
+DCE RPC only generates or processes packets from buffers. Other layers must take care of packet transmission and reception. The packet heaps are managed through a simple interface provided by NDR streams.
+.sp
+ONC RPC communicates directly with the network. The programmer must do specific setup for the RPC packet to be placed in a buffer rather than sent to the wire.
+.RE
+.RS +4
+.TP
+2.
+DCE RPC uses application provided heaps to support operations. A heap is a managed chunk of memory that NDR manages as it allocates. When the operation and its result are complete, the heap is disposed of as a single item. Transactions, which are the anchor of most operations, perform heap bookkeeping.
+.sp
+ONC RPC uses \fBmalloc()\fR liberally throughout its run-time system. To free results, ONC RPC supports an \fBXDR_FREE\fR operation that traverses data structures freeing memory as it goes.
+.RE
+.sp
+.LP
+The following terminology is used in the subsequent discussion of NDR.
+.sp
+.ne 2
+.mk
+.na
+\fBSize\fR
+.ad
+.sp .6
+.RS 4n
+The size of an array in elements, such as the amount to \fBmalloc()\fR.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBLength\fR
+.ad
+.sp .6
+.RS 4n
+The number of significant elements of an array.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBKnown\fR
+.ad
+.sp .6
+.RS 4n
+Size or Length is known at build time.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBDetermined\fR
+.ad
+.sp .6
+.RS 4n
+Size or Length is determined at run time.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBFixed\fR
+.ad
+.sp .6
+.RS 4n
+The Size and Length are Known, such as a string constant:
+.sp
+.in +2
+.nf
+char array[] = "A constant Size/Length";
+.fi
+.in -2
+
+.RE
+
+.sp
+.LP
+The following DCE RPC terminology is used in the subsequent discussion.
+.sp
+.ne 2
+.mk
+.na
+\fBConformant\fR
+.ad
+.sp .6
+.RS 4n
+The Size is Determined. The Length is the same as Size.
+.sp
+
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBVarying\fR
+.ad
+.sp .6
+.RS 4n
+The Size is Known. The Length is Determined, such as a \fBstrcpy()\fR of a variable length string into a fixed length buffer:
+.sp
+.in +2
+.nf
+char array[100];
+strcpy(array, "very short string");
+.fi
+.in -2
+
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBVarying and Conformant\fR
+.ad
+.sp .6
+.RS 4n
+The Size is Determined. The Length is separately Determined, such as:
+.sp
+.in +2
+.nf
+char *array = malloc(size);
+strcpy(array, "short string");
+.fi
+.in -2
+
+.RE
+
+.SS "Strings"
+.sp
+.LP
+DCE RPC strings are represented as varying or varying and conformant one-dimensional arrays. Characters can be single-byte or multi-byte as long as all characters conform to a fixed element size. For instance, UCS-2 is valid, but UTF-8 is not a valid DCE RPC string format. The string is terminated by a null character of the appropriate element size.
+.sp
+.LP
+MSRPC strings are always varying and conformant format and not null terminated. This format uses the \fIsize_is\fR, \fIfirst_is\fR, and \fIlength_is\fR attributes:
+.sp
+.in +2
+.nf
+typedef struct string {
+   DWORD size_is;
+   DWORD first_is;
+   DWORD length_is;
+   wchar_t string[ANY_SIZE_ARRAY];
+} string_t;
+.fi
+.in -2
+
+.sp
+.LP
+The \fIsize_is\fR attribute is used to specify the number of data elements in each dimension of an array.
+.sp
+.LP
+The \fIfirst_is\fR attribute is used to define the lower bound for significant elements in each dimension of an array. For strings, this value is always zero.
+.sp
+.LP
+The \fIlength_is\fR attribute is used to define the number of significant elements in each dimension of an array.  For strings, this value is typically the same as \fIsize_is\fR, although it might be (\fIsize_is\fR - 1) if the string is null terminated.
+.sp
+.LP
+MSRPC Unicode strings are not null terminated, which means that the recipient must manually null-terminate the string after it has been received. Note that there is often a wide-char pad following a string, which might contain zero but this situation is not guaranteed.
+.sp
+.in +2
+.nf
+ 4 bytes   4 bytes   4 bytes   2bytes 2bytes 2bytes 2bytes
++---------+---------+---------+------+------+------+------+
+|size_is  |first_is |length_is| char | char | char | char |
++---------+---------+---------+------+------+------+------+
+.fi
+.in -2
+
+.sp
+.LP
+Despite the general rule, some MSRPC services use null-terminated Unicode strings. To compensate, MSRPC uses the following additional string wrapper with two additional fields. Note that LPTSTR is automatically converted to \fBstring_t\fR by the NDR library.
+.sp
+.in +2
+.nf
+typedef struct msrpc_string {
+   WORD length;
+   WORD maxlen;
+   LPTSTR str;
+} msrpc_string_t;
+.fi
+.in -2
+
+.sp
+.LP
+Here, \fIlength\fR is the array length in bytes excluding any terminating null bytes and \fImaxlen\fR is the array length in bytes including the terminating null bytes.
+.SS "NDL Syntax"
+.sp
+.LP
+The \fBndrgen\fR input must be a valid C header file. Thus, NDL is defined by using macros to map to DCE RPC IDL. The following shows the mappings:
+.sp
+.in +2
+.nf
+NDRGEN NDL	DCE RPC IDL
+================================
+OPERATION(X)    [operation(X)]
+IN              [in]
+OUT             [out]
+INOUT           [in out]
+STRING          [string]
+SIZE_IS(X)      [size_is(X)]
+SWITCH(X)       [switch_is(X)]
+CASE(X)         [case(X)]
+DEFAULT         [default]
+INTERFACE(X)    [interface(X)]
+UUID(X)         [uuid(X)]
+ARG_IS(X)       [arg_is(X)]
+REFERENCE       [reference]
+ANY_SIZE_ARRAY  *
+IMPORT_EXTERN   [extern]
+.fi
+.in -2
+
+.sp
+.LP
+The following shows the C data type associated with the NDRGEN NDL:
+.sp
+.in +2
+.nf
+NDRGEN NDL	C Data Type
+==============================
+BYTE            unsigned char
+WORD            unsigned short
+DWORD           unsigned long
+LPTSTR          wchar_t *
+LPBYTE          unsigned char *
+LPWORD          unsigned short *
+LPDWORD         unsigned long *
+.fi
+.in -2
+
+.SH OPTIONS
+.sp
+.LP
+The \fBsmbutil\fR command supports the following global option:
+.sp
+.ne 2
+.mk
+.na
+\fB\fB-Y\fR\fR
+.ad
+.RS 13n
+.rt  
+Specifies the path to the \fBcpp\fR program.
+.RE
+
+.SH EXAMPLES
+.sp
+.LP
+The following is an example NDL header file:
+.sp
+.in +2
+.nf
+#ifndef _SVC_NDL_
+#define	_SVC_NDL_
+
+#include "ndrtypes.ndl"
+
+/*
+* Opnums: note that ndrgen does not automatically number
+* operations and the values do not have to be sequential.
+*/
+#define	SVC_CLOSE 0x00
+#define	SVC_OPEN 0x01
+#define	SVC_READ 0x02
+#define	SVC_WRITE 0x03
+
+/*
+* Define a file handle - choice of UUID format is
+* arbitrary.  Note that typedef's cannot be declared
+* with the struct definition.
+*/
+struct svc_uuid {
+   DWORD data1;
+   DWORD data2;
+   WORD  data3[2];
+   BYTE  data4[8];
+};
+typedef struct svc_uuid svc_handle_t;
+
+struct xferbuf {
+   DWORD nbytes;
+   DWORD offset;
+   SIZE_IS(nbytes) BYTE *data;
+};
+typedef struct xferbuf xferbuf_t;
+
+/*
+* Define the RPC operations.
+*/
+OPERATION(SVC_CLOSE)
+struct svc_close {
+   IN	svc_handle_t handle;
+   OUT	DWORD status;
+};
+
+OPERATION(SVC_OPEN)
+struct svc_open {
+   IN	LPTSTR servername;
+   IN	LPTSTR path;
+   OUT	svc_handle_t handle;
+   OUT	DWORD status;
+};
+
+OPERATION(SVC_READ)
+struct svc_read {
+   IN	svc_handle_t handle;
+   IN	DWORD nbytes;
+   IN	DWORD offset;
+   OUT	xferbuf_t buf;
+   OUT	DWORD status;
+};
+
+OPERATION(SVC_WRITE)
+struct svc_write {
+   IN	svc_handle_t handle;
+   IN	xferbuf_t buf;
+   OUT	DWORD nbytes;
+   OUT	DWORD status;
+};
+
+/*
+* Define the interface.
+*/
+INTERFACE(0)
+union svc_interface {
+CASE(SVC_CLOSE)
+   struct svc_close net_close;
+CASE(SVC_OPEN)
+   struct svc_open net_open;
+CASE(SVC_READ)
+   struct svc_read net_read;
+CASE(SVC_WRITE)
+   struct svc_write net_write;
+};
+typedef union svc_interface svc_interface_t;
+EXTERNTYPEINFO(svc_interface)
+
+#endif /* _SVC_NDL_ */
+.fi
+.in -2
+
+.SH EXIT STATUS
+.sp
+.LP
+The following exit values are returned:
+.sp
+.ne 2
+.mk
+.na
+\fB0\fR
+.ad
+.RS 13n
+.rt  
+Successful operation.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fB>0\fR
+.ad
+.RS 13n
+.rt  
+An error occurred.
+.RE
+
+.SH ATTRIBUTES
+.sp
+.LP
+See the \fBattributes\fR(5) man page for descriptions of the following attributes:
+.sp
+
+.sp
+.TS
+tab() box;
+cw(2.75i) |cw(2.75i) 
+lw(2.75i) |lw(2.75i) 
+.
+ATTRIBUTE TYPEATTRIBUTE VALUE
+_
+AvailabilitySUNWbtool
+.TE
+
+.SH SEE ALSO
+.sp
+.LP
+\fBcpp\fR(1), \fBrpcgen\fR(1), \fBcc\fR(1B), \fBattributes\fR(5)
+.SH BUGS
+.sp
+.LP
+Some \fBcpp\fR(1) macros used by \fBndrgen\fR are not understood by \fB/usr/bin/cpp\fR or \fB/usr/sfw/bin/cpp\fR. Simple NDL files generally do not pose a problem. If problems occur, for example, when using unions, use \fB/usr/libexec/cpp\fR or \fBcw\fR.
--- old/usr/src/tools/scripts/Install.1	Wed Sep 30 19:35:38 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,362 +0,0 @@
-.\"
-.\" Copyright 2010 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.TH Install 1 "14 Jan 2010"
-.SH NAME
-Install \- install a kernel from an ON workspace
-.SH SYNOPSIS
-.TP 8n
-.B Install
-.RB [ " \-w "
-.IR workspace " ]"
-.RB [ " \-s "
-.IR "source dir" " ]"
-.br
-.RB [ " \-k  "
-.IR "kernel arch" " ]"
-.RB "[ " \-n " | " \-t|T
-.IR target " ]"
-.br
-.RB [ " \-u|m|a " ]
-.RB [ " \-v|V|q " ]
-.RB [ " \-c|p " ]
-.br
-.RB [ " \-l "
-.IR "library file" " ]"
-.RB [ " \-L " ]
-.RB [ " \-3 " ]
-.RB [ " \-6 " ]
-.RB [ " \-K " ]
-.br
-.RB [ " \-o "
-{
-.BR obj " | "
-.B debug
-}
-]
-.RB [ " \-d "
-.IR "work dir" " ]"
-.br
-.RB [ " \-D "
-.IR "library dir" " ]"
-.RB [ " \-G "
-.IB glomname " ]"
-.RI [ " module ... " ]
-.LP
-or
-.LP
-.BR "Install \-R " "[ options ]"
-.SH DESCRIPTION
-.LP
-.B Install
-is a utility which simplifies the process of installing a 5.0 system.
-.B Install
-goes into a built ON workspace (or any kernel source tree),
-looks at the Makefiles,
-and figures out how to construct the /kernel and /usr/kernel directories.
-It then creates a tarfile
-.RB "(see " tar "(1))"
-containing /kernel, /usr/kernel, and a few related /etc files.  If a
-.I target ([user@]machine:/dir)
-is specified, the tarfile is either copied to
-.IR machine:/dir " (-T) or untarred on " "machine" " in " "/dir" " (-t),"
-using the remote user id
-.IR user ,
-if specified.
-With no options,
-.B Install
-creates a sun4c system from files in the current workspace (as indicated
-by $SRC) and places the tarfile in /tmp/Install.username/Install.sun4c.tar.
-
-.SH OPTIONS
-.TP 20n
-.BI "-w" " ws"
-Install the system built in the ON workspace
-.I ws.  ws
-must be a built ON workspace \(em
-.B Install
-will not automatically invoke
-.BR make "(1).  If " \-w " is not specified, " Install " uses the current
-workspace (as indicated by $CODEMGR_WS).  If there is no current workspace,
-.B Install
-checks to see if you are in an appropriate source directory, e.g. uts/sun4c;
-if so,
-.B Install
-takes files from there.  Otherwise,
-.B Install
-looks for files under $SRC/uts.
-.TP
-.BI "-s" " source directory"
-where to look for files [default: $SRC/uts].
-.TP
-.BI "-k" " kernel arch"
-the type of kernel to install.  The default is sun4c; however, if you invoke
-.B Install
-from $SRC/uts/sun4z,
-.B Install
-assumes you want a sun4z kernel.
-.TP
-.B "-n"
-No target; just create the tarfile in
-/tmp/Install.username/Install.sun4c.tar [default].
-.BR "-n" " implies " "-p" .
-.TP
-.BI "-t" " target"
-Install the system on
-.I target ([user@]machine:/dir).
-This means that kernel/unix is copied to
-.I machine:/dir/kernel/unix,
-etc.
-.IR /dir " is typically either " / " or " /mnt.
-.BR "-t" " implies " "-c" .
-The default remote user id is the same as the local one ($LOGNAME).
-.TP
-.BI "-T" " target"
-Copy the tarfile to
-.I target ([user@]machine:/dir).
-This creates the file
-.I /dir/Install.tar
-on
-.I machine.
-To finish the install, log on to
-.I machine
-as root, and type
-.RB `` "cd /; tar xvf /dir/Install.tar" "''."
-.BR "-T" " implies " "-c" .
-.TP
-.B "-u"
-Install unix only.
-.TP
-.B "-m"
-Install modules only.
-.TP
-.B "-a"
-Install unix and all modules [default].
-.TP
-.B "-v"
-Verbose mode.
-.TP
-.B "-V"
-REALLY verbose mode.  Useful mainly for debugging.
-.TP
-.B "-q"
-Quiet mode [default].  Only fatal messages are printed.
-.TP
-.B "-c"
-Clean up.  After a successful install, delete the files created in
-/tmp/Install.username.  This is the default behavior if a
-.I target
-is specified with
-.BR "-t" " or " "-T" .
-.TP
-.B "-p"
-Preserve temp files.  This is the default behavior when no
-.I target
-is specified
-.RB ( "-n" ).
-.TP
-.B "-R"
-Recover from a failed
-.BR Install .
-This is not required, it's just faster than restarting.
-A typical scenario is for
-.B Install
-to run smoothly right up to the very end, but then die with
-"Permission denied" when it tries to rsh/rcp to the target machine.
-At this point, you log on to the target machine, diddle the permissions,
-log off, and type
-.RB `` "Install -R" "''."
-.B Install
-will only have to retry the rsh/rcp,
-rather than rebuild the tarfile from scratch.
-.TP
-.BI "-d" " temp directory"
-specifies where
-.B Install
-should create its temp files [default: /tmp/Install.username].  This is
-useful if you have limited space in /tmp (\fBInstall\fR can take as
-much as 100MB).
-The suffix "Install.username" is always appended.
-.TP
-.B "-L"
-add a system to your library.  This allows you to build a personal
-collection of installable systems from various environments and for
-various architectures.  When you type
-.RB `` "Install -w /ws/ws_name -k arch -L" "'', " Install
-creates a tarfile called
-.I ws_name.arch.tar
-in your library directory (~/LibInstall by default).
-.BR "-L" " implies " "-c" .
-.TP
-.BI "-l" " library file"
-Installs the system contained in
-.I library file.
-You may omit the ``.tar'' suffix.  For example,
-.RB `` "Install -l my_ws.sun4c -t machine:/" ''
-installs a system you previously built with
-.B "-L"
-(from sun4c files in my_ws) on 
-.IR machine:/ .
-This is equivalent to typing
-.RB `` "rsh machine '(cd /; tar xvf -)' <~/LibInstall/my_ws.sun4c.tar" '',
-but it's easier to remember.
-.TP
-.BI "-D" " lib directory"
-specifies the library directory [default: $HOME/LibInstall].
-.TP
-.BI "-G " glomname
-gloms /kernel and /usr/kernel together into a single /kernel directory.
-Useful for development work, e.g. use "Install -G good [...]" to create a
-"/kernel.good".
-.TP
-.BR "-o " "{ \fBobj\fP | \fBdebug\fP }"
-object directory. The default is "debug".
-.TP
-.B \-3
-32-bit modules only
-.TP
-.B \-6
-64-bit modules only
-.TP
-.B \-K
-Do not include kmdb misc module or dmods
-.TP
-.B "-h"
-Help.  Prints a brief summary of
-.BR Install "'s"
-options.
-.LP
-If you are in a directory like $SRC/uts/sun4z when you invoke
-.BR Install ,
-it will infer that you want to install a sun4z system
-from the current workspace.
-.LP
-If you supply a list of modules, it overrides any of the
-.B "-uma"
-options.  You only need to specify the basename of the
-module(s), e.g. ``\fBInstall ufs nfs le\fR''.
-``\fBInstall unix\fR'' is equivalent to ``\fBInstall -u\fR'', and
-``\fBInstall modules\fR'' is equivalent to ``\fBInstall -m\fR''.
-.LP
-You can customize
-.B Install
-by creating a .Installrc file in your home directory.  .Installrc
-should consist of a list of command-line-style options, e.g:
-.LP
-.B
-	-w /ws/foo
-.br
-.B
-	-t labmachine:/mnt -pv
-.LP
-.B Install
-processes default options first, then .Installrc
-options, then command-line options.  In the case of
-conflicting options (e.g. \fB-uma\fR), the last one wins.
-.LP
-In order to use the most convenient form of
-.BR Install " (``" "Install -t machine:/" "''),"
-you will need to do the following on the target machine:
-.LP
-.br
-	(1) add your machine name to the /etc/hosts.equiv file
-.br
-	(2) add your username to the /etc/{passwd,shadow} files
-.br
-	(3) chown -R yourself /kernel /usr/kernel
-.br
-	(4) chmod -R u+w /kernel /usr/kernel
-.SH "ENVIRONMENT"
-.LP
-You can set the following variables in your environment:
-.LP
-ON_CRYPTO_BINS
-.IP
-file containing signed cryptographic binaries.  This is only needed if
-you are not building the closed-source tree.
-.LP
-INSTALL_RC [default: $HOME/.Installrc]
-.IP
-file containing default options for \fBInstall\fR
-.LP
-INSTALL_STATE [default: $HOME/.Install.state]
-.IP
-where \fBInstall\fR keeps its state information
-.LP
-INSTALL_DIR [default: /tmp/Install.username]
-.IP
-where \fBInstall\fR does its work.  This can be overridden on
-the command line with \fB\-d\fR.
-.LP
-INSTALL_LIB [default: $HOME/LibInstall]
-.IP
-where \fBInstall\fR gets/puts library files.  This can be overridden on
-the command line with \fB\-D\fR.
-.LP
-INSTALL_CP [default: cp -p]
-.IP
-the command to copy files locally
-.LP
-INSTALL_RCP [default: rcp -p]
-.IP
-the command to copy files remotely
-.bp
-.SH "EXAMPLES"
-.LP
-.B
-Install -w /ws/blort -t machine:/
-.IP
-.RI "installs the system built in workspace " /ws/blort " on " machine:/
-.LP
-.B
-Install -w /ws/blort -T machine:/tmp
-.br
-.B
-rsh machine -l root "cd /; tar xvf /tmp/Install.tar"
-.IP
-is an equivalent way to do the previous example
-.LP
-.B Install
-.IP
-makes a tarfile containing a sun4c kernel,
-and places it in /tmp/Install.username/Install.sun4c.tar.  However, if you
-are in one of the arch directories (e.g. $SRC/uts/sun4m) when you invoke
-.BR Install ,
-you will get a tarfile for that architecture instead.
-.LP
-.B
-Install -k sun4m -w /ws/on493 -t mpbox:/ ufs
-.IP
-installs a new sun4m ufs module from workspace /ws/on493 on mpbox:/
-.SH "FILES"
-$HOME/.Installrc, $HOME/.Install.state
-.SH "SEE ALSO"
-.BR tar "(1), " rsh "(1), " rcp "(1)"
-.SH "BUGS"
-.BR tar "(1) and " rsh "(1)"
-do not have particularly useful exit codes.  To compensate,
-.B Install
-feeds stderr through grep -v and throws away error messages which it
-considers harmless.  If there's anything left,
-.B Install
-assumes it is fatal.  It's a hack, but it works.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/Install.1onbld	Wed Sep 30 19:35:38 2015
@@ -0,0 +1,362 @@
+.\"
+.\" Copyright 2010 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.TH Install 1ONBLD "14 Jan 2010"
+.SH NAME
+Install \- install a kernel from an ON workspace
+.SH SYNOPSIS
+.TP 8n
+.B Install
+.RB [ " \-w "
+.IR workspace " ]"
+.RB [ " \-s "
+.IR "source dir" " ]"
+.br
+.RB [ " \-k  "
+.IR "kernel arch" " ]"
+.RB "[ " \-n " | " \-t|T
+.IR target " ]"
+.br
+.RB [ " \-u|m|a " ]
+.RB [ " \-v|V|q " ]
+.RB [ " \-c|p " ]
+.br
+.RB [ " \-l "
+.IR "library file" " ]"
+.RB [ " \-L " ]
+.RB [ " \-3 " ]
+.RB [ " \-6 " ]
+.RB [ " \-K " ]
+.br
+.RB [ " \-o "
+{
+.BR obj " | "
+.B debug
+}
+]
+.RB [ " \-d "
+.IR "work dir" " ]"
+.br
+.RB [ " \-D "
+.IR "library dir" " ]"
+.RB [ " \-G "
+.IB glomname " ]"
+.RI [ " module ... " ]
+.LP
+or
+.LP
+.BR "Install \-R " "[ options ]"
+.SH DESCRIPTION
+.LP
+.B Install
+is a utility which simplifies the process of installing a 5.0 system.
+.B Install
+goes into a built ON workspace (or any kernel source tree),
+looks at the Makefiles,
+and figures out how to construct the /kernel and /usr/kernel directories.
+It then creates a tarfile
+.RB "(see " tar "(1))"
+containing /kernel, /usr/kernel, and a few related /etc files.  If a
+.I target ([user@]machine:/dir)
+is specified, the tarfile is either copied to
+.IR machine:/dir " (-T) or untarred on " "machine" " in " "/dir" " (-t),"
+using the remote user id
+.IR user ,
+if specified.
+With no options,
+.B Install
+creates a sun4c system from files in the current workspace (as indicated
+by $SRC) and places the tarfile in /tmp/Install.username/Install.sun4c.tar.
+
+.SH OPTIONS
+.TP 20n
+.BI "-w" " ws"
+Install the system built in the ON workspace
+.I ws.  ws
+must be a built ON workspace \(em
+.B Install
+will not automatically invoke
+.BR make "(1).  If " \-w " is not specified, " Install " uses the current
+workspace (as indicated by $CODEMGR_WS).  If there is no current workspace,
+.B Install
+checks to see if you are in an appropriate source directory, e.g. uts/sun4c;
+if so,
+.B Install
+takes files from there.  Otherwise,
+.B Install
+looks for files under $SRC/uts.
+.TP
+.BI "-s" " source directory"
+where to look for files [default: $SRC/uts].
+.TP
+.BI "-k" " kernel arch"
+the type of kernel to install.  The default is sun4c; however, if you invoke
+.B Install
+from $SRC/uts/sun4z,
+.B Install
+assumes you want a sun4z kernel.
+.TP
+.B "-n"
+No target; just create the tarfile in
+/tmp/Install.username/Install.sun4c.tar [default].
+.BR "-n" " implies " "-p" .
+.TP
+.BI "-t" " target"
+Install the system on
+.I target ([user@]machine:/dir).
+This means that kernel/unix is copied to
+.I machine:/dir/kernel/unix,
+etc.
+.IR /dir " is typically either " / " or " /mnt.
+.BR "-t" " implies " "-c" .
+The default remote user id is the same as the local one ($LOGNAME).
+.TP
+.BI "-T" " target"
+Copy the tarfile to
+.I target ([user@]machine:/dir).
+This creates the file
+.I /dir/Install.tar
+on
+.I machine.
+To finish the install, log on to
+.I machine
+as root, and type
+.RB `` "cd /; tar xvf /dir/Install.tar" "''."
+.BR "-T" " implies " "-c" .
+.TP
+.B "-u"
+Install unix only.
+.TP
+.B "-m"
+Install modules only.
+.TP
+.B "-a"
+Install unix and all modules [default].
+.TP
+.B "-v"
+Verbose mode.
+.TP
+.B "-V"
+REALLY verbose mode.  Useful mainly for debugging.
+.TP
+.B "-q"
+Quiet mode [default].  Only fatal messages are printed.
+.TP
+.B "-c"
+Clean up.  After a successful install, delete the files created in
+/tmp/Install.username.  This is the default behavior if a
+.I target
+is specified with
+.BR "-t" " or " "-T" .
+.TP
+.B "-p"
+Preserve temp files.  This is the default behavior when no
+.I target
+is specified
+.RB ( "-n" ).
+.TP
+.B "-R"
+Recover from a failed
+.BR Install .
+This is not required, it's just faster than restarting.
+A typical scenario is for
+.B Install
+to run smoothly right up to the very end, but then die with
+"Permission denied" when it tries to rsh/rcp to the target machine.
+At this point, you log on to the target machine, diddle the permissions,
+log off, and type
+.RB `` "Install -R" "''."
+.B Install
+will only have to retry the rsh/rcp,
+rather than rebuild the tarfile from scratch.
+.TP
+.BI "-d" " temp directory"
+specifies where
+.B Install
+should create its temp files [default: /tmp/Install.username].  This is
+useful if you have limited space in /tmp (\fBInstall\fR can take as
+much as 100MB).
+The suffix "Install.username" is always appended.
+.TP
+.B "-L"
+add a system to your library.  This allows you to build a personal
+collection of installable systems from various environments and for
+various architectures.  When you type
+.RB `` "Install -w /ws/ws_name -k arch -L" "'', " Install
+creates a tarfile called
+.I ws_name.arch.tar
+in your library directory (~/LibInstall by default).
+.BR "-L" " implies " "-c" .
+.TP
+.BI "-l" " library file"
+Installs the system contained in
+.I library file.
+You may omit the ``.tar'' suffix.  For example,
+.RB `` "Install -l my_ws.sun4c -t machine:/" ''
+installs a system you previously built with
+.B "-L"
+(from sun4c files in my_ws) on 
+.IR machine:/ .
+This is equivalent to typing
+.RB `` "rsh machine '(cd /; tar xvf -)' <~/LibInstall/my_ws.sun4c.tar" '',
+but it's easier to remember.
+.TP
+.BI "-D" " lib directory"
+specifies the library directory [default: $HOME/LibInstall].
+.TP
+.BI "-G " glomname
+gloms /kernel and /usr/kernel together into a single /kernel directory.
+Useful for development work, e.g. use "Install -G good [...]" to create a
+"/kernel.good".
+.TP
+.BR "-o " "{ \fBobj\fP | \fBdebug\fP }"
+object directory. The default is "debug".
+.TP
+.B \-3
+32-bit modules only
+.TP
+.B \-6
+64-bit modules only
+.TP
+.B \-K
+Do not include kmdb misc module or dmods
+.TP
+.B "-h"
+Help.  Prints a brief summary of
+.BR Install "'s"
+options.
+.LP
+If you are in a directory like $SRC/uts/sun4z when you invoke
+.BR Install ,
+it will infer that you want to install a sun4z system
+from the current workspace.
+.LP
+If you supply a list of modules, it overrides any of the
+.B "-uma"
+options.  You only need to specify the basename of the
+module(s), e.g. ``\fBInstall ufs nfs le\fR''.
+``\fBInstall unix\fR'' is equivalent to ``\fBInstall -u\fR'', and
+``\fBInstall modules\fR'' is equivalent to ``\fBInstall -m\fR''.
+.LP
+You can customize
+.B Install
+by creating a .Installrc file in your home directory.  .Installrc
+should consist of a list of command-line-style options, e.g:
+.LP
+.B
+	-w /ws/foo
+.br
+.B
+	-t labmachine:/mnt -pv
+.LP
+.B Install
+processes default options first, then .Installrc
+options, then command-line options.  In the case of
+conflicting options (e.g. \fB-uma\fR), the last one wins.
+.LP
+In order to use the most convenient form of
+.BR Install " (``" "Install -t machine:/" "''),"
+you will need to do the following on the target machine:
+.LP
+.br
+	(1) add your machine name to the /etc/hosts.equiv file
+.br
+	(2) add your username to the /etc/{passwd,shadow} files
+.br
+	(3) chown -R yourself /kernel /usr/kernel
+.br
+	(4) chmod -R u+w /kernel /usr/kernel
+.SH "ENVIRONMENT"
+.LP
+You can set the following variables in your environment:
+.LP
+ON_CRYPTO_BINS
+.IP
+file containing signed cryptographic binaries.  This is only needed if
+you are not building the closed-source tree.
+.LP
+INSTALL_RC [default: $HOME/.Installrc]
+.IP
+file containing default options for \fBInstall\fR
+.LP
+INSTALL_STATE [default: $HOME/.Install.state]
+.IP
+where \fBInstall\fR keeps its state information
+.LP
+INSTALL_DIR [default: /tmp/Install.username]
+.IP
+where \fBInstall\fR does its work.  This can be overridden on
+the command line with \fB\-d\fR.
+.LP
+INSTALL_LIB [default: $HOME/LibInstall]
+.IP
+where \fBInstall\fR gets/puts library files.  This can be overridden on
+the command line with \fB\-D\fR.
+.LP
+INSTALL_CP [default: cp -p]
+.IP
+the command to copy files locally
+.LP
+INSTALL_RCP [default: rcp -p]
+.IP
+the command to copy files remotely
+.bp
+.SH "EXAMPLES"
+.LP
+.B
+Install -w /ws/blort -t machine:/
+.IP
+.RI "installs the system built in workspace " /ws/blort " on " machine:/
+.LP
+.B
+Install -w /ws/blort -T machine:/tmp
+.br
+.B
+rsh machine -l root "cd /; tar xvf /tmp/Install.tar"
+.IP
+is an equivalent way to do the previous example
+.LP
+.B Install
+.IP
+makes a tarfile containing a sun4c kernel,
+and places it in /tmp/Install.username/Install.sun4c.tar.  However, if you
+are in one of the arch directories (e.g. $SRC/uts/sun4m) when you invoke
+.BR Install ,
+you will get a tarfile for that architecture instead.
+.LP
+.B
+Install -k sun4m -w /ws/on493 -t mpbox:/ ufs
+.IP
+installs a new sun4m ufs module from workspace /ws/on493 on mpbox:/
+.SH "FILES"
+$HOME/.Installrc, $HOME/.Install.state
+.SH "SEE ALSO"
+.BR tar "(1), " rsh "(1), " rcp "(1)"
+.SH "BUGS"
+.BR tar "(1) and " rsh "(1)"
+do not have particularly useful exit codes.  To compensate,
+.B Install
+feeds stderr through grep -v and throws away error messages which it
+considers harmless.  If there's anything left,
+.B Install
+assumes it is fatal.  It's a hack, but it works.
--- old/usr/src/tools/scripts/Makefile	Wed Sep 30 19:35:38 2015
+++ new/usr/src/tools/scripts/Makefile	Wed Sep 30 19:35:38 2015
@@ -74,34 +74,34 @@
 SCRIPTLINKS= \
 	git-nits
 
-MAN1FILES= \
-	Install.1 \
-	bldenv.1 \
-	bringovercheck.1 \
-	cddlchk.1 \
-	checkpaths.1 \
-	check_rtime.1 \
-	cstyle.1 \
-	find_elf.1 \
-	flg.flp.1 \
-	git-pbchk.1 \
-	hdrchk.1 \
-	interface_check.1 \
-	interface_cmp.1 \
-	hgsetup.1 \
-	jstyle.1 \
-	mapfilechk.1 \
-	nightly.1 \
-	onu.1 \
-	sccscheck.1 \
-	webrev.1 \
-	which_scm.1 \
-	ws.1 \
-	wsdiff.1 \
-	xref.1
+MAN1ONBLDFILES= \
+	Install.1onbld \
+	bldenv.1onbld \
+	bringovercheck.1onbld \
+	cddlchk.1onbld \
+	checkpaths.1onbld \
+	check_rtime.1onbld \
+	cstyle.1onbld \
+	find_elf.1onbld \
+	flg.flp.1onbld \
+	git-pbchk.1onbld \
+	hdrchk.1onbld \
+	interface_check.1onbld \
+	interface_cmp.1onbld \
+	hgsetup.1onbld \
+	jstyle.1onbld \
+	mapfilechk.1onbld \
+	nightly.1onbld \
+	onu.1onbld \
+	sccscheck.1onbld \
+	webrev.1onbld \
+	which_scm.1onbld \
+	ws.1onbld \
+	wsdiff.1onbld \
+	xref.1onbld
 
-MAN1LINKS= \
-	git-nits.1
+MAN1ONBLDLINKS= \
+	git-nits.1onbld
 
 MAKEFILES= \
 	xref.mk
@@ -116,37 +116,37 @@
 	interface_check \
 	interface_cmp
 
-CLEANFILES = $(SHFILES) $(PERLFILES) $(PYFILES) bldenv.1
+CLEANFILES = $(SHFILES) $(PERLFILES) $(PYFILES) bldenv.1onbld
 
 include ../Makefile.tools
 
 ROOTONBLDSCRIPTLINKS = $(SCRIPTLINKS:%=$(ROOTONBLDBIN)/%)
-ROOTONBLDMAN1LINKS = $(MAN1LINKS:%=$(ROOTONBLDMAN1)/%)
+ROOTONBLDMAN1ONBLDLINKS = $(MAN1ONBLDLINKS:%=$(ROOTONBLDMAN1ONBLD)/%)
 
-$(ROOTONBLDETCFILES)	:= FILEMODE=	644
-$(ROOTONBLDEXCEPTFILES)	:= FILEMODE=	644
-$(ROOTONBLDPERLMODULES)	:= FILEMODE=	644
-$(ROOTONBLDMAKEFILES)	:= FILEMODE=	644
-$(ROOTONBLDMAN1FILES)	:= FILEMODE=	644
+$(ROOTONBLDETCFILES)		:= FILEMODE=	644
+$(ROOTONBLDEXCEPTFILES)		:= FILEMODE=	644
+$(ROOTONBLDPERLMODULES)		:= FILEMODE=	644
+$(ROOTONBLDMAKEFILES)		:= FILEMODE=	644
+$(ROOTONBLDMAN1ONBLDFILES)	:= FILEMODE=	644
 
 .KEEP_STATE:
 
 all:	$(SHFILES) $(PERLFILES) $(PERLMODULES) $(PYFILES) \
-	$(MAN1FILES) $(MAKEFILES)
+	$(MAN1ONBLDFILES) $(MAKEFILES)
 
 $(ROOTONBLDBIN)/git-nits:
 	$(RM) $(ROOTONBLDBIN)/git-nits
 	$(SYMLINK) git-pbchk $(ROOTONBLDBIN)/git-nits
 
-$(ROOTONBLDMAN1)/git-nits.1:
-	$(RM) $(ROOTONBLDMAN1)/git-nits.1
-	$(SYMLINK) git-pbchk.1 $(ROOTONBLDMAN1)/git-nits.1
+$(ROOTONBLDMAN1ONBLD)/git-nits.1onbld:
+	$(RM) $(ROOTONBLDMAN1ONBLD)/git-nits.1onbld
+	$(SYMLINK) git-pbchk.1onbld $(ROOTONBLDMAN1ONBLD)/git-nits.1onbld
 
-install: all .WAIT $(ROOTONBLDSHFILES) $(ROOTONBLDPERLFILES)	\
-		$(ROOTONBLDPERLMODULES) $(ROOTONBLDPYFILES)	\
-		$(ROOTONBLDSCRIPTLINKS) $(ROOTONBLDMAN1FILES)	\
-		$(ROOTONBLDMAKEFILES) $(ROOTONBLDETCFILES)	\
-		$(ROOTONBLDEXCEPTFILES) $(ROOTONBLDMAN1LINKS)
+install: all .WAIT $(ROOTONBLDSHFILES) $(ROOTONBLDPERLFILES)		\
+		$(ROOTONBLDPERLMODULES) $(ROOTONBLDPYFILES)		\
+		$(ROOTONBLDSCRIPTLINKS) $(ROOTONBLDMAN1ONBLDFILES)	\
+		$(ROOTONBLDMAKEFILES) $(ROOTONBLDETCFILES)		\
+		$(ROOTONBLDEXCEPTFILES) $(ROOTONBLDMAN1ONBLDLINKS)
 
 clean:
 	$(RM) $(CLEANFILES)
@@ -160,10 +160,12 @@
 		{ print -r -- "$${shlintout}" ;	false ; } || true
 	$(CHMOD) +x "$@" 
 
-bldenv.1: bldenv
+bldenv.1onbld: bldenv
 	$(RM) "$@"
 	(set +o errexit ; ksh93 $? --nroff ; true) 2>&1 | \
-	sed 's/\.DS/.nf/g;s/\.DE/.fi/' > "$@"
+	sed -e 's/\.DS/.nf/g;s/\.DE/.fi/' \
+	-e 's/\.TH BLDENV 1/.TH BLDENV 1ONBLD/' \
+	-e 's/(1)/(1ONBLD)/' > "$@"
 
 nightly: nightly.sh stdenv.sh
 	$(RM) "$@"
--- old/usr/src/tools/scripts/bringovercheck.1	Wed Sep 30 19:35:38 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,57 +0,0 @@
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.\" ident	"%Z%%M%	%I%	%E% SMI"
-.\"
-.TH bringovercheck 1 "7 April 2006"
-.SH NAME
-.I bringovercheck
-\- Repair misordered workspace timestamps
-.SH SYNOPSIS
-.B bringovercheck
-workspace
-.SH DESCRIPTION
-Some versions of 
-.I bringover(1) 
-fail to 
-.I msync(2)
-writeable mappings; this results in indeterminate modification times
-when the workspace exists on certain filesystems.  When this results
-in SCCS s. files being newer than their respective checked-out source
-files, build carnage may result (see
-.I sccscheck(1)
-for one mitigating step being taken).
-
-If a workspace has been damaged by this bug, you can run
-bringovercheck to detect and correct cases where a source file is
-older than its corresponding SCCS s. file.
-
-If no out-of-date files are found, bringovercheck will produce no
-output; otherwise, it will produce a human-readable transcript
-which includes filenames, last modification dates, and the output of
-the sccs commands it uses to attempt to fix the problem.
-
-Note that because the problem may involve deferred filesystem writes,
-this script may not be fully effective if run immediately after a
-bringover.
-
-
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/bringovercheck.1onbld	Wed Sep 30 19:35:38 2015
@@ -0,0 +1,55 @@
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.TH bringovercheck 1ONBLD "7 April 2006"
+.SH NAME
+.I bringovercheck
+\- Repair misordered workspace timestamps
+.SH SYNOPSIS
+.B bringovercheck
+workspace
+.SH DESCRIPTION
+Some versions of
+.I bringover(1ONBLD)
+fail to
+.I msync(2)
+writeable mappings; this results in indeterminate modification times
+when the workspace exists on certain filesystems.  When this results
+in SCCS s. files being newer than their respective checked-out source
+files, build carnage may result (see
+.I sccscheck(1ONBLD)
+for one mitigating step being taken).
+
+If a workspace has been damaged by this bug, you can run
+bringovercheck to detect and correct cases where a source file is
+older than its corresponding SCCS s. file.
+
+If no out-of-date files are found, bringovercheck will produce no
+output; otherwise, it will produce a human-readable transcript
+which includes filenames, last modification dates, and the output of
+the sccs commands it uses to attempt to fix the problem.
+
+Note that because the problem may involve deferred filesystem writes,
+this script may not be fully effective if run immediately after a
+bringover.
+
+
--- old/usr/src/tools/scripts/cddlchk.1	Wed Sep 30 19:35:38 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,86 +0,0 @@
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.TH cddlchk 1 "1 June 2008"
-.SH NAME
-cddlchk \- Check for valid CDDL header blocks
-.SH SYNOPSIS
-.nf
-\fBcddlchk \fR [\fB-av\fR] [\fB-x\fR \fIexceptions_file\fR] [\fIpath\fR...]
-.fi
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "cddlchk" "" "\fBcddlchk\fP"
-cddlchk inspects files for missing, obsolete, or corrupt Common
-Development and Distribution License (CDDL) header blocks.
-.LP
-.SH OPTIONS
-.LP
-.TP 4
-.B \-a
-Check that all the specified files have a CDDL block, and report a
-warning if any do not.
-If this flag is not specified, only files containing an existing CDDL
-block are validated.
-.LP
-.TP 4
-.B \-v
-Report on all files, not just those with invalid headers
-.LP
-.TP 4
-.B \-x \fIexceptions_file\fR
-Load an exceptions file containing a list of files, directories and
-file extensions to be ignored.
-Exceptions may be one of three types:
-.RS +4
-.TP
-.ie t \(bu
-.el o
-File paths
-.RE
-.RS +4
-.TP
-.ie t \(bu
-.el o
-Directories, specified with a trailing '/'
-.RE
-.RS +4
-.TP
-.ie t \(bu
-.el o
-File extensions, specified with a leading '*.'
-.RE
-.LP
-.SH EXIT STATUS
-.TP 4
-.B 0
-The command completed successfully.
-No errors or warnings were reported
-.LP
-.TP 4
-.B 1
-The command completed unsuccessfully.
-One or more errors or warnings were reported.
-.LP
-.TP 4
-.B 2
-Invalid command-line arguments were specified to the command.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/cddlchk.1onbld	Wed Sep 30 19:35:38 2015
@@ -0,0 +1,86 @@
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.TH cddlchk 1ONBLD "1 June 2008"
+.SH NAME
+cddlchk \- Check for valid CDDL header blocks
+.SH SYNOPSIS
+.nf
+\fBcddlchk \fR [\fB-av\fR] [\fB-x\fR \fIexceptions_file\fR] [\fIpath\fR...]
+.fi
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "cddlchk" "" "\fBcddlchk\fP"
+cddlchk inspects files for missing, obsolete, or corrupt Common
+Development and Distribution License (CDDL) header blocks.
+.LP
+.SH OPTIONS
+.LP
+.TP 4
+.B \-a
+Check that all the specified files have a CDDL block, and report a
+warning if any do not.
+If this flag is not specified, only files containing an existing CDDL
+block are validated.
+.LP
+.TP 4
+.B \-v
+Report on all files, not just those with invalid headers
+.LP
+.TP 4
+.B \-x \fIexceptions_file\fR
+Load an exceptions file containing a list of files, directories and
+file extensions to be ignored.
+Exceptions may be one of three types:
+.RS +4
+.TP
+.ie t \(bu
+.el o
+File paths
+.RE
+.RS +4
+.TP
+.ie t \(bu
+.el o
+Directories, specified with a trailing '/'
+.RE
+.RS +4
+.TP
+.ie t \(bu
+.el o
+File extensions, specified with a leading '*.'
+.RE
+.LP
+.SH EXIT STATUS
+.TP 4
+.B 0
+The command completed successfully.
+No errors or warnings were reported
+.LP
+.TP 4
+.B 1
+The command completed unsuccessfully.
+One or more errors or warnings were reported.
+.LP
+.TP 4
+.B 2
+Invalid command-line arguments were specified to the command.
--- old/usr/src/tools/scripts/check_rtime.1	Wed Sep 30 19:35:38 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,734 +0,0 @@
-.\" Copyright (c) 2001, 2010, Oracle and/or its affiliates. All rights reserved.
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.TH check_rtime 1 "09 March 2010"
-.SH NAME
-.I check_rtime
-\- check ELF runtime attributes
-.SH SYNOPSIS
-\fBcheck_rtime [-imosv] [-D depfile | -d depdir] [-E errfile] [-e exfile] [-f listfile] [-I infofile] [-w outdir] file | dir, ...\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "check_rtime" "" "\fBcheck_rtime\fP"
-.LP
-.I check_rtime
-attempts to check a number of ELF runtime attributes
-for consistency with common build rules.
-These checks involve running \fBldd(1)\fP and
-\fBelfdump(1)\fP against a family of dynamic objects.
-A dynamic object can be defined explicitly as a \fIfile\fP
-or multiple dynamic objects can be located under the directory \fIdir\fP.
-.LP
-.I check_rtime
-is typically called from \fBnightly(1)\fP when the \fB-r\fP
-option is in effect. In this case the dynamic objects under
-the associated \fIproto\fP area (\fB$ROOT\fP) are checked.
-.I check_rtime
-can also be run standalone against any set of dynamic objects.
-.LP
-.I check_rtime
-uses \fBldd(1)\fP to verify dependencies. This implies that
-by default any object inspected will bind to its dependencies
-as they are found in the \fBunderlying\fP system.  Use of the \fB-D\fP, \fB-d\fP
-option, or the existence of the environment variables
-\fB$CODEMGR_WS/$ROOT\fP instruct
-.I check_rtime
-to establish an alternative dependency mapping using
-runtime configuration files generated with \fBcrle(1)\fP.
-.LP
-.I check_rtime
-uses \fBldd(1)\fP to completely relocate any dynamic
-object and thus detect missing dependencies, unsatisfied
-symbol relocations, unused and unreferenced dependencies. These checks
-are carried out for the following reasons:
-.TP 4
-\(bu
-An object that cannot find its dependencies may fail to load
-at runtime.  This error condition often goes unnoticed
-because the existing use of the object is as a dependency itself,
-and the objects' dependencies are already satisfied by the
-caller.  However, if the object itself is unable to satisfy its
-dependencies, its use in new environments may be compromised.
-.sp
-A missing or erroneous \fBrunpath\fP is the typical reason why
-an object can not locate its dependencies.  Use of the link-editors
-\fB-zdefs\fP option when building a shared object ensures required
-dependencies are established.  This flag is inherited from
-\fB$(DYNFLAGS)\fP in \fIlib/Makefile.lib\fP. Missing dependencies
-are displayed as:
-.sp
-.RS 6
-foo: bar.so.1 => (file not found)  <no -zdefs?>
-.RE
-.TP
-\(bu
-Unsatisfied symbol relocations indicate that some thread of
-execution through the object will fail when it is unable to
-locate a referenced symbol.
-.sp
-A missing, or mismatched version of a dependency is the typical
-reason for unsatisfied symbol relocations (see missing dependency
-discussion above). Unsatisfied symbol relocations are displayed as:
-.sp
-.RS 6
-foo: symbol not found: bar  <no -zdefs?>
-.RE
-.RS 4
-.sp
-Note: Shared objects can make reference to symbol definitions
-that are expected to be defined by the caller. To indicate that
-such symbols are not undefined in the usual sense, you must
-specify these symbols in a \fImapfile\fP, using the \fBEXTERN\fP
-or \fBPARENT\fP symbol attribute. Without these symbol attributes,
-\fBldd(1)\fP is unable to determine the symbols special nature, and
-.I check_rtime
-will report these symbols as undefined. 
-.RE
-.TP
-\(bu
-Unused dependencies are wasteful at runtime, as they take time to
-load and relocate, but will not be used by the calling object.  They
-also result in unnecessary processing at link-edit time.
-.sp
-Dependency lists (typically defined via \fB$(LDLIBS)\fP)
-that have been yanked-and-put
-between \fIMakefiles\fP without verifying their need, are a typical
-reason why unused dependencies exist.  Unused dependencies are
-displayed as:
-.sp
-.RS 6
-foo: unused object=bar.so.1  <remove lib or -zignore?>
-.RE
-.TP
-\(bu
-Unreferenced dependencies are also wasteful at runtime, although not
-to the extent of unused dependencies.  They also result in unnecessary
-processing at link-edit time.
-.sp
-Unreferenced dependency removal guards against a dependency becoming
-unused when combined with
-different objects, or as the other object dependencies evolve.
-Unreferenced dependencies are displayed as:
-.sp
-.RS 6
-foo: unreferenced object=bar.so.1;  \\
-.br
-    unused dependency of libfoo.so.1  \\
-.br
-    <remove lib or -zignore?>
-.RE
-.RS 4
-.sp
-See also the section ENVIRONMENT VARIABLES.
-.RE
-.TP
-\(bu
-Unused search paths are wasteful at runtime.
-Unused search paths are displayed as:
-.sp
-.RS 6
-foo: unused search path=/usr/foo/lib  \\
-.br
-    (RUNPATH/RPATH from file libfoo.so.1)  \\
-.br
-    <remove search path?>
-.RE
-.LP
-.I check_rtime
-uses \fBelfdump(1)\fP to look for a concatenated relocation
-section in shared objects, the existence of text relocations,
-whether debugging or symbol table information exists, whether
-applications have a non-executable stack defined, duplicate
-entries in the symbol sorting sections, and for direct bindings.
-These checks are carried out for the following reasons:
-.TP 4
-\(bu
-A concatenated relocation section (\fI.SUNW_reloc\fP)
-provides optimal symbol table
-access at runtime, and thus reduces the overhead of relocating
-the shared object.  In past releases, the link-edit of a dynamic object with
-the \fB-z combreloc\fP option was required to generate a combined
-relocation section.  However, with the integration of 6642769, this section
-combination is a default behavior of the link-editor.
-.sp
-In past releases, not inheriting \fB$(DYNFLAGS)\fP from
-\fIlib/Makefile.lib\fP was the typical reason for not having a
-concatenated relocation section. The misguided use of the
-\fB-z nocombreloc\fP option will also prevent the creation of a
-concatenated relocation section. A missing concatenated relocation section
-is displayed as:
-.sp
-.RS 6
-foo: .SUNW_reloc section missing  <no -zcombreloc?>
-.RE
-.TP
-\(bu
-Text relocations result in impure text segments.  As text segments
-are typically read-only, they can be shared between numerous processes.
-If they must be updated as part of the relocation then the updated
-pages become unsharable and swap space must be allocated to back
-these pages.  These events consume unnecessary system resources and
-reduce overall system performance.
-.sp
-Not inheriting the \fB$(PICS)\fP
-rules from \fIlib/Makefile.lib\fP is the typical reason for having
-non-pic code in shared objects.  Text relocations are displayed as:
-.sp
-.RS 6
-foo: TEXTREL .dynamic tag  <no -Kpic?>
-.RE
-.TP
-\(bu
-Debugging information is unnecessary in released objects.  Although
-extensive when compiled \fB-g\fP, small quantities of debugging
-information are stored in \fI.stabs\fP sections under normal
-compilations.  This debugging information is geared towards aiding
-debuggers locate relocatable objects associated with the dynamic
-objects being debugged.  As relocatable objects aren't made available
-as part of a software release this information has no use.
-.sp
-Not inheriting the correct \fB$(LDFLAGS)\fP from \fIcmd/Makefile.cmd\fP
-(which asserts \fP-s\fP), or \fB$(POST_PROCESS_SO)\fP (which asserts
-\fIstrip -x\fP) are typical reasons for not removing debugging
-information.  Note, removal of debugging information is only enabled
-for release builds. The existence of debugging information is displayed as:
-.sp
-.RS 6
-foo: debugging sections should be deleted  \\
-.br
-    <no strip -x?>
-.RE
-.TP
-\(bu
-All objects should retain their full \fI.symtab\fP symbol table.
-Although this consumes disk space, it provides for more extensive stack
-tracing when debugging user applications.
-.sp
-Hard coding a \fI-s\fP flag with \fB$(LDFLAGS)\fP or
-\fB$(DYNFLAGS)\fP is the typical
-reason for symbol tables being removed.
-Objects that do not contain a symbol table are displayed as:
-.sp
-.RS 6
-foo.so.1: symbol table should not be stripped  \\
-.br
-    <remove -s?>
-.RE
-.TP
-\(bu
-Applications should have a non-executable stack defined to make
-them less vulnerable to buffer overflow attacks.
-.sp
-Not inheriting the \fB$(LDFLAGS)\fP macro in \fIcmd/Makefile.cmd\fP
-is the typical reason for not having a non-executable stack definition.
-Applications without this definition are displayed as:
-.sp
-.RS 6
-foo: application requires non-executable stack \\
-.br
-	<no -Mmapfile_noexstk?>
-.RE
-.sp
-.TP
-\(bu
-x86 applications should have a non-executable data segment defined to make
-them less vulnerable to buffer overflow attacks.
-.sp
-Not inheriting the \fB$(LDFLAGS)\fP macro in \fIcmd/Makefile.cmd\fP
-is the typical reason for not having a non-executable data definition.
-Applications without this definition are displayed as:
-.sp
-.RS 6
-foo: application requires non-executable data \\
-.br
-	<no -Mmapfile_noexdata?>
-.RE
-.sp
-.TP
-\(bu
-Solaris ELF files contain symbol sort sections used by DTrace to
-map addresses in memory to the related function or variable symbols. There
-are two such sections, \fI.SUNW_dynsymsort\fP for
-regular symbols, and \fI.SUNW_dyntlssort\fP for thread-local
-symbols. To ensure that the best names are shown for each
-such address, and that the same name is given across Solaris releases,
-.I check_rtime
-enforces the rule that only one symbol can appear in the sort sections for
-any given address.
-There are two common ways in which multiple symbols 
-or a given address occur in the ON distribution. The first is from
-code written in assembly language. The second is as a 
-result of using \fB#pragma weak\fP in C to create weak symbols. The
-best solution to this
-situation is to modify the code to avoid symbol aliasing. Alternatively,
-the \fBNODYNSORT\fP mapfile attribute can be used to eliminate the unwanted
-symbol.
-.sp
-Duplicate entries in a symbol sort section are
-displayed in one of the following ways, depending on
-whether the section is for regular or thread-local symbols:
-.sp
-.RS 6
-foo: .SUNW_dynsymsort: duplicate ADDRESS: sym1, sym2
-.br
-foo: .SUNW_dyntlssort: duplicate OFFSET: sym1, sym2
-.RE
-.sp
-.TP
-\(bu
-\fBOSNet\fP dynamic ELF objects are expected to employ direct bindings whenever
-feasible.  This runtime binding technique helps to avoid accidental
-interposition problems, and provides a more optimal
-runtime symbol search model.
-.sp
-Not inheriting the correct \fB$(LDFLAGS)\fP from \fIcmd/Makefile.cmd\fP,
-or the correct \fB$(DYNFLAGS)\fP from \fIlib/Makefile.lib\fP, are the
-typical reasons for not enabling direct bindings. Dynamic objects that
-do not contain direct binding information are displayed as:
-.sp
-.RS 6
-foo: object has no direct bindings \\
-.br
-	<no -B direct or -z direct?>
-.RE
-
-.sp
-.LP
-.I check_rtime also
-uses \fBelfdump(1)\fP
-to display useful dynamic entry information under the \fB-i\fP option.
-This doesn't necessarily indicate an error condition, but
-provides information that is often useful for gatekeepers to track
-changes in a release.  Presently the information listed is:
-.TP
-\(bu
-Runpaths are printed for any dynamic object.  This is a historic
-sanity check to insure compiler supplied runpaths (typically from \fBCC\fP)
-are not recorded in any objects.  Runpaths are displayed as:
-.sp
-.RS 6
-foo: RPATH=/usr/bar/lib
-.RE
-.TP
-\(bu
-Needed dependencies are printed for any dynamic object.
-In the freeware world this often helps the introducer of a new
-shared object discover that an existing binary has become its
-consumer, and thus that binaries package dependencies may require updating.
-Dependencies are printed as:
-.sp
-.RS 6
-foo: NEEDED=bar.so.1
-.RE
-.sp
-.LP
-.I check_rtime
-uses \fBmcs(1)\fP to inspect an object's \fI.comment\fP section.
-During development, this section contains numerous file identifiers
-marked with the tag "\fB@(#)\fP".  For release builds these sections
-are deleted and rewritten under control of the \fB$(POST_PROCESS)\fP
-macro to produce a common release identifier.  This identifier
-typically consists of three lines including a single comment starting
-with the string "\fB@(#) SunOS\fP".  If this common identifier isn't
-found the following diagnostic is generated:
-.sp
-.RS 6
-foo: non-conforming mcs(1) comment  <no $(POST_PROCESS)?>
-.RE
-.sp
-.LP
-.I check_rtime
-uses \fBpvs(1)\fP to display version definitions under the \fB-v\fP option.
-Each symbol defined by the object is shown along with the version it belongs to.
-Changes to the symbols defined by an object, or the versions they belong to,
-do not necessarily indicate an error condition, but
-provides information that is often useful for gatekeepers to track
-changes in a release.
-.RE
-.sp
-.LP
-.SH OPTIONS
-.LP
-The following options are supported:
-.TP 4
-.B \-D depfile
-Use \fIdepfile\fP to generate an alternative dependency mapping.
-\fIdepfile\fP must be created by '\fBfind_elf -r\fP'.
-The \fB-D\fP and \fB-d\fP options are mutually exclusive.
-.TP
-.B \-d depdir
-Use \fIdepdir\fP to generate an alternative dependency mapping.
-\fBfind_elf(1)\fP is used to locate the ELF sharable objects for
-which alternative mappings are required. The \fB-D\fP and \fB-d\fP options
-are mutually exclusive.
-.TP 4
-.B \-E errfile
-Direct error messages for the analyzed objects to \fIerrfile\fP instead 
-of stdout.
-.TP 4
-.B \-e exfile
-An exception file is used to exclude objects from
-the usual rules. See EXCEPTION FILE FORMAT.
-.TP
-.B \-f listfile
-Normally,
-.I interface_check
-runs
-.I find_elf
-to locate the ELF objects to analyze. The \fB-f\fP option can be
-used to instead provide a file containing the list of objects to
-analyze, in the format produced by '\fBfind_elf -r\fP'.
-.TP
-.B -I infofile
-Direct informational messages (\fB-i\fP, and \fB-v\fP options) for the
-analyzed objects to \fIinfofile\fP instead of stdout.
-.TP
-.B \-i
-Provide dynamic entry information.  Presently only dependencies and
-runpaths are printed.
-.TP
-.B \-m
-Enable \fBmcs(1)\fP checking.
-.TP
-.B \-o
-Produce a one-line output for each condition discovered, prefixed
-by the objects name.  This output style is more terse, but is
-more appropriate for sorting and diffing with previous build results.
-.TP
-.B \-s
-Determine whether \fI.stabs\fP sections exist.
-.TP
-.B \-v
-Provide version definition information. Each symbol defined by the object
-is printed along with the version it is assigned to.
-.TP
-.B -w outdir
-Interpret the paths of all input and output files relative to \fIoutdir\fP.
-.LP
-.SH EXCEPTION FILE FORMAT
-Exceptions to the rules enforced by
-.I check_rtime
-are specified using an exception file. The \fB-e\fP option is used to
-specify an explicit exception file. Otherwise, if used in an activated
-workspace, the default exception file is
-$CODEMGR_WS/exception_list/check_rtime
-if that file exists. If not used in an activated workspace, or if
-$CODEMGR_WS/exception_list/check_rtime does not exist,
-.I check_rtime
-will use
-.I /opt/onbld/etc/exception_list/check_rtime
-as a fallback default exception file.
-.p
-To run
-.I check_rtime
-without applying exceptions, specify \fB-e\fP with a value of /dev/null.
-.P
-A '#' character at the beginning of a line, or at any point in
-a line when preceded by whitespace, introduces a comment. Empty lines, 
-and lines containing only comments, are ignored by
-.I check_rtime.
-Exceptions are specified as space separated keyword, and \fBperl(1)\fP
-regular expression:
-.sp
-.in +4
-.nf
-keyword  perl-regex
-.fi
-.in -4
-.sp
-Since whitespace is used as a separator, the regular
-expression cannot itself contain whitespace. Use of the \\s character
-class to represent whitespace within the regular expression is recommended.
-Before the perl regular expression is used, constructs of the form
-MACH(dir) are expanded into a regular expression that matches the directory
-given, as well as any 64-bit architecture subdirectory that
-might be present (i.e. amd64, sparcv9). For instance, MACH(lib) will
-match any of the following:
-.sp
-.in +4
-.nf
-lib
-lib/amd64
-lib/sparcv9
-.fi
-.in -4
-.sp
-The exceptions understood by
-.I check_rtime
-are:
-.sp
-.ne 2
-.mk
-.na
-\fBEXEC_DATA\fR
-.ad
-.RS 17n
-.rt
-.sp
-Executables that are not required to have non-executable writable
-data segments
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBEXEC_STACK\fR
-.ad
-.RS 17n
-.rt
-.sp
-Executables that are not required to have a non-executable stack
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBNOCRLEALT\fR
-.ad
-.RS 17n
-.rt
-.sp
-Objects that should be skipped when building the alternative dependency 
-mapping via the \fB-d\fP option.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBNODIRECT\fR
-.ad
-.RS 17n
-.rt
-.sp
-Directories and files that are allowed to have no direct bound symbols.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBNOSYMSORT\fR
-.ad
-.RS 17n
-.rt
-.sp
-Files for which we skip checking of duplicate addresses in the
-symbol sort sections.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBOLDDEP\fR
-.ad
-.RS 17n
-.rt
-.sp
-Objects that used to contain system functionality that has since
-migrated to libc. We preserve these libraries as pure filters for
-backward compatibility but nothing needs to link to them.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBSKIP\fR
-.ad
-.RS 17n
-.rt
-.sp
-Directories and/or individual objects to skip. Note that SKIP should be
-a last resort, used only when one of the other exceptions will not suffice.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBSTAB\fR
-.ad
-.RS 17n
-.rt
-.sp
-Objects that are allowed to contain debugging information (stabs).
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBTEXTREL\fR
-.ad
-.RS 17n
-.rt
-.sp
-Objects for which we allow relocations to the text segment.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBUNDEF_OBJ\fR
-.ad
-.RS 17n
-.rt
-.sp
-Objects that are allowed to be unreferenced.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBUNDEF_REF\fR
-.ad
-.RS 17n
-.rt
-.sp
-Objects that are allowed undefined references.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBUNUSED_DEPS\fR
-.ad
-.RS 17n
-.rt
-.sp
-Objects that are allowed to have unused dependencies.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBUNUSED_OBJ\fR
-.ad
-.RS 17n
-.rt
-.sp
-Objects that are always allowed to be unused dependencies.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBUNUSED_RPATH\fR
-.ad
-.RS 17n
-.rt
-.sp
-Objects that are allowed to have unused runpath directories.
-.RE
-
-.LP
-.SH ALTERNATIVE DEPENDENCY MAPPING
-.I check_rtime
-was primarily designed to process a nightly builds \fB$ROOT\fP
-hierarchy. It is often the case that objects within this hierarchy
-must bind to dependencies within the same hierarchy to satisfy
-their requirements.
-.LP
-To achieve this,
-.I check_rtime
-uses the shared objects specified with the \fB-D\fP or \fB-d\fP options.
-If neither option is specified, and the \fB$CODEMGR_WS\fP and \fB$ROOT\fP
-environment variables are defined, the proto area for the workspace
-is used. The objects found are used
-to create runtime configuration files via \fBcrle(1)\fP, that establish
-the new shared objects as alternatives to their underlying system location.
-.I check_rtime
-passes these configuration files as \fBLD_CONFIG\fP environment
-variable settings to \fBldd(1)\fP using its \fB-e\fP option.
-.LP
-The effect of these configuration files is that the execution of an
-object under \fBldd(1)\fP will bind to the dependencies defined as
-alternatives.  Simply put, an object inspected in the \fIproto\fP
-area will bind to its dependencies found in the \fIproto\fP area.
-Dependencies that have no alternative mapping will continue to
-bind to the underlying system.
-.LP
-.SH ENVIRONMENT VARIABLES
-.LP
-When the \fB-D\fP or \fB-d\fP option isn't in use,
-.I check_rtime
-uses the following environment variables to
-establish an alternative dependency mapping:
-.LP
-.B CODEMGR_WS
-.RS 4
-The root of your workspace, which is the directory
-containing \fICodemgr_wsdata\fP. Existence of this environment variable
-indicates that \fB$ROOT\fP should be investigated.
-.RE
-.LP
-.B ROOT
-.RS 4
-Root of the \fIproto\fP area of your workspace. Any shared objects
-under this directory will be used to establish an alternative dependency
-mapping.
-.RE
-.sp
-If \fBldd(1)\fP supports the \fB-U\fP option, it will be used to determine
-any unreferenced dependencies.  Otherwise \fBldd(1)\fP uses the older
-\fB-u\fP option which only detects unused references.  If the following
-environment variable exists, and indicates an earlier release than \fB5.10\fP
-then \fBldd(1)\fP also falls back to using the \fB-u\fP option.
-.RE
-.LP
-.B RELEASE
-.RS 4
-The release version number of the environment being built.
-.RE
-.SH ERROR CONDITIONS
-.LP
-Inspection of an object with \fBldd(1)\fP assumes it is compatible
-with the machine on which
-.I check_rtime
-is being run.  Incompatible objects such as a 64-bit object encountered on
-a 32-bit system, or an i386 object encountered on a sparc system,
-can not be fully inspected.  These objects are displayed as:
-.sp
-.RS 4
-foo: has wrong class or data encoding
-.RE
-.LP
-.SH FILES
-.LP
-.RS 5
-$CODEMGR_WS/exception_list/check_rtime
-/opt/onbld/etc/exception_list/check_rtime
-.SH SEE ALSO
-.B crle(1),
-.B elfdump(1),
-.B find_elf(1),
-.B ldd(1),
-.B ld.so.1(1),
-.B mcs(1).
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/check_rtime.1onbld	Wed Sep 30 19:35:38 2015
@@ -0,0 +1,734 @@
+.\" Copyright (c) 2001, 2010, Oracle and/or its affiliates. All rights reserved.
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.TH check_rtime 1ONBLD "09 March 2010"
+.SH NAME
+.I check_rtime
+\- check ELF runtime attributes
+.SH SYNOPSIS
+\fBcheck_rtime [-imosv] [-D depfile | -d depdir] [-E errfile] [-e exfile] [-f listfile] [-I infofile] [-w outdir] file | dir, ...\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "check_rtime" "" "\fBcheck_rtime\fP"
+.LP
+.I check_rtime
+attempts to check a number of ELF runtime attributes
+for consistency with common build rules.
+These checks involve running \fBldd(1)\fP and
+\fBelfdump(1)\fP against a family of dynamic objects.
+A dynamic object can be defined explicitly as a \fIfile\fP
+or multiple dynamic objects can be located under the directory \fIdir\fP.
+.LP
+.I check_rtime
+is typically called from \fBnightly(1ONBLD)\fP when the \fB-r\fP
+option is in effect. In this case the dynamic objects under
+the associated \fIproto\fP area (\fB$ROOT\fP) are checked.
+.I check_rtime
+can also be run standalone against any set of dynamic objects.
+.LP
+.I check_rtime
+uses \fBldd(1)\fP to verify dependencies. This implies that
+by default any object inspected will bind to its dependencies
+as they are found in the \fBunderlying\fP system.  Use of the \fB-D\fP, \fB-d\fP
+option, or the existence of the environment variables
+\fB$CODEMGR_WS/$ROOT\fP instruct
+.I check_rtime
+to establish an alternative dependency mapping using
+runtime configuration files generated with \fBcrle(1)\fP.
+.LP
+.I check_rtime
+uses \fBldd(1)\fP to completely relocate any dynamic
+object and thus detect missing dependencies, unsatisfied
+symbol relocations, unused and unreferenced dependencies. These checks
+are carried out for the following reasons:
+.TP 4
+\(bu
+An object that cannot find its dependencies may fail to load
+at runtime.  This error condition often goes unnoticed
+because the existing use of the object is as a dependency itself,
+and the objects' dependencies are already satisfied by the
+caller.  However, if the object itself is unable to satisfy its
+dependencies, its use in new environments may be compromised.
+.sp
+A missing or erroneous \fBrunpath\fP is the typical reason why
+an object can not locate its dependencies.  Use of the link-editors
+\fB-zdefs\fP option when building a shared object ensures required
+dependencies are established.  This flag is inherited from
+\fB$(DYNFLAGS)\fP in \fIlib/Makefile.lib\fP. Missing dependencies
+are displayed as:
+.sp
+.RS 6
+foo: bar.so.1 => (file not found)  <no -zdefs?>
+.RE
+.TP
+\(bu
+Unsatisfied symbol relocations indicate that some thread of
+execution through the object will fail when it is unable to
+locate a referenced symbol.
+.sp
+A missing, or mismatched version of a dependency is the typical
+reason for unsatisfied symbol relocations (see missing dependency
+discussion above). Unsatisfied symbol relocations are displayed as:
+.sp
+.RS 6
+foo: symbol not found: bar  <no -zdefs?>
+.RE
+.RS 4
+.sp
+Note: Shared objects can make reference to symbol definitions
+that are expected to be defined by the caller. To indicate that
+such symbols are not undefined in the usual sense, you must
+specify these symbols in a \fImapfile\fP, using the \fBEXTERN\fP
+or \fBPARENT\fP symbol attribute. Without these symbol attributes,
+\fBldd(1)\fP is unable to determine the symbols special nature, and
+.I check_rtime
+will report these symbols as undefined. 
+.RE
+.TP
+\(bu
+Unused dependencies are wasteful at runtime, as they take time to
+load and relocate, but will not be used by the calling object.  They
+also result in unnecessary processing at link-edit time.
+.sp
+Dependency lists (typically defined via \fB$(LDLIBS)\fP)
+that have been yanked-and-put
+between \fIMakefiles\fP without verifying their need, are a typical
+reason why unused dependencies exist.  Unused dependencies are
+displayed as:
+.sp
+.RS 6
+foo: unused object=bar.so.1  <remove lib or -zignore?>
+.RE
+.TP
+\(bu
+Unreferenced dependencies are also wasteful at runtime, although not
+to the extent of unused dependencies.  They also result in unnecessary
+processing at link-edit time.
+.sp
+Unreferenced dependency removal guards against a dependency becoming
+unused when combined with
+different objects, or as the other object dependencies evolve.
+Unreferenced dependencies are displayed as:
+.sp
+.RS 6
+foo: unreferenced object=bar.so.1;  \\
+.br
+    unused dependency of libfoo.so.1  \\
+.br
+    <remove lib or -zignore?>
+.RE
+.RS 4
+.sp
+See also the section ENVIRONMENT VARIABLES.
+.RE
+.TP
+\(bu
+Unused search paths are wasteful at runtime.
+Unused search paths are displayed as:
+.sp
+.RS 6
+foo: unused search path=/usr/foo/lib  \\
+.br
+    (RUNPATH/RPATH from file libfoo.so.1)  \\
+.br
+    <remove search path?>
+.RE
+.LP
+.I check_rtime
+uses \fBelfdump(1)\fP to look for a concatenated relocation
+section in shared objects, the existence of text relocations,
+whether debugging or symbol table information exists, whether
+applications have a non-executable stack defined, duplicate
+entries in the symbol sorting sections, and for direct bindings.
+These checks are carried out for the following reasons:
+.TP 4
+\(bu
+A concatenated relocation section (\fI.SUNW_reloc\fP)
+provides optimal symbol table
+access at runtime, and thus reduces the overhead of relocating
+the shared object.  In past releases, the link-edit of a dynamic object with
+the \fB-z combreloc\fP option was required to generate a combined
+relocation section.  However, with the integration of 6642769, this section
+combination is a default behavior of the link-editor.
+.sp
+In past releases, not inheriting \fB$(DYNFLAGS)\fP from
+\fIlib/Makefile.lib\fP was the typical reason for not having a
+concatenated relocation section. The misguided use of the
+\fB-z nocombreloc\fP option will also prevent the creation of a
+concatenated relocation section. A missing concatenated relocation section
+is displayed as:
+.sp
+.RS 6
+foo: .SUNW_reloc section missing  <no -zcombreloc?>
+.RE
+.TP
+\(bu
+Text relocations result in impure text segments.  As text segments
+are typically read-only, they can be shared between numerous processes.
+If they must be updated as part of the relocation then the updated
+pages become unsharable and swap space must be allocated to back
+these pages.  These events consume unnecessary system resources and
+reduce overall system performance.
+.sp
+Not inheriting the \fB$(PICS)\fP
+rules from \fIlib/Makefile.lib\fP is the typical reason for having
+non-pic code in shared objects.  Text relocations are displayed as:
+.sp
+.RS 6
+foo: TEXTREL .dynamic tag  <no -Kpic?>
+.RE
+.TP
+\(bu
+Debugging information is unnecessary in released objects.  Although
+extensive when compiled \fB-g\fP, small quantities of debugging
+information are stored in \fI.stabs\fP sections under normal
+compilations.  This debugging information is geared towards aiding
+debuggers locate relocatable objects associated with the dynamic
+objects being debugged.  As relocatable objects aren't made available
+as part of a software release this information has no use.
+.sp
+Not inheriting the correct \fB$(LDFLAGS)\fP from \fIcmd/Makefile.cmd\fP
+(which asserts \fP-s\fP), or \fB$(POST_PROCESS_SO)\fP (which asserts
+\fIstrip -x\fP) are typical reasons for not removing debugging
+information.  Note, removal of debugging information is only enabled
+for release builds. The existence of debugging information is displayed as:
+.sp
+.RS 6
+foo: debugging sections should be deleted  \\
+.br
+    <no strip -x?>
+.RE
+.TP
+\(bu
+All objects should retain their full \fI.symtab\fP symbol table.
+Although this consumes disk space, it provides for more extensive stack
+tracing when debugging user applications.
+.sp
+Hard coding a \fI-s\fP flag with \fB$(LDFLAGS)\fP or
+\fB$(DYNFLAGS)\fP is the typical
+reason for symbol tables being removed.
+Objects that do not contain a symbol table are displayed as:
+.sp
+.RS 6
+foo.so.1: symbol table should not be stripped  \\
+.br
+    <remove -s?>
+.RE
+.TP
+\(bu
+Applications should have a non-executable stack defined to make
+them less vulnerable to buffer overflow attacks.
+.sp
+Not inheriting the \fB$(LDFLAGS)\fP macro in \fIcmd/Makefile.cmd\fP
+is the typical reason for not having a non-executable stack definition.
+Applications without this definition are displayed as:
+.sp
+.RS 6
+foo: application requires non-executable stack \\
+.br
+	<no -Mmapfile_noexstk?>
+.RE
+.sp
+.TP
+\(bu
+x86 applications should have a non-executable data segment defined to make
+them less vulnerable to buffer overflow attacks.
+.sp
+Not inheriting the \fB$(LDFLAGS)\fP macro in \fIcmd/Makefile.cmd\fP
+is the typical reason for not having a non-executable data definition.
+Applications without this definition are displayed as:
+.sp
+.RS 6
+foo: application requires non-executable data \\
+.br
+	<no -Mmapfile_noexdata?>
+.RE
+.sp
+.TP
+\(bu
+Solaris ELF files contain symbol sort sections used by DTrace to
+map addresses in memory to the related function or variable symbols. There
+are two such sections, \fI.SUNW_dynsymsort\fP for
+regular symbols, and \fI.SUNW_dyntlssort\fP for thread-local
+symbols. To ensure that the best names are shown for each
+such address, and that the same name is given across Solaris releases,
+.I check_rtime
+enforces the rule that only one symbol can appear in the sort sections for
+any given address.
+There are two common ways in which multiple symbols 
+or a given address occur in the ON distribution. The first is from
+code written in assembly language. The second is as a 
+result of using \fB#pragma weak\fP in C to create weak symbols. The
+best solution to this
+situation is to modify the code to avoid symbol aliasing. Alternatively,
+the \fBNODYNSORT\fP mapfile attribute can be used to eliminate the unwanted
+symbol.
+.sp
+Duplicate entries in a symbol sort section are
+displayed in one of the following ways, depending on
+whether the section is for regular or thread-local symbols:
+.sp
+.RS 6
+foo: .SUNW_dynsymsort: duplicate ADDRESS: sym1, sym2
+.br
+foo: .SUNW_dyntlssort: duplicate OFFSET: sym1, sym2
+.RE
+.sp
+.TP
+\(bu
+\fBOSNet\fP dynamic ELF objects are expected to employ direct bindings whenever
+feasible.  This runtime binding technique helps to avoid accidental
+interposition problems, and provides a more optimal
+runtime symbol search model.
+.sp
+Not inheriting the correct \fB$(LDFLAGS)\fP from \fIcmd/Makefile.cmd\fP,
+or the correct \fB$(DYNFLAGS)\fP from \fIlib/Makefile.lib\fP, are the
+typical reasons for not enabling direct bindings. Dynamic objects that
+do not contain direct binding information are displayed as:
+.sp
+.RS 6
+foo: object has no direct bindings \\
+.br
+	<no -B direct or -z direct?>
+.RE
+
+.sp
+.LP
+.I check_rtime also
+uses \fBelfdump(1)\fP
+to display useful dynamic entry information under the \fB-i\fP option.
+This doesn't necessarily indicate an error condition, but
+provides information that is often useful for gatekeepers to track
+changes in a release.  Presently the information listed is:
+.TP
+\(bu
+Runpaths are printed for any dynamic object.  This is a historic
+sanity check to insure compiler supplied runpaths (typically from \fBCC\fP)
+are not recorded in any objects.  Runpaths are displayed as:
+.sp
+.RS 6
+foo: RPATH=/usr/bar/lib
+.RE
+.TP
+\(bu
+Needed dependencies are printed for any dynamic object.
+In the freeware world this often helps the introducer of a new
+shared object discover that an existing binary has become its
+consumer, and thus that binaries package dependencies may require updating.
+Dependencies are printed as:
+.sp
+.RS 6
+foo: NEEDED=bar.so.1
+.RE
+.sp
+.LP
+.I check_rtime
+uses \fBmcs(1)\fP to inspect an object's \fI.comment\fP section.
+During development, this section contains numerous file identifiers
+marked with the tag "\fB@(#)\fP".  For release builds these sections
+are deleted and rewritten under control of the \fB$(POST_PROCESS)\fP
+macro to produce a common release identifier.  This identifier
+typically consists of three lines including a single comment starting
+with the string "\fB@(#) SunOS\fP".  If this common identifier isn't
+found the following diagnostic is generated:
+.sp
+.RS 6
+foo: non-conforming mcs(1) comment  <no $(POST_PROCESS)?>
+.RE
+.sp
+.LP
+.I check_rtime
+uses \fBpvs(1)\fP to display version definitions under the \fB-v\fP option.
+Each symbol defined by the object is shown along with the version it belongs to.
+Changes to the symbols defined by an object, or the versions they belong to,
+do not necessarily indicate an error condition, but
+provides information that is often useful for gatekeepers to track
+changes in a release.
+.RE
+.sp
+.LP
+.SH OPTIONS
+.LP
+The following options are supported:
+.TP 4
+.B \-D depfile
+Use \fIdepfile\fP to generate an alternative dependency mapping.
+\fIdepfile\fP must be created by '\fBfind_elf -r\fP'.
+The \fB-D\fP and \fB-d\fP options are mutually exclusive.
+.TP
+.B \-d depdir
+Use \fIdepdir\fP to generate an alternative dependency mapping.
+\fBfind_elf(1ONBLD)\fP is used to locate the ELF sharable objects for
+which alternative mappings are required. The \fB-D\fP and \fB-d\fP options
+are mutually exclusive.
+.TP 4
+.B \-E errfile
+Direct error messages for the analyzed objects to \fIerrfile\fP instead 
+of stdout.
+.TP 4
+.B \-e exfile
+An exception file is used to exclude objects from
+the usual rules. See EXCEPTION FILE FORMAT.
+.TP
+.B \-f listfile
+Normally,
+.I interface_check
+runs
+.I find_elf
+to locate the ELF objects to analyze. The \fB-f\fP option can be
+used to instead provide a file containing the list of objects to
+analyze, in the format produced by '\fBfind_elf -r\fP'.
+.TP
+.B -I infofile
+Direct informational messages (\fB-i\fP, and \fB-v\fP options) for the
+analyzed objects to \fIinfofile\fP instead of stdout.
+.TP
+.B \-i
+Provide dynamic entry information.  Presently only dependencies and
+runpaths are printed.
+.TP
+.B \-m
+Enable \fBmcs(1)\fP checking.
+.TP
+.B \-o
+Produce a one-line output for each condition discovered, prefixed
+by the objects name.  This output style is more terse, but is
+more appropriate for sorting and diffing with previous build results.
+.TP
+.B \-s
+Determine whether \fI.stabs\fP sections exist.
+.TP
+.B \-v
+Provide version definition information. Each symbol defined by the object
+is printed along with the version it is assigned to.
+.TP
+.B -w outdir
+Interpret the paths of all input and output files relative to \fIoutdir\fP.
+.LP
+.SH EXCEPTION FILE FORMAT
+Exceptions to the rules enforced by
+.I check_rtime
+are specified using an exception file. The \fB-e\fP option is used to
+specify an explicit exception file. Otherwise, if used in an activated
+workspace, the default exception file is
+$CODEMGR_WS/exception_list/check_rtime
+if that file exists. If not used in an activated workspace, or if
+$CODEMGR_WS/exception_list/check_rtime does not exist,
+.I check_rtime
+will use
+.I /opt/onbld/etc/exception_list/check_rtime
+as a fallback default exception file.
+.p
+To run
+.I check_rtime
+without applying exceptions, specify \fB-e\fP with a value of /dev/null.
+.P
+A '#' character at the beginning of a line, or at any point in
+a line when preceded by whitespace, introduces a comment. Empty lines, 
+and lines containing only comments, are ignored by
+.I check_rtime.
+Exceptions are specified as space separated keyword, and \fBperl(1)\fP
+regular expression:
+.sp
+.in +4
+.nf
+keyword  perl-regex
+.fi
+.in -4
+.sp
+Since whitespace is used as a separator, the regular
+expression cannot itself contain whitespace. Use of the \\s character
+class to represent whitespace within the regular expression is recommended.
+Before the perl regular expression is used, constructs of the form
+MACH(dir) are expanded into a regular expression that matches the directory
+given, as well as any 64-bit architecture subdirectory that
+might be present (i.e. amd64, sparcv9). For instance, MACH(lib) will
+match any of the following:
+.sp
+.in +4
+.nf
+lib
+lib/amd64
+lib/sparcv9
+.fi
+.in -4
+.sp
+The exceptions understood by
+.I check_rtime
+are:
+.sp
+.ne 2
+.mk
+.na
+\fBEXEC_DATA\fR
+.ad
+.RS 17n
+.rt
+.sp
+Executables that are not required to have non-executable writable
+data segments
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBEXEC_STACK\fR
+.ad
+.RS 17n
+.rt
+.sp
+Executables that are not required to have a non-executable stack
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBNOCRLEALT\fR
+.ad
+.RS 17n
+.rt
+.sp
+Objects that should be skipped when building the alternative dependency 
+mapping via the \fB-d\fP option.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBNODIRECT\fR
+.ad
+.RS 17n
+.rt
+.sp
+Directories and files that are allowed to have no direct bound symbols.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBNOSYMSORT\fR
+.ad
+.RS 17n
+.rt
+.sp
+Files for which we skip checking of duplicate addresses in the
+symbol sort sections.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBOLDDEP\fR
+.ad
+.RS 17n
+.rt
+.sp
+Objects that used to contain system functionality that has since
+migrated to libc. We preserve these libraries as pure filters for
+backward compatibility but nothing needs to link to them.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBSKIP\fR
+.ad
+.RS 17n
+.rt
+.sp
+Directories and/or individual objects to skip. Note that SKIP should be
+a last resort, used only when one of the other exceptions will not suffice.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBSTAB\fR
+.ad
+.RS 17n
+.rt
+.sp
+Objects that are allowed to contain debugging information (stabs).
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBTEXTREL\fR
+.ad
+.RS 17n
+.rt
+.sp
+Objects for which we allow relocations to the text segment.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBUNDEF_OBJ\fR
+.ad
+.RS 17n
+.rt
+.sp
+Objects that are allowed to be unreferenced.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBUNDEF_REF\fR
+.ad
+.RS 17n
+.rt
+.sp
+Objects that are allowed undefined references.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBUNUSED_DEPS\fR
+.ad
+.RS 17n
+.rt
+.sp
+Objects that are allowed to have unused dependencies.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBUNUSED_OBJ\fR
+.ad
+.RS 17n
+.rt
+.sp
+Objects that are always allowed to be unused dependencies.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBUNUSED_RPATH\fR
+.ad
+.RS 17n
+.rt
+.sp
+Objects that are allowed to have unused runpath directories.
+.RE
+
+.LP
+.SH ALTERNATIVE DEPENDENCY MAPPING
+.I check_rtime
+was primarily designed to process a nightly builds \fB$ROOT\fP
+hierarchy. It is often the case that objects within this hierarchy
+must bind to dependencies within the same hierarchy to satisfy
+their requirements.
+.LP
+To achieve this,
+.I check_rtime
+uses the shared objects specified with the \fB-D\fP or \fB-d\fP options.
+If neither option is specified, and the \fB$CODEMGR_WS\fP and \fB$ROOT\fP
+environment variables are defined, the proto area for the workspace
+is used. The objects found are used
+to create runtime configuration files via \fBcrle(1)\fP, that establish
+the new shared objects as alternatives to their underlying system location.
+.I check_rtime
+passes these configuration files as \fBLD_CONFIG\fP environment
+variable settings to \fBldd(1)\fP using its \fB-e\fP option.
+.LP
+The effect of these configuration files is that the execution of an
+object under \fBldd(1)\fP will bind to the dependencies defined as
+alternatives.  Simply put, an object inspected in the \fIproto\fP
+area will bind to its dependencies found in the \fIproto\fP area.
+Dependencies that have no alternative mapping will continue to
+bind to the underlying system.
+.LP
+.SH ENVIRONMENT VARIABLES
+.LP
+When the \fB-D\fP or \fB-d\fP option isn't in use,
+.I check_rtime
+uses the following environment variables to
+establish an alternative dependency mapping:
+.LP
+.B CODEMGR_WS
+.RS 4
+The root of your workspace, which is the directory
+containing \fICodemgr_wsdata\fP. Existence of this environment variable
+indicates that \fB$ROOT\fP should be investigated.
+.RE
+.LP
+.B ROOT
+.RS 4
+Root of the \fIproto\fP area of your workspace. Any shared objects
+under this directory will be used to establish an alternative dependency
+mapping.
+.RE
+.sp
+If \fBldd(1)\fP supports the \fB-U\fP option, it will be used to determine
+any unreferenced dependencies.  Otherwise \fBldd(1)\fP uses the older
+\fB-u\fP option which only detects unused references.  If the following
+environment variable exists, and indicates an earlier release than \fB5.10\fP
+then \fBldd(1)\fP also falls back to using the \fB-u\fP option.
+.RE
+.LP
+.B RELEASE
+.RS 4
+The release version number of the environment being built.
+.RE
+.SH ERROR CONDITIONS
+.LP
+Inspection of an object with \fBldd(1)\fP assumes it is compatible
+with the machine on which
+.I check_rtime
+is being run.  Incompatible objects such as a 64-bit object encountered on
+a 32-bit system, or an i386 object encountered on a sparc system,
+can not be fully inspected.  These objects are displayed as:
+.sp
+.RS 4
+foo: has wrong class or data encoding
+.RE
+.LP
+.SH FILES
+.LP
+.RS 5
+$CODEMGR_WS/exception_list/check_rtime
+/opt/onbld/etc/exception_list/check_rtime
+.SH SEE ALSO
+.B crle(1),
+.B elfdump(1),
+.B find_elf(1ONBLD),
+.B ldd(1),
+.B ld.so.1(1),
+.B mcs(1).
--- old/usr/src/tools/scripts/checkpaths.1	Wed Sep 30 19:35:39 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,84 +0,0 @@
-.\" ident	"%Z%%M%	%I%	%E% SMI"
-.\" Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License, Version 1.0 only
-.\" (the "License").  You may not use this file except in compliance
-.\" with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.TH checkpaths 1 "25 September 2003"
-.SH NAME
-.I checkpaths
-\- check file path containing files
-.SH SYNOPSIS
-\fBcheckpaths [-b] [root_paths...]\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "checkpaths" "" "\fBcheckpaths\fP"
-.LP
-.I checkpaths
-inspects the contents of various files within an OS-Net workspace to
-ensure that the file paths listed in those files are valid.  This
-provides an integrity check of the workspace to catch cases where a
-file was removed or renamed without updating the corresponding
-\fIinc.flg\fP, \fIcry_files\fP, or \fIexception_list\fP entry.
-.LP
-.I checkpaths
-is typically called from \fBnightly(1)\fP.  It may be invoked
-interactively within a workspace, and requires that at least
-\fI$CODEMGR_WS\fP is set to a valid workspace.  It is not necessary
-that a full build has been performed in the workspace to be tested,
-but if full build(s) are not available under the
-\fI$CODEMGR_WS/proto/\fP directory, then the corresponding exclusion
-lists are not verified.
-.LP
-.SH OPTIONS
-.LP
-The following options are supported:
-.TP 4
-.B \-b
-Disable processing of files that list derived (built) objects.  This
-should be set if the \fI$CODEMGR_WS/proto/\fP directory exists, but
-the contents are known to be bad.  \fBnightly(1)\fP will typically set
-this flag if the build fails.
-.LP
-.TP 4
-.B root_paths...
-By default, checkpaths validates all of the proto areas for known
-architectures that exist in the \fI$CODEMGR_WS/proto/\fP directory.
-To specify other root directories, list them as arguments on the
-command line.  It is an error if any of the root paths specified does
-not end with a known architecture.
-.LP
-.SH ENVIRONMENT VARIABLES
-.LP
-.B CODEMGR_WS
-.RS 4
-The root of your TeamWare workspace, which is the directory
-containing \fICodemgr_wsdata\fP.
-.RE
-.LP
-.B SRC
-.RS 4
-The location of your ON source tree.  Defaults to
-\fI$CODEMGR_WS/usr/src/\fP if not specified.
-.RE
-.LP
-.SH SEE ALSO
-.B nightly(1).
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/checkpaths.1onbld	Wed Sep 30 19:35:39 2015
@@ -0,0 +1,83 @@
+.\" Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License, Version 1.0 only
+.\" (the "License").  You may not use this file except in compliance
+.\" with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.TH checkpaths 1ONBLD "25 September 2003"
+.SH NAME
+.I checkpaths
+\- check file path containing files
+.SH SYNOPSIS
+\fBcheckpaths [-b] [root_paths...]\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "checkpaths" "" "\fBcheckpaths\fP"
+.LP
+.I checkpaths
+inspects the contents of various files within an OS-Net workspace to
+ensure that the file paths listed in those files are valid.  This
+provides an integrity check of the workspace to catch cases where a
+file was removed or renamed without updating the corresponding
+\fIinc.flg\fP, \fIcry_files\fP, or \fIexception_list\fP entry.
+.LP
+.I checkpaths
+is typically called from \fBnightly(1ONBLD)\fP.  It may be invoked
+interactively within a workspace, and requires that at least
+\fI$CODEMGR_WS\fP is set to a valid workspace.  It is not necessary
+that a full build has been performed in the workspace to be tested,
+but if full build(s) are not available under the
+\fI$CODEMGR_WS/proto/\fP directory, then the corresponding exclusion
+lists are not verified.
+.LP
+.SH OPTIONS
+.LP
+The following options are supported:
+.TP 4
+.B \-b
+Disable processing of files that list derived (built) objects.  This
+should be set if the \fI$CODEMGR_WS/proto/\fP directory exists, but
+the contents are known to be bad.  \fBnightly(1ONBLD)\fP will typically set
+this flag if the build fails.
+.LP
+.TP 4
+.B root_paths...
+By default, checkpaths validates all of the proto areas for known
+architectures that exist in the \fI$CODEMGR_WS/proto/\fP directory.
+To specify other root directories, list them as arguments on the
+command line.  It is an error if any of the root paths specified does
+not end with a known architecture.
+.LP
+.SH ENVIRONMENT VARIABLES
+.LP
+.B CODEMGR_WS
+.RS 4
+The root of your TeamWare workspace, which is the directory
+containing \fICodemgr_wsdata\fP.
+.RE
+.LP
+.B SRC
+.RS 4
+The location of your ON source tree.  Defaults to
+\fI$CODEMGR_WS/usr/src/\fP if not specified.
+.RE
+.LP
+.SH SEE ALSO
+.B nightly(1ONBLD).
--- old/usr/src/tools/scripts/cstyle.1	Wed Sep 30 19:35:39 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,167 +0,0 @@
-.\" Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.TH cstyle 1 "28 March 2005"
-.SH NAME
-.I cstyle
-\- check for some common stylistic errors in C source files
-.SH SYNOPSIS
-\fBcstyle [-chpvCP] [-o constructs] [file...]\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "cstyle" "" "\fBcstyle\fP"
-.LP
-.I cstyle
-inspects C source files (*.c and *.h) for common sylistic errors.  It
-attempts to check for the cstyle documented in 
-\fI/shared/ON/general_docs/cstyle.ms.pdf\fP.  Note that there is much
-in that document that
-.I cannot
-be checked for; just because your code is \fBcstyle(1)\fP clean does not
-mean that you've followed Sun's C style.  \fICaveat emptor\fP.
-.LP
-.SH OPTIONS
-.LP
-The following options are supported:
-.TP 4
-.B \-c
-Check continuation line indentation inside of functions.  Sun's C style
-states that all statements must be indented to an appropriate tab stop,
-and any continuation lines after them must be indented \fIexactly\fP four
-spaces from the start line.  This option enables a series of checks
-designed to find contination line problems within functions only.  The
-checks have some limitations;  see CONTINUATION CHECKING, below.
-.LP
-.TP 4
-.B \-h
-Performs heuristic checks that are sometimes wrong.  Not generally used.
-.LP
-.TP 4
-.B \-p
-Performs some of the more picky checks.  Includes ANSI #else and #endif
-rules, and tries to detect spaces after casts.  Used as part of the
-putback checks.
-.LP
-.TP 4
-.B \-v
-Verbose output;  includes the text of the line of error, and, for
-\fB-c\fP, the first statement in the current continuation block.
-.LP
-.TP 4
-.B \-C
-Ignore errors in header comments (i.e. block comments starting in the
-first column).  Not generally used.
-.LP
-.TP 4
-.B \-P
-Check for use of non-POSIX types.  Historically, types like "u_int" and
-"u_long" were used, but they are now deprecated in favor of the POSIX
-types uint_t, ulong_t, etc.  This detects any use of the deprecated
-types.  Used as part of the putback checks.
-.LP
-.TP 4
-.B \-o \fIconstructs\fP
-Allow a comma-seperated list of additional constructs.  Available
-constructs include:
-.LP
-.TP 10
-.B doxygen
-Allow doxygen-style block comments (\fB/**\fP and \fB/*!\fP)
-.LP
-.TP 10
-.B splint
-Allow splint-style lint comments (\fB/*@...@*/\fP)
-.LP
-.SH NOTES
-.LP
-The cstyle rule for the OS/Net consolidation is that all new files must
-be \fB-pP\fP clean.  For existing files, the following invocations are
-run against both the old and new files:
-.LP
-.TP 4
-\fBcstyle file\fB
-.LP
-.TP 4
-\fBcstyle -p file\fB
-.LP
-.TP 4
-\fBcstyle -pP file\fB
-.LP
-If the old file gave no errors for one of the invocations, the new file
-must also give no errors.  This way, files can only become more clean.
-.LP
-.SH CONTINUATION CHECKING
-.LP
-The continuation checker is a resonably simple state machine that knows
-something about how C is layed out, and can match parenthesis, etc. over
-multiple lines.  It does have some limitations:
-.LP
-.TP 4
-.B 1.
-Preprocessor macros which cause unmatched parenthesis will confuse the
-checker for that line.  To fix this, you'll need to make sure that each
-branch of the #if statement has balanced parenthesis.
-.LP
-.TP 4
-.B 2.
-Some \fBcpp\fP macros do not require ;s after them.  Any such macros
-*must* be ALL_CAPS; any lower case letters will cause bad output.
-.LP
-The bad output will generally be corrected after the next \fB;\fP,
-\fB{\fP, or \fB}\fP.
-.LP
-Some continuation error messages deserve some additional explanation
-.LP
-.TP 4
-.B
-multiple statements continued over multiple lines
-A multi-line statement which is not broken at statement
-boundries.  For example:
-.RS 4
-.HP 4
-if (this_is_a_long_variable == another_variable) a =
-.br
-b + c;
-.LP
-Will trigger this error.  Instead, do:
-.HP 8
-if (this_is_a_long_variable == another_variable)
-.br
-a = b + c;
-.RE
-.LP
-.TP 4
-.B
-empty if/for/while body not on its own line
-For visibility, empty bodies for if, for, and while statements should be
-on their own line.  For example:
-.RS 4
-.HP 4
-while (do_something(&x) == 0);
-.LP
-Will trigger this error.  Instead, do:
-.HP 8
-while (do_something(&x) == 0)
-.br
-;
-.RE
-
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/cstyle.1onbld	Wed Sep 30 19:35:39 2015
@@ -0,0 +1,167 @@
+.\" Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.TH cstyle 1ONBLD "28 March 2005"
+.SH NAME
+.I cstyle
+\- check for some common stylistic errors in C source files
+.SH SYNOPSIS
+\fBcstyle [-chpvCP] [-o constructs] [file...]\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "cstyle" "" "\fBcstyle\fP"
+.LP
+.I cstyle
+inspects C source files (*.c and *.h) for common sylistic errors.  It
+attempts to check for the cstyle documented in 
+\fI/shared/ON/general_docs/cstyle.ms.pdf\fP.  Note that there is much
+in that document that
+.I cannot
+be checked for; just because your code is \fBcstyle(1ONBLD)\fP clean does not
+mean that you've followed Sun's C style.  \fICaveat emptor\fP.
+.LP
+.SH OPTIONS
+.LP
+The following options are supported:
+.TP 4
+.B \-c
+Check continuation line indentation inside of functions.  Sun's C style
+states that all statements must be indented to an appropriate tab stop,
+and any continuation lines after them must be indented \fIexactly\fP four
+spaces from the start line.  This option enables a series of checks
+designed to find contination line problems within functions only.  The
+checks have some limitations;  see CONTINUATION CHECKING, below.
+.LP
+.TP 4
+.B \-h
+Performs heuristic checks that are sometimes wrong.  Not generally used.
+.LP
+.TP 4
+.B \-p
+Performs some of the more picky checks.  Includes ANSI #else and #endif
+rules, and tries to detect spaces after casts.  Used as part of the
+putback checks.
+.LP
+.TP 4
+.B \-v
+Verbose output;  includes the text of the line of error, and, for
+\fB-c\fP, the first statement in the current continuation block.
+.LP
+.TP 4
+.B \-C
+Ignore errors in header comments (i.e. block comments starting in the
+first column).  Not generally used.
+.LP
+.TP 4
+.B \-P
+Check for use of non-POSIX types.  Historically, types like "u_int" and
+"u_long" were used, but they are now deprecated in favor of the POSIX
+types uint_t, ulong_t, etc.  This detects any use of the deprecated
+types.  Used as part of the putback checks.
+.LP
+.TP 4
+.B \-o \fIconstructs\fP
+Allow a comma-seperated list of additional constructs.  Available
+constructs include:
+.LP
+.TP 10
+.B doxygen
+Allow doxygen-style block comments (\fB/**\fP and \fB/*!\fP)
+.LP
+.TP 10
+.B splint
+Allow splint-style lint comments (\fB/*@...@*/\fP)
+.LP
+.SH NOTES
+.LP
+The cstyle rule for the OS/Net consolidation is that all new files must
+be \fB-pP\fP clean.  For existing files, the following invocations are
+run against both the old and new files:
+.LP
+.TP 4
+\fBcstyle file\fB
+.LP
+.TP 4
+\fBcstyle -p file\fB
+.LP
+.TP 4
+\fBcstyle -pP file\fB
+.LP
+If the old file gave no errors for one of the invocations, the new file
+must also give no errors.  This way, files can only become more clean.
+.LP
+.SH CONTINUATION CHECKING
+.LP
+The continuation checker is a resonably simple state machine that knows
+something about how C is layed out, and can match parenthesis, etc. over
+multiple lines.  It does have some limitations:
+.LP
+.TP 4
+.B 1.
+Preprocessor macros which cause unmatched parenthesis will confuse the
+checker for that line.  To fix this, you'll need to make sure that each
+branch of the #if statement has balanced parenthesis.
+.LP
+.TP 4
+.B 2.
+Some \fBcpp\fP macros do not require ;s after them.  Any such macros
+*must* be ALL_CAPS; any lower case letters will cause bad output.
+.LP
+The bad output will generally be corrected after the next \fB;\fP,
+\fB{\fP, or \fB}\fP.
+.LP
+Some continuation error messages deserve some additional explanation
+.LP
+.TP 4
+.B
+multiple statements continued over multiple lines
+A multi-line statement which is not broken at statement
+boundries.  For example:
+.RS 4
+.HP 4
+if (this_is_a_long_variable == another_variable) a =
+.br
+b + c;
+.LP
+Will trigger this error.  Instead, do:
+.HP 8
+if (this_is_a_long_variable == another_variable)
+.br
+a = b + c;
+.RE
+.LP
+.TP 4
+.B
+empty if/for/while body not on its own line
+For visibility, empty bodies for if, for, and while statements should be
+on their own line.  For example:
+.RS 4
+.HP 4
+while (do_something(&x) == 0);
+.LP
+Will trigger this error.  Instead, do:
+.HP 8
+while (do_something(&x) == 0)
+.br
+;
+.RE
+
--- old/usr/src/tools/scripts/find_elf.1	Wed Sep 30 19:35:39 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,225 +0,0 @@
-.\" Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.TH find_elf 1 "25 March 2010"
-.SH NAME
-find_elf \- Locate ELF shared objects and executables
-.SH SYNOPSIS
-\fBfind_elf [-afrs] path\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "find_elf" "" "\fBfind_elf\fP"
-The
-.I find_elf
-command descends a directory hierarchy and produces one line
-of output on stdout for each ELF executable or shared object found.
-.LP
-.SH OPTIONS
-.LP
-The following options are supported:
-.TP 4
-.B \-a
-Disable alias processing. Symbolic links are treated as independent
-files, each such link results in a separate OBJECT output line,
-and ALIAS lines are not issued.
-.TP 4
-.B \-f
-Fast Mode. When reading directories, the file name and modes are
-used to eliminate files from consideration and speed up the search:
-Directories with names that start with a '.' character are skipped.
-Executables must have the execute bit set, and
-shared objects must end with a .so extension. Files that do not
-meet these requirements are silently eliminated from consideration without
-further analysis.
-.TP 4
-.B \-r
-Report file names as relative paths, relative to the given file or directory,
-instead of fully qualified.
-.TP 4
-.B \-s
-Only report shared objects.
-.LP
-.SH OUTPUT
-.LP
-.I find_elf
-produces a series of PREFIX, OBJECT, and ALIAS lines, which collectively
-describe the ELF objects located. Whitespace is used within each
-line to delimit the various fields of information provided.
-.P
-If the \fB-r\fP option is used to specify that file names be reported
-as relative paths, a PREFIX line is output to provide the base path from
-which the relative names should be interpreted.
-There can only be one PREFIX line, and it is output first, before any
-OBJECT or ALIAS lines.
-.sp
-.in +4
-.nf
-PREFIX path
-.fi
-.in -4
-.sp
-For each object found, an OBJECT line is produced to describe it:
-.sp
-.in +4
-.nf
-OBJECT [32 | 64] [DYN | EXEC] [VERDEF | NOVERDEF] object-path
-.fi
-.in -4
-.sp
-The first field provides the ELF class of the object, and will be
-either 32 or 64. 
-The second field provides the type of object, either
-a shared object (DYN) or executable (EXEC).
-The third field will be VERDEF if the object contains ELF
-version definitions, and NOVERDEF if the object is not versioned.
-The final field gives the path to the object.
-.P
-Under Unix, a file can have multiple names. In the context of ELF
-objects, this often happens for one of two reasons:
-.RS +4
-.TP
-.ie t \(bu
-.el o
-Compilation symlinks, used to provide a non-versioned name for a shared object.
-.RE
-.RS +4
-.TP
-.ie t \(bu
-.el o 
-Symlinks such as '32' and '64' used to provide alternative
-non-machine specific paths to objects.
-.RE
-.sp
-When
-.I find_elf
-identifies an object via such an aliased name, it issues an ALIAS line
-mapping it to the main name for the object:
-.sp
-.in +4
-.nf
-ALIAS object-path alias-path
-.fi
-.in -4
-.sp
-The \fB-a\fP option alters the handling of aliased names. When \fB-a\fP is
-specified, each file results in a separate OBJECT line, as if they were
-independent files rather than the same file with different names.
-.sp
-.PP
-.SH EXAMPLES
-Assume the following hierarchy of files exist under /usr/lib/foo:
-.sp
-.in +4
-.nf
-% /bin/ls -alRF /usr/lib/foo
-/usr/lib/foo:
-total 111
-drwxr-xr-x  3 root root    7 Jul 16 17:35 ./
-drwxr-xr-x 34 root root   42 Jul 16 17:34 ../
-lrwxrwxrwx  1 root bin     1 Jul 16 17:34 32 -> ./
-lrwxrwxrwx  1 root bin     5 Jul 16 17:34 64 -> amd64/
-drwxr-xr-x  2 root bin     4 Jul 16 17:35 amd64/
-lrwxrwxrwx  1 root bin    11 Jul 16 17:35 libfoo.so -> libfoo.so.1*
--rwxr-xr-x  1 root bin 49132 Jul 16 17:35 libfoo.so.1*
-
-/usr/lib/foo/amd64:
-total 150
-drwxr-xr-x  2 root root   4 Jul 16 17:35 ./
-drwxr-xr-x  3 root root   7 Jul 16 17:35 ../
-lrwxrwxrwx  1 root bin    11 Jul 16 17:35 libfoo.so -> libfoo.so.1*
--rwxr-xr-x  1 root bin 72536 Jul 16 17:35 libfoo.so.1*
-.fi
-.in -4
-.sp
-This hierarchy contains compilation symlinks (libfoo.so) and
-path alias symlinks (32, 64), as discussed in OUTPUT.
-.p
-.I find_elf
-produces the following output for the above hierarchy:
-.sp
-.in +4
-.nf
-% find_elf -r /usr/lib/foo
-PREFIX /usr/lib/foo
-OBJECT 64 DYN  VERDEF  amd64/libfoo.so.1
-ALIAS                  amd64/libfoo.so.1  64/libfoo.so
-ALIAS                  amd64/libfoo.so.1  64/libfoo.so.1
-ALIAS                  amd64/libfoo.so.1  amd64/libfoo.so
-OBJECT 32 DYN  VERDEF  libfoo.so.1
-ALIAS                  libfoo.so.1        32/libfoo.so
-ALIAS                  libfoo.so.1        32/libfoo.so.1
-ALIAS                  libfoo.so.1        libfoo.so
-.fi
-.in -4
-.sp
-Contrast this with the output when \fB-a\fP is used to treat
-each name as an independent file:
-.sp
-.in +4
-.nf
-% find_elf -ar /usr/lib/foo
-PREFIX /usr/lib/foo
-OBJECT 32 DYN  VERDEF  32/libfoo.so
-OBJECT 32 DYN  VERDEF  32/libfoo.so.1
-OBJECT 64 DYN  VERDEF  64/libfoo.so
-OBJECT 64 DYN  VERDEF  64/libfoo.so.1
-OBJECT 64 DYN  VERDEF  amd64/libfoo.so.1
-OBJECT 64 DYN  VERDEF  amd64/libfoo.so
-OBJECT 32 DYN  VERDEF  libfoo.so.1
-OBJECT 32 DYN  VERDEF  libfoo.so
-.fi
-.in -4
-.sp
-When
-.I find_elf
-is used to process an alias for which no target object is given,
-there will be no output. For example, using /lib/libc.so, which
-is a compilation symlink for /lib/libc.so.1:
-.sp
-.in +4
-.nf
-% find_elf /lib/libc.so
-.fi
-.in -4
-.sp
-In such situations, the \fB-a\fP option can be used to produce
-the desired output:
-.sp
-.in +4
-.nf
-% find_elf -a /lib/libc.so
-OBJECT 32 DYN  VERDEF   /lib/libc.so
-.fi
-.in -4
-.sp
-.PP
-.RS
-.nf
-.SH SEE ALSO
-.BR check_rtime (1),
-.BR interface_check (1),
-.BR interface_cmp (1),
-.BR ld (1),
-.BR ldd (1),
-.BR elfdump (1),
-.BR pvs (1).
-.LP
-.TZ LLM
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/find_elf.1onbld	Wed Sep 30 19:35:39 2015
@@ -0,0 +1,225 @@
+.\" Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.TH find_elf 1ONBLD "25 March 2010"
+.SH NAME
+find_elf \- Locate ELF shared objects and executables
+.SH SYNOPSIS
+\fBfind_elf [-afrs] path\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "find_elf" "" "\fBfind_elf\fP"
+The
+.I find_elf
+command descends a directory hierarchy and produces one line
+of output on stdout for each ELF executable or shared object found.
+.LP
+.SH OPTIONS
+.LP
+The following options are supported:
+.TP 4
+.B \-a
+Disable alias processing. Symbolic links are treated as independent
+files, each such link results in a separate OBJECT output line,
+and ALIAS lines are not issued.
+.TP 4
+.B \-f
+Fast Mode. When reading directories, the file name and modes are
+used to eliminate files from consideration and speed up the search:
+Directories with names that start with a '.' character are skipped.
+Executables must have the execute bit set, and
+shared objects must end with a .so extension. Files that do not
+meet these requirements are silently eliminated from consideration without
+further analysis.
+.TP 4
+.B \-r
+Report file names as relative paths, relative to the given file or directory,
+instead of fully qualified.
+.TP 4
+.B \-s
+Only report shared objects.
+.LP
+.SH OUTPUT
+.LP
+.I find_elf
+produces a series of PREFIX, OBJECT, and ALIAS lines, which collectively
+describe the ELF objects located. Whitespace is used within each
+line to delimit the various fields of information provided.
+.P
+If the \fB-r\fP option is used to specify that file names be reported
+as relative paths, a PREFIX line is output to provide the base path from
+which the relative names should be interpreted.
+There can only be one PREFIX line, and it is output first, before any
+OBJECT or ALIAS lines.
+.sp
+.in +4
+.nf
+PREFIX path
+.fi
+.in -4
+.sp
+For each object found, an OBJECT line is produced to describe it:
+.sp
+.in +4
+.nf
+OBJECT [32 | 64] [DYN | EXEC] [VERDEF | NOVERDEF] object-path
+.fi
+.in -4
+.sp
+The first field provides the ELF class of the object, and will be
+either 32 or 64. 
+The second field provides the type of object, either
+a shared object (DYN) or executable (EXEC).
+The third field will be VERDEF if the object contains ELF
+version definitions, and NOVERDEF if the object is not versioned.
+The final field gives the path to the object.
+.P
+Under Unix, a file can have multiple names. In the context of ELF
+objects, this often happens for one of two reasons:
+.RS +4
+.TP
+.ie t \(bu
+.el o
+Compilation symlinks, used to provide a non-versioned name for a shared object.
+.RE
+.RS +4
+.TP
+.ie t \(bu
+.el o 
+Symlinks such as '32' and '64' used to provide alternative
+non-machine specific paths to objects.
+.RE
+.sp
+When
+.I find_elf
+identifies an object via such an aliased name, it issues an ALIAS line
+mapping it to the main name for the object:
+.sp
+.in +4
+.nf
+ALIAS object-path alias-path
+.fi
+.in -4
+.sp
+The \fB-a\fP option alters the handling of aliased names. When \fB-a\fP is
+specified, each file results in a separate OBJECT line, as if they were
+independent files rather than the same file with different names.
+.sp
+.PP
+.SH EXAMPLES
+Assume the following hierarchy of files exist under /usr/lib/foo:
+.sp
+.in +4
+.nf
+% /bin/ls -alRF /usr/lib/foo
+/usr/lib/foo:
+total 111
+drwxr-xr-x  3 root root    7 Jul 16 17:35 ./
+drwxr-xr-x 34 root root   42 Jul 16 17:34 ../
+lrwxrwxrwx  1 root bin     1 Jul 16 17:34 32 -> ./
+lrwxrwxrwx  1 root bin     5 Jul 16 17:34 64 -> amd64/
+drwxr-xr-x  2 root bin     4 Jul 16 17:35 amd64/
+lrwxrwxrwx  1 root bin    11 Jul 16 17:35 libfoo.so -> libfoo.so.1*
+-rwxr-xr-x  1 root bin 49132 Jul 16 17:35 libfoo.so.1*
+
+/usr/lib/foo/amd64:
+total 150
+drwxr-xr-x  2 root root   4 Jul 16 17:35 ./
+drwxr-xr-x  3 root root   7 Jul 16 17:35 ../
+lrwxrwxrwx  1 root bin    11 Jul 16 17:35 libfoo.so -> libfoo.so.1*
+-rwxr-xr-x  1 root bin 72536 Jul 16 17:35 libfoo.so.1*
+.fi
+.in -4
+.sp
+This hierarchy contains compilation symlinks (libfoo.so) and
+path alias symlinks (32, 64), as discussed in OUTPUT.
+.p
+.I find_elf
+produces the following output for the above hierarchy:
+.sp
+.in +4
+.nf
+% find_elf -r /usr/lib/foo
+PREFIX /usr/lib/foo
+OBJECT 64 DYN  VERDEF  amd64/libfoo.so.1
+ALIAS                  amd64/libfoo.so.1  64/libfoo.so
+ALIAS                  amd64/libfoo.so.1  64/libfoo.so.1
+ALIAS                  amd64/libfoo.so.1  amd64/libfoo.so
+OBJECT 32 DYN  VERDEF  libfoo.so.1
+ALIAS                  libfoo.so.1        32/libfoo.so
+ALIAS                  libfoo.so.1        32/libfoo.so.1
+ALIAS                  libfoo.so.1        libfoo.so
+.fi
+.in -4
+.sp
+Contrast this with the output when \fB-a\fP is used to treat
+each name as an independent file:
+.sp
+.in +4
+.nf
+% find_elf -ar /usr/lib/foo
+PREFIX /usr/lib/foo
+OBJECT 32 DYN  VERDEF  32/libfoo.so
+OBJECT 32 DYN  VERDEF  32/libfoo.so.1
+OBJECT 64 DYN  VERDEF  64/libfoo.so
+OBJECT 64 DYN  VERDEF  64/libfoo.so.1
+OBJECT 64 DYN  VERDEF  amd64/libfoo.so.1
+OBJECT 64 DYN  VERDEF  amd64/libfoo.so
+OBJECT 32 DYN  VERDEF  libfoo.so.1
+OBJECT 32 DYN  VERDEF  libfoo.so
+.fi
+.in -4
+.sp
+When
+.I find_elf
+is used to process an alias for which no target object is given,
+there will be no output. For example, using /lib/libc.so, which
+is a compilation symlink for /lib/libc.so.1:
+.sp
+.in +4
+.nf
+% find_elf /lib/libc.so
+.fi
+.in -4
+.sp
+In such situations, the \fB-a\fP option can be used to produce
+the desired output:
+.sp
+.in +4
+.nf
+% find_elf -a /lib/libc.so
+OBJECT 32 DYN  VERDEF   /lib/libc.so
+.fi
+.in -4
+.sp
+.PP
+.RS
+.nf
+.SH SEE ALSO
+.BR check_rtime (1ONBLD),
+.BR interface_check (1ONBLD),
+.BR interface_cmp (1ONBLD),
+.BR ld (1),
+.BR ldd (1),
+.BR elfdump (1),
+.BR pvs (1).
+.LP
+.TZ LLM
--- old/usr/src/tools/scripts/flg.flp.1	Wed Sep 30 19:35:39 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,54 +0,0 @@
-.\" ident	"%Z%%M%	%I%	%E% SMI"
-.\" " CDDL HEADER START
-.\" "
-.\" " The contents of this file are subject to the terms of the
-.\" " Common Development and Distribution License, Version 1.0 only
-.\" " (the "License").  You may not use this file except in compliance
-.\" " with the License.
-.\" "
-.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" " or http://www.opensolaris.org/os/licensing.
-.\" " See the License for the specific language governing permissions
-.\" " and limitations under the License.
-.\" "
-.\" " When distributing Covered Code, include this CDDL HEADER in each
-.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" " If applicable, add the following below this CDDL HEADER, with the
-.\" " fields enclosed by brackets "[]" replaced with your own identifying
-.\" " information: Portions Copyright [yyyy] [name of copyright owner]
-.\" "
-.\" " CDDL HEADER END
-.\" "
-.\" "Copyright 2002 Sun Microsystems, Inc.  All rights reserved.
-.\" "Use is subject to license terms."
-.TH flg.flp 1 "18 Oct 2002"
-.I flg.flp
-\- list the files that bringover would bring over due to inc.flg and
-req.flg files
-.SH SYNOPSIS
-\fBflg.flp [-r] [<dir>]
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "flg.flp" "" "\fBflg.flp\fP"
-.LP
-.I flg.flp
-uses the inc.flg and req.flg files contained within a workspace to
-determine what additional files would be brought over if one were to
-perform a bringover(1) of the specified directory. The resulting list of
-files, specified relative to \fICODEMGR_WS\fP, is sent to standard output.
-.LP
-At most one directory may be specified; if none is specified, the current
-working directory is assumed.  A relative directory is assumed to be
-relative to the current directory or relative to \fICODEMGR_WS\fP, in that
-order.  
-.SH OPTIONS
-.TP 10
-.B -r	
-Output the list of files relative to the current working directory, rather
-than \fICODEMGR_WS\fP.
-.SH SEE ALSO
-.LP
-.IR bringover(1)
-.LP
-The inc.flg and req.flg files are poorly documented, but outlined in
-/shared/ON/tools/teamware/OSNet/doc/osnet-sde.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/flg.flp.1onbld	Wed Sep 30 19:35:39 2015
@@ -0,0 +1,53 @@
+.\" " CDDL HEADER START
+.\" "
+.\" " The contents of this file are subject to the terms of the
+.\" " Common Development and Distribution License, Version 1.0 only
+.\" " (the "License").  You may not use this file except in compliance
+.\" " with the License.
+.\" "
+.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" " or http://www.opensolaris.org/os/licensing.
+.\" " See the License for the specific language governing permissions
+.\" " and limitations under the License.
+.\" "
+.\" " When distributing Covered Code, include this CDDL HEADER in each
+.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" " If applicable, add the following below this CDDL HEADER, with the
+.\" " fields enclosed by brackets "[]" replaced with your own identifying
+.\" " information: Portions Copyright [yyyy] [name of copyright owner]
+.\" "
+.\" " CDDL HEADER END
+.\" "
+.\" "Copyright 2002 Sun Microsystems, Inc.  All rights reserved.
+.\" "Use is subject to license terms."
+.TH flg.flp 1ONBLD "18 Oct 2002"
+.I flg.flp
+\- list the files that bringover would bring over due to inc.flg and
+req.flg files
+.SH SYNOPSIS
+\fBflg.flp [-r] [<dir>]
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "flg.flp" "" "\fBflg.flp\fP"
+.LP
+.I flg.flp
+uses the inc.flg and req.flg files contained within a workspace to
+determine what additional files would be brought over if one were to
+perform a bringover(1ONBLD) of the specified directory. The resulting list of
+files, specified relative to \fICODEMGR_WS\fP, is sent to standard output.
+.LP
+At most one directory may be specified; if none is specified, the current
+working directory is assumed.  A relative directory is assumed to be
+relative to the current directory or relative to \fICODEMGR_WS\fP, in that
+order.  
+.SH OPTIONS
+.TP 10
+.B -r	
+Output the list of files relative to the current working directory, rather
+than \fICODEMGR_WS\fP.
+.SH SEE ALSO
+.LP
+.IR bringover(1ONBLD)
+.LP
+The inc.flg and req.flg files are poorly documented, but outlined in
+/shared/ON/tools/teamware/OSNet/doc/osnet-sde.
--- old/usr/src/tools/scripts/git-pbchk.1	Wed Sep 30 19:35:39 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,96 +0,0 @@
-'\" t
-.\"
-.\" This file and its contents are supplied under the terms of the
-.\" Common Development and Distribution License ("CDDL"), version 1.0.
-.\" You may only use this file in accordance with the terms of version
-.\" 1.0 of the CDDL.
-.\"
-.\" A full copy of the text of the CDDL should have accompanied this
-.\" source.  A copy of the CDDL is also available via the Internet at
-.\" http://www.illumos.org/license/CDDL.
-.\"
-.\"
-.\" Copyright 2011 Richard Lowe.
-.\" Copyright 2015 Elysium Digital, L.L.C.
-.\"
-
-.TH "GIT\-PBCHK" "1" "April 23, 2015" "" ""
-
-.SH "NAME"
-\fBgit\-pbchk\fR \- nits and pre\-putback checks for git
-
-.SH "SYNOPSIS"
-git\-pbchk [\-b \fIbranch\fR]
-
-.P
-git\-nits [\-b \fIbranch\fR]
-
-.SH "DESCRIPTION"
-Check your workspace for common nits and putback\-ending mistakes, a simple set of checks are run over various parts of your workspace and errors encountered are reported, all of which should, generally, be fixed\.
-
-.TP
-Comment format
-Check that putback comments follow the prescribed format (only run for pbchk)
-
-.TP
-Copyrights
-Check that each source file contains a copyright notice for the current
-year\. You don't need to fix this if you, the potential new copyright holder, chooses not to
-
-.TP
-C style
-Check that C source files conform to the Illumos C style rules
-
-.TP
-Header check
-Check that C header files conform to the Illumos header style rules (in addition to the general C rules)
-
-.TP
-Java style
-Check that Java source files conform to the Illumos Java style rules (which differ from the traditionally recommended Java style)
-
-.TP
-SCCS Keywords
-Check that no source files contain unexpanded SCCS keywords\. It is possible that this check may false positive on certain inputs\. It is generally obvious when this is the case\.
-
-.IP
-This check does not check for expanded SCCS keywords, though the common \'ident\'\-style lines should be removed regardless of whether they are expanded\.
-
-.TP
-Mapfile check
-Check that linker mapfiles contain a comment directing anyone editing to read the directions in \fBusr/lib/README\.mapfiles\fR\.
-
-.SH "OPTIONS"
-
-.TP
-\fB\-b branch\fR:
-
-.IP
-Compare the current workspace to /branch/ for the purposes of generating file and comment lists\.
-
-.IP
-If this option is not specified an attempt is made to determine this automatically, if the git branch configuration contains this information\.
-
-.IP
-If no branch is specified and none can be determined automatically \fBorigin/master\fR is used\.
-
-.SH "FILES"
-\fBgit nits\fR and \fBgit pbchk\fR support NOT files of the form used by Cadmium with Mercurial\. These are looked for in \fB$CODEMGR_WS/\.git/\fR and in \fB$CODEMGR_WS/exception_lists/\fR as normal\. The files are named after the check from which they exclude files\.
-
-.IP "\(bu" 4
-\fBcopyright\.NOT\fR: exclude files listed from copyright checking
-
-.IP "\(bu" 4
-\fBcstyle\.NOT\fR: exclude files from the C style check
-
-.IP "\(bu" 4
-\fBhdrchk\.NOT\fR: exclude files from the C header style check
-
-.IP "\(bu" 4
-\fBkeywords\.NOT\fR: exclude files from the SCCS keywords check
-
-.IP "\(bu" 4
-\fBmapfilechk\.NOT\fR: exclude files from the linker mapfile check
-
-.IP "" 0
-
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/git-pbchk.1onbld	Wed Sep 30 19:35:39 2015
@@ -0,0 +1,96 @@
+'\" t
+.\"
+.\" This file and its contents are supplied under the terms of the
+.\" Common Development and Distribution License ("CDDL"), version 1.0.
+.\" You may only use this file in accordance with the terms of version
+.\" 1.0 of the CDDL.
+.\"
+.\" A full copy of the text of the CDDL should have accompanied this
+.\" source.  A copy of the CDDL is also available via the Internet at
+.\" http://www.illumos.org/license/CDDL.
+.\"
+.\"
+.\" Copyright 2011 Richard Lowe.
+.\" Copyright 2015 Elysium Digital, L.L.C.
+.\"
+
+.TH "GIT\-PBCHK" "1ONBLD" "April 23, 2015" "" ""
+
+.SH "NAME"
+\fBgit\-pbchk\fR \- nits and pre\-putback checks for git
+
+.SH "SYNOPSIS"
+git\-pbchk [\-b \fIbranch\fR]
+
+.P
+git\-nits [\-b \fIbranch\fR]
+
+.SH "DESCRIPTION"
+Check your workspace for common nits and putback\-ending mistakes, a simple set of checks are run over various parts of your workspace and errors encountered are reported, all of which should, generally, be fixed\.
+
+.TP
+Comment format
+Check that putback comments follow the prescribed format (only run for pbchk)
+
+.TP
+Copyrights
+Check that each source file contains a copyright notice for the current
+year\. You don't need to fix this if you, the potential new copyright holder, chooses not to
+
+.TP
+C style
+Check that C source files conform to the Illumos C style rules
+
+.TP
+Header check
+Check that C header files conform to the Illumos header style rules (in addition to the general C rules)
+
+.TP
+Java style
+Check that Java source files conform to the Illumos Java style rules (which differ from the traditionally recommended Java style)
+
+.TP
+SCCS Keywords
+Check that no source files contain unexpanded SCCS keywords\. It is possible that this check may false positive on certain inputs\. It is generally obvious when this is the case\.
+
+.IP
+This check does not check for expanded SCCS keywords, though the common \'ident\'\-style lines should be removed regardless of whether they are expanded\.
+
+.TP
+Mapfile check
+Check that linker mapfiles contain a comment directing anyone editing to read the directions in \fBusr/lib/README\.mapfiles\fR\.
+
+.SH "OPTIONS"
+
+.TP
+\fB\-b branch\fR:
+
+.IP
+Compare the current workspace to /branch/ for the purposes of generating file and comment lists\.
+
+.IP
+If this option is not specified an attempt is made to determine this automatically, if the git branch configuration contains this information\.
+
+.IP
+If no branch is specified and none can be determined automatically \fBorigin/master\fR is used\.
+
+.SH "FILES"
+\fBgit nits\fR and \fBgit pbchk\fR support NOT files of the form used by Cadmium with Mercurial\. These are looked for in \fB$CODEMGR_WS/\.git/\fR and in \fB$CODEMGR_WS/exception_lists/\fR as normal\. The files are named after the check from which they exclude files\.
+
+.IP "\(bu" 4
+\fBcopyright\.NOT\fR: exclude files listed from copyright checking
+
+.IP "\(bu" 4
+\fBcstyle\.NOT\fR: exclude files from the C style check
+
+.IP "\(bu" 4
+\fBhdrchk\.NOT\fR: exclude files from the C header style check
+
+.IP "\(bu" 4
+\fBkeywords\.NOT\fR: exclude files from the SCCS keywords check
+
+.IP "\(bu" 4
+\fBmapfilechk\.NOT\fR: exclude files from the linker mapfile check
+
+.IP "" 0
+
--- old/usr/src/tools/scripts/hdrchk.1	Wed Sep 30 19:35:39 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,100 +0,0 @@
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.\" ident	"%Z%%M%	%I%	%E% SMI"
-.\"
-.TH hdrchk 1 "02 July 2008"
-.SH NAME
-hdrchk \- check that header files conform to ON standards
-.SH SYNOPSIS
-.nf
-\fBhdrchk\fR [\fB-a\fP] \fIfile\fR [\fIfile ...\fR]\fP
-.fi
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "hdrchk" "" "\fBhdrchk\fP"
-.LP
-.I hdrchk
-verifies that C header files (*.h) conform to the standards of the ON
-consolidation.
-See HEADER STANDARDS for details.
-.LP
-.SH OPTIONS
-.LP
-.TP 10
-.B -a
-Apply (more lenient) application header rules.
-.LP
-.SH HEADER STANDARDS
-.LP
-Standards for all header files:
-.TP 4
-.B 1.
-Begin with a comment containing a copyright message.
-.LP
-.TP 4
-.B 2.
-Enclosed in a guard of the form:
-.LP
-.nf
-	#ifndef GUARD
-	#define GUARD
-	#endif /* [!]GUARD */
-.fi
-.sp
-.RS 4n
-The preferred form is without the bang character, but either is
-acceptable.
-.RE
-.LP
-.TP 4
-.B 3.
-Has a valid ident declaration.
-.LP
-Additional standards for system header files:
-.TP 4
-.B 1.
-The file guard must take the form '_\fBFILENAME\fP_H[_]', where
-\fBFILENAME\fP matches the basename of the file.
-If it is installed in a subdirectory, it should be of the
-form '_\fBDIR\fP_\fBFILENAME\fP_H[_]', though this is not currently enforced.
-The form without the trailing underscore is preferred in both cases.
-.LP
-.TP 4
-.B 2.
-All #include directives must use the <> form.
-.LP
-.TP 4
-.B 3.
-If the header file contains anything besides comments and preprocessor
-directives, then it must be enclosed in a C++ guard of the form:
-.LP
-.nf
-	#ifdef __cplusplus
-	extern "C" {
-	#endif
-
-	#ifdef __cplusplus
-	}
-	#endif
-.fi
-
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/hdrchk.1onbld	Wed Sep 30 19:35:39 2015
@@ -0,0 +1,98 @@
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.TH hdrchk 1ONBLD "02 July 2008"
+.SH NAME
+hdrchk \- check that header files conform to ON standards
+.SH SYNOPSIS
+.nf
+\fBhdrchk\fR [\fB-a\fP] \fIfile\fR [\fIfile ...\fR]\fP
+.fi
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "hdrchk" "" "\fBhdrchk\fP"
+.LP
+.I hdrchk
+verifies that C header files (*.h) conform to the standards of the ON
+consolidation.
+See HEADER STANDARDS for details.
+.LP
+.SH OPTIONS
+.LP
+.TP 10
+.B -a
+Apply (more lenient) application header rules.
+.LP
+.SH HEADER STANDARDS
+.LP
+Standards for all header files:
+.TP 4
+.B 1.
+Begin with a comment containing a copyright message.
+.LP
+.TP 4
+.B 2.
+Enclosed in a guard of the form:
+.LP
+.nf
+	#ifndef GUARD
+	#define GUARD
+	#endif /* [!]GUARD */
+.fi
+.sp
+.RS 4n
+The preferred form is without the bang character, but either is
+acceptable.
+.RE
+.LP
+.TP 4
+.B 3.
+Has a valid ident declaration.
+.LP
+Additional standards for system header files:
+.TP 4
+.B 1.
+The file guard must take the form '_\fBFILENAME\fP_H[_]', where
+\fBFILENAME\fP matches the basename of the file.
+If it is installed in a subdirectory, it should be of the
+form '_\fBDIR\fP_\fBFILENAME\fP_H[_]', though this is not currently enforced.
+The form without the trailing underscore is preferred in both cases.
+.LP
+.TP 4
+.B 2.
+All #include directives must use the <> form.
+.LP
+.TP 4
+.B 3.
+If the header file contains anything besides comments and preprocessor
+directives, then it must be enclosed in a C++ guard of the form:
+.LP
+.nf
+	#ifdef __cplusplus
+	extern "C" {
+	#endif
+
+	#ifdef __cplusplus
+	}
+	#endif
+.fi
+
--- old/usr/src/tools/scripts/hgsetup.1	Wed Sep 30 19:35:40 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,73 +0,0 @@
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms."
-.\"
-.TH hgsetup 1 "2 October 2008"
-.SH NAME
-.I hgsetup
-\- sets up a user's ~/.hgrc for development of ON with Mercurial
-.SH SYNOPSIS
-\fBhgsetup [-f] [-c \fIcdm_path\fP] [-m \fImerge_path\fP] [-n \fIname\fP] [-e \fIemail\fP] [-p \fIproxy\fP] [-s \fIstyle_path\fP]
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "hgsetup" "" "\fBhgsetup\fP"
-.LP
-The hgsetup script sets up a user's ~/.hgrc (hgrc(5)) file for development
-of ON (OS/Net) with Mercurial.  
-.LP
-It populates the author and email fields with the user's information.
-It loads the Cadmium extension.
-It aliases canonical repositories for onnv-gate.
-It configures Mercurial to use appropriate merge tools.
-.SH OPTIONS
-.TP 10
-.B -f
-Force the user's ~/.hgrc to be overwritten if one already exists
-.TP 10
-.B -c
-Override the path to the Cadmium extension for Mercurial to load
-.TP 10
-.B -m
-Override the default merge configuration, such that a single
-specified tool is used.
-.TP 10
-.B -n
-Specify the name to use for commits (default is taken from passwd file)
-.TP 10
-.B -e
-Specify the email address to use for commits.
-For SWAN users the default is taken from an LDAP query, otherwise -e 
-is mandatory.
-.TP 10
-.B -p
-Specify an http_proxy to use for interacting with HTTP repositories
-.TP 10
-.B -s
-Override the path to the Mercurial style file
-.LP
-.SH OUTPUT
-.LP
-Generates a .hgrc file in the user's home directory.
-.LP
-.SH SEE ALSO
-.LP
-.IR hgrc(5),
-.IR hg(1),
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/hgsetup.1onbld	Wed Sep 30 19:35:40 2015
@@ -0,0 +1,73 @@
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms."
+.\"
+.TH hgsetup 1ONBLD "2 October 2008"
+.SH NAME
+.I hgsetup
+\- sets up a user's ~/.hgrc for development of ON with Mercurial
+.SH SYNOPSIS
+\fBhgsetup [-f] [-c \fIcdm_path\fP] [-m \fImerge_path\fP] [-n \fIname\fP] [-e \fIemail\fP] [-p \fIproxy\fP] [-s \fIstyle_path\fP]
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "hgsetup" "" "\fBhgsetup\fP"
+.LP
+The hgsetup script sets up a user's ~/.hgrc (hgrc(5)) file for development
+of ON (OS/Net) with Mercurial.  
+.LP
+It populates the author and email fields with the user's information.
+It loads the Cadmium extension.
+It aliases canonical repositories for onnv-gate.
+It configures Mercurial to use appropriate merge tools.
+.SH OPTIONS
+.TP 10
+.B -f
+Force the user's ~/.hgrc to be overwritten if one already exists
+.TP 10
+.B -c
+Override the path to the Cadmium extension for Mercurial to load
+.TP 10
+.B -m
+Override the default merge configuration, such that a single
+specified tool is used.
+.TP 10
+.B -n
+Specify the name to use for commits (default is taken from passwd file)
+.TP 10
+.B -e
+Specify the email address to use for commits.
+For SWAN users the default is taken from an LDAP query, otherwise -e 
+is mandatory.
+.TP 10
+.B -p
+Specify an http_proxy to use for interacting with HTTP repositories
+.TP 10
+.B -s
+Override the path to the Mercurial style file
+.LP
+.SH OUTPUT
+.LP
+Generates a .hgrc file in the user's home directory.
+.LP
+.SH SEE ALSO
+.LP
+.IR hgrc(5),
+.IR hg(1),
--- old/usr/src/tools/scripts/interface_check.1	Wed Sep 30 19:35:40 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,393 +0,0 @@
-.\" Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.TH interface_check 1 "25 March 2010"
-.SH NAME
-interface_check \- check shared object interfaces
-.SH SYNOPSIS
-\fBinterface_check [-hIo] [-c vertype_module] [-E errfile] [-e exfile] [-f listfile] [-i intffile] [-w outdir] file | dir, ...\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "interface_check" "" "\fBinterface_check\fP"
-The
-.I interface_check
-command attempts to check a number of ELF versioning attributes
-for consistency with common build rules and practices.
-In addition, a complete breakdown of the file's version definitions can
-be captured using the
-.B -i
-option, and the interface description file created can be used with
-.I interface_cmp
-to audit
-the versioning evolution of a software product.
-These interface description files reflect the association of the shared
-object's global symbols with recorded version definitions.
-.LP
-.I interface_check
-is typically called from \fBnightly(1)\fP when the \fB-A\fP
-option is in effect. In this case the shared objects under
-the associated \fIproto\fP area (\fB$ROOT\fP) are examined.
-.I interface_check
-can also be run standalone against any set of dynamic objects.
-.LP
-.I interface_check
-uses \fBelfdump(1)\fP and \fBpvs(1)\fP to
-check file naming standardization, and versioning consistency. These 
-check are carried out for the following reasons:
-.TP 4
-\(bu
-A shared object should exist with a versioned filename.
-A versioned filename commonly takes the form of a \fI.so\fP suffix
-followed by a version number. For example, \fI/usr/lib/libc.so.1\fP
-is the shared object representation of version one of the standard C
-library made available to the runtime environment.
-A versioned filename allows for a change in the exported interface of
-the shared object over a series of software releases.  A shared object
-that doesn't exist as a versioned filename is displayed as:
-.sp
-.RS 6
-foo.so: does not have a versioned name
-.RE
-.TP
-\(bu
-Versions should be defined within a shared object both to clarify its
-public or private use, and to explicitly define the interfaces that it
-makes available.  The reduction in object size, and relocation cost
-created by reducing non-interface symbols to locals is an added bonus.
-A non-versioned shared object is displayed as:
-.sp
-.RS 6
-foo.so.1: no versions found
-.RE
-.TP
-\(bu
-Version definitions should follow a standard naming convention, i.e.,
-\fBSUNW_\fIx.y\fP\fP, \fBSUNWprivate_\fIx.y\fP\fP, or \fIfilename\fP.  The
-latter version is a base version and is used to capture any reserved
-interface symbols (i.e., \fI_end\fP, \fI_etext\fP, etc.).  Any non-conforming
-version names are displayed as:
-.sp
-.RS 6
-foo.so.1: non-standard version name: \fIversion-name\fP
-.RE
-.sp
-.RS 4
-Note, that non-conforming base version names are often generated when
-the file itself has an internal identification that differs from the
-actual filename (see \fBld(1)\fP \fI-h\fP).
-.RE
-.TP
-\(bu
-A scoped object, one that has defined its external interfaces
-and whose internal interfaces have been reduced to locals,
-but has no version definitions assigned, does not inform users
-of the commitment level of the interfaces it offers. Scoped
-objects are displayed as:
-.sp
-.RS 6
-foo.so.1: scoped object contains no versions
-.LP
-When used with the \fI-i\fP option
-.I interface_check
-produces a more detailed breakdown of a shared objects versioning.
-This interface description file provides for the release-to-release 
-auditing of interfaces,
-and monitoring the evolution of the share objects interfaces.
-.LP
-These files provide a complete cross reference of version to interface
-relationships and are the basis for
-auditing a shared objects interfaces from release-to-release.  Any
-addition, deletion or regrouping of versioning information can be
-detected by inspecting this database with
-.I interface_cmp.
-.sp
-.LP
-.SH OPTIONS
-.LP
-The following options are supported:
-.TP 4
-.B \-c vertype_module
-By default,
-.I interface_check
-is customized for the versioning conventions used by the Solaris
-OSnet code base. This specialized information, which includes
-the recognition of the SUNW_ prefix and other special names, is
-contained in a perl module named onbld_elfmod_vertype.pm, which
-is delivered with the SUNWonbld tools. This module is loaded by
-.I interface_check
-at runtime. The \fB-c\fP option can be used to supply
-an alternative module, customized for a different code base, allowing
-.I interface_check
-to operate on code from other projects. The alternative module must
-supply the same module and calling interfaces as the standard module.
-.TP 4
-.B \-E errfile
-Direct error messages for the analyzed objects to \fIerrfile\fP instead 
-of stdout.
-.TP 4
-.B \-e exfile
-An exception file is used to exclude objects from
-the usual rules. See EXCEPTION FILE FORMAT.
-.TP 4
-.B \-f listfile
-Normally,
-.I interface_check
-runs
-.I find_elf
-to locate the ELF objects to analyze. The \fB-f\fP option can be
-used to instead provide a file containing the list of objects to
-analyze, in the format produced by '\fBfind_elf -r\fP'.
-.TP 4
-.B \-h
-Prevent the generation of the CDDL license and Sun copyright header 
-normally produced at the start of output.
-.TP 4
-.B \-I
-When used with the \fB-i\fP option, the interface definition produced shows
-expanded symbol inheritance. Each version lists the symbols inherited
-from sub-versions. This mode is primarily of interest for debugging,
-as it matches the format produced by the \fB-t\fP option to
-.I interface_cmp. See INTERFACE DESCRIPTION FILE FORMAT.
-.TP 4
-.B \-i intffile
-Produce an output file containing a complete interface definition for
-the objects analyzed. This file can be used with
-.I interface_cmp
-to audit versioning between gates, or prior to integration within
-a single gate. See INTERFACE DESCRIPTION FILE FORMAT.
-.TP 4
-.B \-o
-Produce one-liner output, with each line of diagnostic output 
-prefixed with the object pathname.
-.TP
-.B -w outdir
-Interpret the paths of all input and output files relative to \fIoutdir\fP.
-.LP
-.SH EXCEPTION FILE FORMAT
-Exceptions to the rules enforced by
-.I interface_check
-are be specified using an exception file. The \fB-e\fP option is used to
-specify an explicit exception file. Otherwise, if used in an activated
-workspace, the default exception file is
-$CODEMGR_WS/exception_list/interface_check
-if that file exists. If not used in an activated workspace, or if
-$CODEMGR_WS/exception_list/interface_check does not exist,
-.I interface_check
-will use
-.I /opt/onbld/etc/exception_list/interface_check
-as a fallback default exception file.
-.p
-To run
-.I interface_check
-without applying exceptions, specify \fB-e\fP with a value of /dev/null.
-.P
-A '#' character at the beginning of a line, or at any point in
-a line when preceded by whitespace, introduces a comment. Empty lines, 
-and lines containing only comments, are ignored by
-.I interface_check.
-Exceptions are specified as space separated keyword, and \fBperl(1)\fP
-regular expression:
-.sp
-.in +4
-.nf
-keyword  perl-regex
-.fi
-.in -4
-.sp
-Since whitespace is used as a separator, the regular
-expression cannot itself contain whitespace. Use of the \\s character
-class to represent whitespace within the regular expression is recommended.
-Before the perl regular expression is used, constructs of the form
-MACH(dir) are expanded into a regular expression that matches the directory
-given, as well as any 64-bit architecture subdirectory that
-might be present (i.e. amd64, sparcv9). For instance, MACH(lib) will
-match any of the following:
-.sp
-.in +4
-.nf
-lib
-lib/amd64
-lib/sparcv9
-.fi
-.in -4
-.sp
-The exceptions understood by
-.I interface_check
-are:
-.sp
-.ne 2
-.mk
-.na
-\fBNONSTD_VERNAME\fR
-.ad
-.RS 17n
-.rt
-.sp
-Objects that are allowed to deviate from our standard version names.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBNOVERDEF\fR
-.ad
-.RS 17n
-.rt
-Objects that are not expected to contain versioning information.
-Note that PLUGIN objects are automatically exempt from this,
-so these directives are generally applied to non-plugin objects
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBPLUGIN\fR
-.ad
-.RS 17n
-.rt
-Sharable objects underneath these parts of the tree are taken to be plugins.
-Plugins are not required to have versioned file names, and are not required
-to be internally versioned.
-.RE
-.LP
-.SH INTERFACE DESCRIPTION FILE FORMAT
-When the \fB-i\fP option is used
-.I interface_check
-produces an \fIInterface Description File\fP that captures a description of
-the interfaces provided by each ELF object processed. 
-.P
-Unless the \fB-h\fP option is used,
-.I interface_check
-produces a header comment at the start of this file, containing a CDDL
-block and a Sun copyright notice. The header uses '#' as a comment character
-for the lines containing text, and also includes empty lines.
-.P
-Following the header comment,
-.I interface_check
-produces a description of the interfaces provided by each object. The
-description of each object starts with an OBJECT directive, and follows the
-form shown below, using /lib/amd64/libadm.so.1 as an example:
-.sp
-.in +4
-.nf
-.CR
-OBJECT	lib/amd64/libadm.so.1
-CLASS	ELFCLASS64
-TYPE	ET_DYN
-ALIAS	lib/64/libadm.so
-ALIAS	lib/64/libadm.so.1
-ALIAS	lib/amd64/libadm.so
-ALIAS	usr/lib/64/libadm.so
-ALIAS	usr/lib/64/libadm.so.1
-ALIAS	usr/lib/amd64/libadm.so
-ALIAS	usr/lib/amd64/libadm.so.1
-TOP_VERSION	SUNW_1.2	{SUNW_1.1}
-	SYMBOL	read_extvtoc
-	SYMBOL	write_extvtoc
-VERSION	SUNW_1.1	{SUNW_0.7}
-VERSION	SUNW_0.7
-	SYMBOL	pkgdir
-	SYMBOL	read_vtoc
-	SYMBOL	write_vtoc
-.fi
-.in -4
-.sp
-The description for every object starts with OBJECT, CLASS, and TYPE
-directives. Following that come ALIAS lines for every alternative name
-by which this object is known. Every version exported by the object
-is designated by a VERSION or TOP_VERSION directive. A TOP_VERSION is
-a version at the top of the version inheritance chain, and VERSION
-is used for versions lower in the chain. Inherited versions are shown
-within {} brackets following the version name. Following each version directive
-are SYMBOL directives, each describing a symbol defined by
-that version.
-.P
-When the \fB-I\fP option is used, version inheritance is expanded,
-such that each version includes the symbols inherited from sub-versions.
-In this mode, the SYMBOL directive is replaced with NEW for symbols
-defined in the version, and INHERIT for those that are inherited. Using
-\fB-I\fP for the above example produces the following output:
-.sp
-.in +4
-.nf
-.CR
-OBJECT  lib/amd64/libadm.so.1
-CLASS   ELFCLASS64
-TYPE    ET_DYN
-ALIAS   lib/64/libadm.so
-ALIAS   lib/64/libadm.so.1
-ALIAS   lib/amd64/libadm.so
-ALIAS   usr/lib/64/libadm.so
-ALIAS   usr/lib/64/libadm.so.1
-ALIAS   usr/lib/amd64/libadm.so
-ALIAS   usr/lib/amd64/libadm.so.1
-TOP_VERSION     SUNW_1.2        {SUNW_1.1}
-        INHERIT pkgdir
-        NEW     read_extvtoc
-        INHERIT read_vtoc
-        NEW     write_extvtoc
-        INHERIT write_vtoc
-VERSION SUNW_1.1        {SUNW_0.7}
-        INHERIT pkgdir
-        INHERIT read_vtoc
-        INHERIT write_vtoc
-VERSION SUNW_0.7
-        NEW     pkgdir
-        NEW     read_vtoc
-        NEW     write_vtoc
-.fi
-.in -4
-.sp
-The \fB-I\fP option is primary used for debugging
-.I interface_check
-and
-.I interface_cmp.
-.LP
-.SH EXAMPLES
-The following example uses
-.I interface_check
-to generate an interface database for a workspace:
-.PP
-.RS
-.nf
-% mkdir $SRC/ELF-data.$MACH
-% interface_check -w $SRC/ELF-data.$MACH -E interface.err \ 
-        -i interface $ROOT
-% ls -1R $SRC/ELF
-interface
-interface.err
-.br
-.SH FILES
-.LP
-.RS 5
-$CODEMGR_WS/exception_list/interface_check
-/opt/onbld/etc/exception_list/interface_check
-.SH SEE ALSO
-.BR find_elf(1),
-.BR interface_cmp(1),
-.BR ld(1),
-.BR ldd(1),
-.BR elfdump(1),
-.BR pvs(1).
-.LP
-.TZ LLM
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/interface_check.1onbld	Wed Sep 30 19:35:40 2015
@@ -0,0 +1,393 @@
+.\" Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.TH interface_check 1ONBLD "25 March 2010"
+.SH NAME
+interface_check \- check shared object interfaces
+.SH SYNOPSIS
+\fBinterface_check [-hIo] [-c vertype_module] [-E errfile] [-e exfile] [-f listfile] [-i intffile] [-w outdir] file | dir, ...\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "interface_check" "" "\fBinterface_check\fP"
+The
+.I interface_check
+command attempts to check a number of ELF versioning attributes
+for consistency with common build rules and practices.
+In addition, a complete breakdown of the file's version definitions can
+be captured using the
+.B -i
+option, and the interface description file created can be used with
+.I interface_cmp
+to audit
+the versioning evolution of a software product.
+These interface description files reflect the association of the shared
+object's global symbols with recorded version definitions.
+.LP
+.I interface_check
+is typically called from \fBnightly(1ONBLD)\fP when the \fB-A\fP
+option is in effect. In this case the shared objects under
+the associated \fIproto\fP area (\fB$ROOT\fP) are examined.
+.I interface_check
+can also be run standalone against any set of dynamic objects.
+.LP
+.I interface_check
+uses \fBelfdump(1)\fP and \fBpvs(1)\fP to
+check file naming standardization, and versioning consistency. These 
+check are carried out for the following reasons:
+.TP 4
+\(bu
+A shared object should exist with a versioned filename.
+A versioned filename commonly takes the form of a \fI.so\fP suffix
+followed by a version number. For example, \fI/usr/lib/libc.so.1\fP
+is the shared object representation of version one of the standard C
+library made available to the runtime environment.
+A versioned filename allows for a change in the exported interface of
+the shared object over a series of software releases.  A shared object
+that doesn't exist as a versioned filename is displayed as:
+.sp
+.RS 6
+foo.so: does not have a versioned name
+.RE
+.TP
+\(bu
+Versions should be defined within a shared object both to clarify its
+public or private use, and to explicitly define the interfaces that it
+makes available.  The reduction in object size, and relocation cost
+created by reducing non-interface symbols to locals is an added bonus.
+A non-versioned shared object is displayed as:
+.sp
+.RS 6
+foo.so.1: no versions found
+.RE
+.TP
+\(bu
+Version definitions should follow a standard naming convention, i.e.,
+\fBSUNW_\fIx.y\fP\fP, \fBSUNWprivate_\fIx.y\fP\fP, or \fIfilename\fP.  The
+latter version is a base version and is used to capture any reserved
+interface symbols (i.e., \fI_end\fP, \fI_etext\fP, etc.).  Any non-conforming
+version names are displayed as:
+.sp
+.RS 6
+foo.so.1: non-standard version name: \fIversion-name\fP
+.RE
+.sp
+.RS 4
+Note, that non-conforming base version names are often generated when
+the file itself has an internal identification that differs from the
+actual filename (see \fBld(1)\fP \fI-h\fP).
+.RE
+.TP
+\(bu
+A scoped object, one that has defined its external interfaces
+and whose internal interfaces have been reduced to locals,
+but has no version definitions assigned, does not inform users
+of the commitment level of the interfaces it offers. Scoped
+objects are displayed as:
+.sp
+.RS 6
+foo.so.1: scoped object contains no versions
+.LP
+When used with the \fI-i\fP option
+.I interface_check
+produces a more detailed breakdown of a shared objects versioning.
+This interface description file provides for the release-to-release 
+auditing of interfaces,
+and monitoring the evolution of the share objects interfaces.
+.LP
+These files provide a complete cross reference of version to interface
+relationships and are the basis for
+auditing a shared objects interfaces from release-to-release.  Any
+addition, deletion or regrouping of versioning information can be
+detected by inspecting this database with
+.I interface_cmp.
+.sp
+.LP
+.SH OPTIONS
+.LP
+The following options are supported:
+.TP 4
+.B \-c vertype_module
+By default,
+.I interface_check
+is customized for the versioning conventions used by the Solaris
+OSnet code base. This specialized information, which includes
+the recognition of the SUNW_ prefix and other special names, is
+contained in a perl module named onbld_elfmod_vertype.pm, which
+is delivered with the SUNWonbld tools. This module is loaded by
+.I interface_check
+at runtime. The \fB-c\fP option can be used to supply
+an alternative module, customized for a different code base, allowing
+.I interface_check
+to operate on code from other projects. The alternative module must
+supply the same module and calling interfaces as the standard module.
+.TP 4
+.B \-E errfile
+Direct error messages for the analyzed objects to \fIerrfile\fP instead 
+of stdout.
+.TP 4
+.B \-e exfile
+An exception file is used to exclude objects from
+the usual rules. See EXCEPTION FILE FORMAT.
+.TP 4
+.B \-f listfile
+Normally,
+.I interface_check
+runs
+.I find_elf
+to locate the ELF objects to analyze. The \fB-f\fP option can be
+used to instead provide a file containing the list of objects to
+analyze, in the format produced by '\fBfind_elf -r\fP'.
+.TP 4
+.B \-h
+Prevent the generation of the CDDL license and Sun copyright header 
+normally produced at the start of output.
+.TP 4
+.B \-I
+When used with the \fB-i\fP option, the interface definition produced shows
+expanded symbol inheritance. Each version lists the symbols inherited
+from sub-versions. This mode is primarily of interest for debugging,
+as it matches the format produced by the \fB-t\fP option to
+.I interface_cmp. See INTERFACE DESCRIPTION FILE FORMAT.
+.TP 4
+.B \-i intffile
+Produce an output file containing a complete interface definition for
+the objects analyzed. This file can be used with
+.I interface_cmp
+to audit versioning between gates, or prior to integration within
+a single gate. See INTERFACE DESCRIPTION FILE FORMAT.
+.TP 4
+.B \-o
+Produce one-liner output, with each line of diagnostic output 
+prefixed with the object pathname.
+.TP
+.B -w outdir
+Interpret the paths of all input and output files relative to \fIoutdir\fP.
+.LP
+.SH EXCEPTION FILE FORMAT
+Exceptions to the rules enforced by
+.I interface_check
+are be specified using an exception file. The \fB-e\fP option is used to
+specify an explicit exception file. Otherwise, if used in an activated
+workspace, the default exception file is
+$CODEMGR_WS/exception_list/interface_check
+if that file exists. If not used in an activated workspace, or if
+$CODEMGR_WS/exception_list/interface_check does not exist,
+.I interface_check
+will use
+.I /opt/onbld/etc/exception_list/interface_check
+as a fallback default exception file.
+.p
+To run
+.I interface_check
+without applying exceptions, specify \fB-e\fP with a value of /dev/null.
+.P
+A '#' character at the beginning of a line, or at any point in
+a line when preceded by whitespace, introduces a comment. Empty lines, 
+and lines containing only comments, are ignored by
+.I interface_check.
+Exceptions are specified as space separated keyword, and \fBperl(1)\fP
+regular expression:
+.sp
+.in +4
+.nf
+keyword  perl-regex
+.fi
+.in -4
+.sp
+Since whitespace is used as a separator, the regular
+expression cannot itself contain whitespace. Use of the \\s character
+class to represent whitespace within the regular expression is recommended.
+Before the perl regular expression is used, constructs of the form
+MACH(dir) are expanded into a regular expression that matches the directory
+given, as well as any 64-bit architecture subdirectory that
+might be present (i.e. amd64, sparcv9). For instance, MACH(lib) will
+match any of the following:
+.sp
+.in +4
+.nf
+lib
+lib/amd64
+lib/sparcv9
+.fi
+.in -4
+.sp
+The exceptions understood by
+.I interface_check
+are:
+.sp
+.ne 2
+.mk
+.na
+\fBNONSTD_VERNAME\fR
+.ad
+.RS 17n
+.rt
+.sp
+Objects that are allowed to deviate from our standard version names.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBNOVERDEF\fR
+.ad
+.RS 17n
+.rt
+Objects that are not expected to contain versioning information.
+Note that PLUGIN objects are automatically exempt from this,
+so these directives are generally applied to non-plugin objects
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBPLUGIN\fR
+.ad
+.RS 17n
+.rt
+Sharable objects underneath these parts of the tree are taken to be plugins.
+Plugins are not required to have versioned file names, and are not required
+to be internally versioned.
+.RE
+.LP
+.SH INTERFACE DESCRIPTION FILE FORMAT
+When the \fB-i\fP option is used
+.I interface_check
+produces an \fIInterface Description File\fP that captures a description of
+the interfaces provided by each ELF object processed. 
+.P
+Unless the \fB-h\fP option is used,
+.I interface_check
+produces a header comment at the start of this file, containing a CDDL
+block and a Sun copyright notice. The header uses '#' as a comment character
+for the lines containing text, and also includes empty lines.
+.P
+Following the header comment,
+.I interface_check
+produces a description of the interfaces provided by each object. The
+description of each object starts with an OBJECT directive, and follows the
+form shown below, using /lib/amd64/libadm.so.1 as an example:
+.sp
+.in +4
+.nf
+.CR
+OBJECT	lib/amd64/libadm.so.1
+CLASS	ELFCLASS64
+TYPE	ET_DYN
+ALIAS	lib/64/libadm.so
+ALIAS	lib/64/libadm.so.1
+ALIAS	lib/amd64/libadm.so
+ALIAS	usr/lib/64/libadm.so
+ALIAS	usr/lib/64/libadm.so.1
+ALIAS	usr/lib/amd64/libadm.so
+ALIAS	usr/lib/amd64/libadm.so.1
+TOP_VERSION	SUNW_1.2	{SUNW_1.1}
+	SYMBOL	read_extvtoc
+	SYMBOL	write_extvtoc
+VERSION	SUNW_1.1	{SUNW_0.7}
+VERSION	SUNW_0.7
+	SYMBOL	pkgdir
+	SYMBOL	read_vtoc
+	SYMBOL	write_vtoc
+.fi
+.in -4
+.sp
+The description for every object starts with OBJECT, CLASS, and TYPE
+directives. Following that come ALIAS lines for every alternative name
+by which this object is known. Every version exported by the object
+is designated by a VERSION or TOP_VERSION directive. A TOP_VERSION is
+a version at the top of the version inheritance chain, and VERSION
+is used for versions lower in the chain. Inherited versions are shown
+within {} brackets following the version name. Following each version directive
+are SYMBOL directives, each describing a symbol defined by
+that version.
+.P
+When the \fB-I\fP option is used, version inheritance is expanded,
+such that each version includes the symbols inherited from sub-versions.
+In this mode, the SYMBOL directive is replaced with NEW for symbols
+defined in the version, and INHERIT for those that are inherited. Using
+\fB-I\fP for the above example produces the following output:
+.sp
+.in +4
+.nf
+.CR
+OBJECT  lib/amd64/libadm.so.1
+CLASS   ELFCLASS64
+TYPE    ET_DYN
+ALIAS   lib/64/libadm.so
+ALIAS   lib/64/libadm.so.1
+ALIAS   lib/amd64/libadm.so
+ALIAS   usr/lib/64/libadm.so
+ALIAS   usr/lib/64/libadm.so.1
+ALIAS   usr/lib/amd64/libadm.so
+ALIAS   usr/lib/amd64/libadm.so.1
+TOP_VERSION     SUNW_1.2        {SUNW_1.1}
+        INHERIT pkgdir
+        NEW     read_extvtoc
+        INHERIT read_vtoc
+        NEW     write_extvtoc
+        INHERIT write_vtoc
+VERSION SUNW_1.1        {SUNW_0.7}
+        INHERIT pkgdir
+        INHERIT read_vtoc
+        INHERIT write_vtoc
+VERSION SUNW_0.7
+        NEW     pkgdir
+        NEW     read_vtoc
+        NEW     write_vtoc
+.fi
+.in -4
+.sp
+The \fB-I\fP option is primary used for debugging
+.I interface_check
+and
+.I interface_cmp.
+.LP
+.SH EXAMPLES
+The following example uses
+.I interface_check
+to generate an interface database for a workspace:
+.PP
+.RS
+.nf
+% mkdir $SRC/ELF-data.$MACH
+% interface_check -w $SRC/ELF-data.$MACH -E interface.err \ 
+        -i interface $ROOT
+% ls -1R $SRC/ELF
+interface
+interface.err
+.br
+.SH FILES
+.LP
+.RS 5
+$CODEMGR_WS/exception_list/interface_check
+/opt/onbld/etc/exception_list/interface_check
+.SH SEE ALSO
+.BR find_elf(1ONBLD),
+.BR interface_cmp(1ONBLD),
+.BR ld(1),
+.BR ldd(1),
+.BR elfdump(1),
+.BR pvs(1).
+.LP
+.TZ LLM
--- old/usr/src/tools/scripts/interface_cmp.1	Wed Sep 30 19:35:40 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,245 +0,0 @@
-.\" Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.TH interface_cmp 1 "25 March 2010"
-.SH NAME
-interface_cmp \- compare shared object interface descriptions
-.SH SYNOPSIS
-\fBinterface_cmp [-dot] [-e exfile] old new\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "interface_cmp" "" "\fBinterface_cmp\fP"
-The
-.I interface_cmp
-command compares the interface definition files for two workspaces
-and reports versioning inconsistencies. Interface definition
-files are created by
-.IR interface_check.
-.PP
-.I interface_cmp
-is typically called from \fBnightly(1)\fP when the \fB-A\fP
-option is in effect following the creation of a new database by
-.IR interface_check .
-To insure symbolic
-interface consistency between successive software releases, existing
-version definitions and their symbol association should remain intact.
-Any discrepancies between the two interface definitions are flagged as
-errors.
-.PP
-Note that version definition inheritance has the effect of causing a
-symbol to be viewed as existing in multiple definitions. This insures
-that both version definitions and their inheritance relationship are
-processed as part of the comparison.
-.LP
-.SH OPTIONS
-.LP
-The following options are supported:
-.TP 4
-.B \-c vertype_module
-By default,
-.I interface_cmp
-is customized for the versioning conventions used by the Solaris
-OSnet code base. This specialized information, which includes
-the recognition of the SUNW_ prefix and other special names, is
-contained in a perl module named onbld_elfmod_vertype.pm, which
-is delivered with the SUNWonbld tools. This module is loaded by
-.I interface_cmp
-at runtime. The \fB-c\fP option can be used to supply
-an alternative module, customized for a different code base, allowing
-.I interface_cmp
-to operate on code from other projects. The alternative module must
-supply the same module and calling interfaces as the standard module.
-.TP 4
-.B \-d
-Asserts that the \fBnew\fP interface is a direct descendant of
-\fBold\fP. If so, the following additional checks are enabled:
-.RS +4
-.TP
-.ie t \(bu
-.el o
-The top version of an inheritance chain must not increase
-by more than one.
-.RE
-.RS +4
-.TP
-.ie t \(bu
-.el o
-The new interface must not add new empty versions. Pre-existing empty
-versions represent public interfaces that cannot be changed, but new
-ones should be removed before the product ships.
-.RE
-.sp
-.LP
-.TP 4
-.B \-e exfile
-An exception file is used to exclude objects from
-the usual rules. See EXCEPTION FILE FORMAT.
-.TP 4
-.B \-o
-Produce one-liner output, with each line of diagnostic output 
-prefixed with the object pathname.
-.TP 4
-.B \-t
-If the \fB-t\fP option is present, only one argument is allowed.
-The interface description file is parsed, and then regenerated on
-stdout in the same format used by the
-.I interface_check
-\fB-I\fP option. The \fB-I\fP output from
-.I interface_check
-and the output from
-.I interface_cmp
-\fB-t\fP
-should be identical, excluding header comments. 
-This is a debugging feature, and not intended for general use.
-.LP
-.SH EXCEPTION FILE FORMAT
-Exceptions to the rules enforced by
-.I interface_cmp
-are specified using an exception file. The \fB-e\fP option is used to
-specify an explicit exception file. Otherwise, if used in an activated
-workspace, the default exception file is
-$CODEMGR_WS/exception_list/interface_cmp
-if that file exists. If not used in an activated workspace, or if
-$CODEMGR_WS/exception_list/interface_cmp does not exist,
-.I interface_cmp
-will use
-.I /opt/onbld/etc/exception_list/interface_cmp
-as a fallback default exception file.
-.p
-To run
-.I interface_cmp
-without applying exceptions, specify \fB-e\fP with a value of /dev/null.
-.P
-A '#' character at the beginning of a line, or at any point in
-a line when preceded by whitespace, introduces a comment. Empty lines, 
-and lines containing only comments, are ignored by
-.I interface_cmp.
-Exceptions are specified as space separated keyword, and \fBperl(1)\fP
-regular expressions. The number of regular expressions depends on the
-particular exception in questions:
-.sp
-.in +4
-.nf
-keyword  perl-regex...
-.fi
-.in -4
-.sp
-Since whitespace is used as a separator, the regular
-expression cannot itself contain whitespace. Use of the \\s character
-class to represent whitespace within the regular expression is recommended.
-Before the perl regular expression is used, constructs of the form
-MACH(dir) are expanded into a regular expression that matches the directory
-given, as well as any 64-bit architecture subdirectory that
-might be present (i.e. amd64, sparcv9). For instance, MACH(lib) will
-match any of the following:
-.sp
-.in +4
-.nf
-lib
-lib/amd64
-lib/sparcv9
-.fi
-.in -4
-.sp
-The exceptions understood by
-.I interface_cmp
-are:
-.sp
-.ne 2
-.mk
-.na
-\fBADDSYM\fR sym_re version_re object_re
-.ad
-.RS 17n
-.rt
-.sp
-The interfaces in a given version are not supposed to change. 
-.I interface_cmp
-will normally issue an error if a new interface is added to a previously
-released version. ADDSYM is used to override this
-requirement. If the added symbol, version, and object match
-the regular expressions specified by ADDSYM, the added symbol is ignored.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBDELDYM\fR sym_re version_re object_re
-.ad
-.RS 17n
-.rt
-.sp
-Once released to the public, interfaces are required to remain available
-in subsequent releases. DELSYM is used to override this
-requirement, as can occur when interfaces are EOL'd. Such an action generally
-requires a PSARC case. If the deleted symbol, version, and object match
-the regular expressions specified by DELSYM, the deleted symbol is ignored.
-.RE
-
-.sp
-.ne 2
-.mk
-.na
-\fBEMPTY_TOPVERSION\fR version_re object_re
-.ad
-.RS 17n
-.rt
-.sp
-.I
-interface_cmp
-normally issues an error if the old object has an empty top version
-that is non-empty in the new object. Such a situation is normally
-an error, but may legitimately occur as part of a fix to another versioning
-error.  If the version, and object match
-the regular expressions specified by EMPTY_TOPVERSION, the error is suppressed.
-.RE
-
-.PP
-.SH EXAMPLES
-The following example uses
-.I interface_cmp
-to compare this releases interface definition with a previous
-builds results:
-.PP
-.RS
-.nf
-.B % interface_cmp -d -o $SRC/ELF-data.$MACH.ref/interfaces\ \\\\
-.B \ \ \ \ \ \ \ $SRC/ELF-data.$MACH/interfaces
-lib/libadm.so.1: SUNW_1.1: added interface: circf(4)
-lib/libaio.so.1: SUNW_1.1: deleted interface: _aiocancel
-.fi
-.RE
-.sp
-.PP
-Note: the above comparison files were doctored in order to provide
-the example, they do not indicate any real changes that have
-occurred in the associated system libraries.
-.br
-.SH SEE ALSO
-.BR find_elf(1),
-.BR interface_check(1),
-.BR ld(1),
-.BR ldd(1),
-.BR elfdump(1),
-.BR pvs(1).
-.LP
-.TZ LLM
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/interface_cmp.1onbld	Wed Sep 30 19:35:40 2015
@@ -0,0 +1,245 @@
+.\" Copyright (c) 2009, 2010, Oracle and/or its affiliates. All rights reserved.
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.TH interface_cmp 1ONBLD "25 March 2010"
+.SH NAME
+interface_cmp \- compare shared object interface descriptions
+.SH SYNOPSIS
+\fBinterface_cmp [-dot] [-e exfile] old new\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "interface_cmp" "" "\fBinterface_cmp\fP"
+The
+.I interface_cmp
+command compares the interface definition files for two workspaces
+and reports versioning inconsistencies. Interface definition
+files are created by
+.IR interface_check.
+.PP
+.I interface_cmp
+is typically called from \fBnightly(1ONBLD)\fP when the \fB-A\fP
+option is in effect following the creation of a new database by
+.IR interface_check .
+To insure symbolic
+interface consistency between successive software releases, existing
+version definitions and their symbol association should remain intact.
+Any discrepancies between the two interface definitions are flagged as
+errors.
+.PP
+Note that version definition inheritance has the effect of causing a
+symbol to be viewed as existing in multiple definitions. This insures
+that both version definitions and their inheritance relationship are
+processed as part of the comparison.
+.LP
+.SH OPTIONS
+.LP
+The following options are supported:
+.TP 4
+.B \-c vertype_module
+By default,
+.I interface_cmp
+is customized for the versioning conventions used by the Solaris
+OSnet code base. This specialized information, which includes
+the recognition of the SUNW_ prefix and other special names, is
+contained in a perl module named onbld_elfmod_vertype.pm, which
+is delivered with the SUNWonbld tools. This module is loaded by
+.I interface_cmp
+at runtime. The \fB-c\fP option can be used to supply
+an alternative module, customized for a different code base, allowing
+.I interface_cmp
+to operate on code from other projects. The alternative module must
+supply the same module and calling interfaces as the standard module.
+.TP 4
+.B \-d
+Asserts that the \fBnew\fP interface is a direct descendant of
+\fBold\fP. If so, the following additional checks are enabled:
+.RS +4
+.TP
+.ie t \(bu
+.el o
+The top version of an inheritance chain must not increase
+by more than one.
+.RE
+.RS +4
+.TP
+.ie t \(bu
+.el o
+The new interface must not add new empty versions. Pre-existing empty
+versions represent public interfaces that cannot be changed, but new
+ones should be removed before the product ships.
+.RE
+.sp
+.LP
+.TP 4
+.B \-e exfile
+An exception file is used to exclude objects from
+the usual rules. See EXCEPTION FILE FORMAT.
+.TP 4
+.B \-o
+Produce one-liner output, with each line of diagnostic output 
+prefixed with the object pathname.
+.TP 4
+.B \-t
+If the \fB-t\fP option is present, only one argument is allowed.
+The interface description file is parsed, and then regenerated on
+stdout in the same format used by the
+.I interface_check
+\fB-I\fP option. The \fB-I\fP output from
+.I interface_check
+and the output from
+.I interface_cmp
+\fB-t\fP
+should be identical, excluding header comments. 
+This is a debugging feature, and not intended for general use.
+.LP
+.SH EXCEPTION FILE FORMAT
+Exceptions to the rules enforced by
+.I interface_cmp
+are specified using an exception file. The \fB-e\fP option is used to
+specify an explicit exception file. Otherwise, if used in an activated
+workspace, the default exception file is
+$CODEMGR_WS/exception_list/interface_cmp
+if that file exists. If not used in an activated workspace, or if
+$CODEMGR_WS/exception_list/interface_cmp does not exist,
+.I interface_cmp
+will use
+.I /opt/onbld/etc/exception_list/interface_cmp
+as a fallback default exception file.
+.p
+To run
+.I interface_cmp
+without applying exceptions, specify \fB-e\fP with a value of /dev/null.
+.P
+A '#' character at the beginning of a line, or at any point in
+a line when preceded by whitespace, introduces a comment. Empty lines, 
+and lines containing only comments, are ignored by
+.I interface_cmp.
+Exceptions are specified as space separated keyword, and \fBperl(1)\fP
+regular expressions. The number of regular expressions depends on the
+particular exception in questions:
+.sp
+.in +4
+.nf
+keyword  perl-regex...
+.fi
+.in -4
+.sp
+Since whitespace is used as a separator, the regular
+expression cannot itself contain whitespace. Use of the \\s character
+class to represent whitespace within the regular expression is recommended.
+Before the perl regular expression is used, constructs of the form
+MACH(dir) are expanded into a regular expression that matches the directory
+given, as well as any 64-bit architecture subdirectory that
+might be present (i.e. amd64, sparcv9). For instance, MACH(lib) will
+match any of the following:
+.sp
+.in +4
+.nf
+lib
+lib/amd64
+lib/sparcv9
+.fi
+.in -4
+.sp
+The exceptions understood by
+.I interface_cmp
+are:
+.sp
+.ne 2
+.mk
+.na
+\fBADDSYM\fR sym_re version_re object_re
+.ad
+.RS 17n
+.rt
+.sp
+The interfaces in a given version are not supposed to change. 
+.I interface_cmp
+will normally issue an error if a new interface is added to a previously
+released version. ADDSYM is used to override this
+requirement. If the added symbol, version, and object match
+the regular expressions specified by ADDSYM, the added symbol is ignored.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBDELDYM\fR sym_re version_re object_re
+.ad
+.RS 17n
+.rt
+.sp
+Once released to the public, interfaces are required to remain available
+in subsequent releases. DELSYM is used to override this
+requirement, as can occur when interfaces are EOL'd. Such an action generally
+requires a PSARC case. If the deleted symbol, version, and object match
+the regular expressions specified by DELSYM, the deleted symbol is ignored.
+.RE
+
+.sp
+.ne 2
+.mk
+.na
+\fBEMPTY_TOPVERSION\fR version_re object_re
+.ad
+.RS 17n
+.rt
+.sp
+.I
+interface_cmp
+normally issues an error if the old object has an empty top version
+that is non-empty in the new object. Such a situation is normally
+an error, but may legitimately occur as part of a fix to another versioning
+error.  If the version, and object match
+the regular expressions specified by EMPTY_TOPVERSION, the error is suppressed.
+.RE
+
+.PP
+.SH EXAMPLES
+The following example uses
+.I interface_cmp
+to compare this releases interface definition with a previous
+builds results:
+.PP
+.RS
+.nf
+.B % interface_cmp -d -o $SRC/ELF-data.$MACH.ref/interfaces\ \\\\
+.B \ \ \ \ \ \ \ $SRC/ELF-data.$MACH/interfaces
+lib/libadm.so.1: SUNW_1.1: added interface: circf(4)
+lib/libaio.so.1: SUNW_1.1: deleted interface: _aiocancel
+.fi
+.RE
+.sp
+.PP
+Note: the above comparison files were doctored in order to provide
+the example, they do not indicate any real changes that have
+occurred in the associated system libraries.
+.br
+.SH SEE ALSO
+.BR find_elf(1ONBLD),
+.BR interface_check(1ONBLD),
+.BR ld(1),
+.BR ldd(1),
+.BR elfdump(1),
+.BR pvs(1).
+.LP
+.TZ LLM
--- old/usr/src/tools/scripts/jstyle.1	Wed Sep 30 19:35:40 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,118 +0,0 @@
-.\" ident	"%Z%%M%	%I%	%E% SMI"
-.\" Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.TH jstyle 1 "22 November 2005"
-.SH NAME
-.I jstyle
-\- check for some common stylistic errors in Java source files
-.SH SYNOPSIS
-\fBjstyle [-chptvC] [file...]\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "jstyle" "" "\fBjstyle\fP"
-.LP
-.B jstyle
-inspects Java source files (*.java) for common stylistic errors.  It
-is similar to
-.BR cstyle (1)
-in that it attempts to check for the style
-documented in \fI/shared/ON/general_docs/cstyle.ms.pdf\fP, although by
-necessity is modified to work with Java-specific constructs.  Note that
-there is much in that document that
-.I cannot
-be checked for; just because your code is
-.BR jstyle (1)
-clean does not
-mean that you've followed Sun's Java style.  \fICaveat emptor\fP.
-.LP
-.SH OPTIONS
-.LP
-The following options are supported:
-.TP 4
-.B \-c
-Check continuation line indentation inside of functions.  Sun's C style
-states that all statements must be indented to an appropriate tab stop,
-and any continuation lines after them must be indented \fIexactly\fP four
-spaces from the start line.  This option enables a series of checks
-designed to find contination line problems within functions only.
-.LP
-.TP 4
-.B \-h
-Performs heuristic checks that are sometimes wrong.  Not generally used.
-.LP
-.TP 4
-.B \-p
-Performs some of the more picky checks.  You should generally use this.
-.LP
-.LP
-.TP 4
-.B \-t
-Insists on indentation with tabs.  Because of the depth of nested blocks
-that Java requires, and the commonality of long identifiers, tab
-indentation in Java code is not always useful, assuming that tabs are fixed
-at eight columns and that maximum line length is fixed at eighty columns,
-so this option is not on by default.  If you choose to consider tabs to be
-four columns wide (not acceptable for ON), or are writing simple enough
-code that the nesting is not very deep, this option might be useful.
-Otherwise, avoid it.
-.LP
-.TP 4
-.B \-v
-Verbose output; includes the text of the line of error.
-.LP
-.TP 4
-.B \-C
-Ignore errors in header comments (i.e., block comments starting in the
-first column).  Not generally used.
-.LP
-.LP
-.SH NOTES
-.LP
-The jstyle rule for the OS/Net consolidation is that all new files must
-be
-.B -p
-clean.  For existing files, the following invocations are
-run against both the old and new files:
-.LP
-.TP 4
-.B "jstyle file"
-.LP
-.TP 4
-.B "jstyle -p file"
-.LP
-If the old file gave no errors for one of the invocations, the new file
-must also give no errors.  This way, files cannot become unclean.
-.LP
-.SH BUGS
-.LP
-.BR jstyle (1)
-cannot disambiguate Java generic type parameters or
-arguments that span multiple lines from relational operators.  For example:
-.RS 4
-.HP 4
-private class Foo<A extends Bar,
-.br
-B extends Bar> { ...
-.RE
-.LP
-is flagged as two lines with missing spaces around relational operators.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/jstyle.1onbld	Wed Sep 30 19:35:40 2015
@@ -0,0 +1,117 @@
+.\" Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.TH jstyle 1ONBLD "22 November 2005"
+.SH NAME
+.I jstyle
+\- check for some common stylistic errors in Java source files
+.SH SYNOPSIS
+\fBjstyle [-chptvC] [file...]\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "jstyle" "" "\fBjstyle\fP"
+.LP
+.B jstyle
+inspects Java source files (*.java) for common stylistic errors.  It
+is similar to
+.BR cstyle (1ONBLD)
+in that it attempts to check for the style
+documented in \fI/shared/ON/general_docs/cstyle.ms.pdf\fP, although by
+necessity is modified to work with Java-specific constructs.  Note that
+there is much in that document that
+.I cannot
+be checked for; just because your code is
+.BR jstyle (1ONBLD)
+clean does not
+mean that you've followed Sun's Java style.  \fICaveat emptor\fP.
+.LP
+.SH OPTIONS
+.LP
+The following options are supported:
+.TP 4
+.B \-c
+Check continuation line indentation inside of functions.  Sun's C style
+states that all statements must be indented to an appropriate tab stop,
+and any continuation lines after them must be indented \fIexactly\fP four
+spaces from the start line.  This option enables a series of checks
+designed to find contination line problems within functions only.
+.LP
+.TP 4
+.B \-h
+Performs heuristic checks that are sometimes wrong.  Not generally used.
+.LP
+.TP 4
+.B \-p
+Performs some of the more picky checks.  You should generally use this.
+.LP
+.LP
+.TP 4
+.B \-t
+Insists on indentation with tabs.  Because of the depth of nested blocks
+that Java requires, and the commonality of long identifiers, tab
+indentation in Java code is not always useful, assuming that tabs are fixed
+at eight columns and that maximum line length is fixed at eighty columns,
+so this option is not on by default.  If you choose to consider tabs to be
+four columns wide (not acceptable for ON), or are writing simple enough
+code that the nesting is not very deep, this option might be useful.
+Otherwise, avoid it.
+.LP
+.TP 4
+.B \-v
+Verbose output; includes the text of the line of error.
+.LP
+.TP 4
+.B \-C
+Ignore errors in header comments (i.e., block comments starting in the
+first column).  Not generally used.
+.LP
+.LP
+.SH NOTES
+.LP
+The jstyle rule for the OS/Net consolidation is that all new files must
+be
+.B -p
+clean.  For existing files, the following invocations are
+run against both the old and new files:
+.LP
+.TP 4
+.B "jstyle file"
+.LP
+.TP 4
+.B "jstyle -p file"
+.LP
+If the old file gave no errors for one of the invocations, the new file
+must also give no errors.  This way, files cannot become unclean.
+.LP
+.SH BUGS
+.LP
+.BR jstyle (1ONBLD)
+cannot disambiguate Java generic type parameters or
+arguments that span multiple lines from relational operators.  For example:
+.RS 4
+.HP 4
+private class Foo<A extends Bar,
+.br
+B extends Bar> { ...
+.RE
+.LP
+is flagged as two lines with missing spaces around relational operators.
--- old/usr/src/tools/scripts/mapfilechk.1	Wed Sep 30 19:35:40 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,78 +0,0 @@
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.TH mapfilechk 1 "27 January 2009"
-.SH NAME
-mapfilechk \- Check for valid link-editor mapfile header blocks
-.SH SYNOPSIS
-.nf
-\fBmapfilechk \fR [\fB-v\fR] [\fB-x\fR \fIexceptions_file\fR] [\fIpath\fR...]
-.fi
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "mapfilechk" "" "\fBmapfilechk\fP"
-mapfilechk inspects link-editor mapfiles for missing, obsolete,
-or corrupt mapfile header blocks.
-.LP
-.SH OPTIONS
-.LP
-.TP 4
-.B \-v
-Report on all files, not just those with invalid headers
-.LP
-.TP 4
-.B \-x \fIexceptions_file\fR
-Load an exceptions file containing a list of files, directories and
-file extensions to be ignored.
-Exceptions may be one of three types:
-.RS +4
-.TP
-.ie t \(bu
-.el o
-File paths
-.RE
-.RS +4
-.TP
-.ie t \(bu
-.el o
-Directories, specified with a trailing '/'
-.RE
-.RS +4
-.TP
-.ie t \(bu
-.el o
-File extensions, specified with a leading '*.'
-.RE
-.LP
-.SH EXIT STATUS
-.TP 4
-.B 0
-The command completed successfully.
-No errors or warnings were reported
-.LP
-.TP 4
-.B 1
-The command completed unsuccessfully.
-One or more errors or warnings were reported.
-.LP
-.TP 4
-.B 2
-Invalid command-line arguments were specified to the command.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/mapfilechk.1onbld	Wed Sep 30 19:35:40 2015
@@ -0,0 +1,78 @@
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.TH mapfilechk 1ONBLD "27 January 2009"
+.SH NAME
+mapfilechk \- Check for valid link-editor mapfile header blocks
+.SH SYNOPSIS
+.nf
+\fBmapfilechk \fR [\fB-v\fR] [\fB-x\fR \fIexceptions_file\fR] [\fIpath\fR...]
+.fi
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "mapfilechk" "" "\fBmapfilechk\fP"
+mapfilechk inspects link-editor mapfiles for missing, obsolete,
+or corrupt mapfile header blocks.
+.LP
+.SH OPTIONS
+.LP
+.TP 4
+.B \-v
+Report on all files, not just those with invalid headers
+.LP
+.TP 4
+.B \-x \fIexceptions_file\fR
+Load an exceptions file containing a list of files, directories and
+file extensions to be ignored.
+Exceptions may be one of three types:
+.RS +4
+.TP
+.ie t \(bu
+.el o
+File paths
+.RE
+.RS +4
+.TP
+.ie t \(bu
+.el o
+Directories, specified with a trailing '/'
+.RE
+.RS +4
+.TP
+.ie t \(bu
+.el o
+File extensions, specified with a leading '*.'
+.RE
+.LP
+.SH EXIT STATUS
+.TP 4
+.B 0
+The command completed successfully.
+No errors or warnings were reported
+.LP
+.TP 4
+.B 1
+The command completed unsuccessfully.
+One or more errors or warnings were reported.
+.LP
+.TP 4
+.B 2
+Invalid command-line arguments were specified to the command.
--- old/usr/src/tools/scripts/nightly.1	Wed Sep 30 19:35:41 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,563 +0,0 @@
-.\" "
-.\" " The contents of this file are subject to the terms of the
-.\" " Common Development and Distribution License (the "License").
-.\" " You may not use this file except in compliance with the License.
-.\" "
-.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" " or http://www.opensolaris.org/os/licensing.
-.\" " See the License for the specific language governing permissions
-.\" " and limitations under the License.
-.\" "
-.\" " When distributing Covered Code, include this CDDL HEADER in each
-.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" " If applicable, add the following below this CDDL HEADER, with the
-.\" " fields enclosed by brackets "[]" replaced with your own identifying
-.\" " information: Portions Copyright [yyyy] [name of copyright owner]
-.\" "
-.\" " CDDL HEADER END
-.\" "
-.\" "Copyright (c) 1999, 2010, Oracle and/or its affiliates. All rights reserved.
-.\" "Copyright 2012 Joshua M. Clulow <josh@sysmgr.org>
-.\" "
-.TH nightly 1 "Jan 28, 2014"
-.SH NAME
-.I nightly
-\- build an OS-Net consolidation overnight
-.SH SYNOPSIS
-\fBnightly [-in] [-V VERS] <env_file>\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "nightly" "" "\fBnightly\fP"
-.LP
-.I nightly,
-the mother of all build scripts,
-can bringover, build, archive, package, error check, and
-generally do everything it takes to
-turn OS/Net consolidation source code into useful stuff.
-It is customizable to permit you to run anything from a
-simple build to all of the cross-checking a gatekeeper
-needs.  The advantage to using
-.I nightly
-is that you build things correctly, consistently and
-automatically, with the best practices; building with
-.I nightly
-can mean never having to say you're sorry to your
-gatekeeper.
-.LP
-More
-specifically,
-.I nightly
-performs the following tasks, in order, if
-all these things are desired:
-.LP
-.RS
-.TP
-\(bu
-perform a "make clobber" to clean up old binaries
-.TP
-\(bu
-bringover from the identified parent gate/clone
-.TP
-\(bu
-perform non-DEBUG and DEBUG builds
-.TP
-\(bu
-list proto area files and compare with previous list
-.TP
-\(bu
-copy updated proto area to parent
-.TP
-\(bu
-list shared lib interface and compare with previous list
-.TP
-\(bu
-perform a "make lint" of the kernel and report errors
-.TP
-\(bu
-perform a "make check" to report hdrchk/cstyle errors
-.TP
-\(bu
-report the presence of any core files
-.TP
-\(bu
-check the ELF runtime attributes of all dynamic objects
-.TP
-\(bu
-check for unreferenced files
-.TP
-\(bu
-report on which proto area objects have changed (since the last build)
-.TP
-\(bu
-report the total build time
-.TP
-\(bu
-save a detailed log file for reference
-.TP
-\(bu
-mail the user a summary of the completed build
-.RE
-.LP
-The actions of the script are almost completely determined by
-the environment variables in the
-.I env
-file, the only necessary argument.  Ths only thing you really
-need to use 
-.I nightly
-is an
-.I env
-file that does what you want.
-.LP
-Like most of the other build tools in usr/src/tools, this script tends
-to change on a fairly regular basis; do not expect to be able to build
-OS/Net with a version of nightly significantly older than your source
-tree.  It has what is effectively a Consolidation Private relationship
-to other build tools and with many parts of the OS/Net makefiles,
-although it may also be used to build other consolidations.
-.LP
-.SH NIGHTLY_OPTIONS
-The environment variable NIGHTLY_OPTIONS controls the actions
-.I nightly
-will take as it proceeds.
-The -i, -n, +t and -V options may also be used from the command
-line to control the actions without editing your environment file.
-The -i and -n options complete the build more quickly by bypassing
-some actions. If NIGHTLY_OPTIONS is not set, then "-Bmt" build
-options will be used.
-
-.B Basic action options
-.TP 10
-.B \-D
-Do a build with DEBUG on (non-DEBUG is built by default)
-.TP
-.B \-F
-Do _not_ do a non-DEBUG build (use with -D to get just a DEBUG build)
-.TP
-.B \-M
-Do not run pmodes (safe file permission checker)
-.TP
-.B \-i
-Do an incremental build, suppressing the "make clobber" that by
-default removes all existing binaries and derived files.  From the
-command line, -i also suppresses the lint pass and the cstyle/hdrchk
-pass
-.TP
-.B \-n
-Suppress the bringover so that the build will start immediately with
-current source code
-.TP
-.B \-p
-Create packages for regular install
-.TP
-.B \-U
-Update proto area in the parent workspace
-.TP
-.B \-u
-Update the parent workspace with files generated by the build, as follows.
-.RS
-.TP
-\(bu
-Copy proto_list_${MACH} and friends to usr/src in the parent.
-.TP
-\(bu
-When used with -f, build a usr/src/unrefmaster.out in
-the parent by merging all the usr/src/unref-${MACH}.out files in the
-parent.
-.TP
-\(bu
-When used with -A or -r, copy the contents of the resulting
-ELF-data.${MACH} directory to usr/src/ELF-data.${MACH} in the parent
-workspace.
-.RE
-.TP
-.B \-m
-Send mail to $MAILTO at end of build
-.TP
-.B \-t
-Build and use the tools in $SRC/tools (default setting).
-.TP
-.B \+t
-Use the build tools in "$ONBLD_TOOLS/bin".
-
-.LP
-.B Code checking options
-.TP 10
-.B \-A
-Check for ABI discrepancies in .so files.
-It is only required for shared object developers when there is an
-addition, deletion or change of interface in the .so files.
-.TP
-.B \-C
-Check for cstyle/hdrchk errors
-.TP
-.B \-f
-Check for unreferenced files.  Since the full workspace must be built
-in order to accurately identify unreferenced files, -f is ignored for
-incremental (-i) builds, or builds that do not include -l, and -p.
-.TP
-.B \-r
-Check the ELF runtime attributes of all dynamic objects
-.TP
-.B \-l
-Do "make lint" in $LINTDIRS (default: $SRC n)
-.TP
-.B \-N
-Do not run protocmp or checkpaths (note: this option is not
-recommended, especially in conjunction with the \-p option)
-.TP
-.B \-w
-Report which proto area objects differ between this and the last build.
-See wsdiff(1) for details. Note that the proto areas used for comparison
-are the last ones constructed as part of the build. As an example, if both
-a non-debug and debug build are performed (in that order), then the debug
-proto area will be used for comparison (which might not be what you want).
-.LP
-.B Groups of options
-.TP 10
-.B \-G
-Gate keeper default group of options (-u)
-.TP
-.B \-I
-Integration engineer default group of options (-mpu)
-.TP
-.B \-R
-Default group of options for building a release (-mp)
-
-.LP
-.B Miscellaneous options
-.TP 10
-.B \-V VERS
-set the build version string to VERS, overriding VERSION
-
-.LP
-.SH ENVIRONMENT VARIABLES
-.LP
-Here is a list of prominent environment variables that 
-.I nightly
-references and the meaning of each variable.
-.LP
-.RE
-.B CODEMGR_WS
-.RS 5
-The root of your workspace, including whatever metadata is kept by
-the source code management system.  This is the workspace in which the
-build will be done. 
-.RE
-.LP
-.B PARENT_WS
-.RS 5
-The root of the workspace that is the parent of the
-one being built.  This is particularly relevant for configurations
-with a main
-workspace and build workspaces underneath it; see the 
-\-u and \-U
-options as well as the PKGARCHIVE environment variable, for more
-information.
-.RE
-.LP
-.B BRINGOVER_WS
-.RS 5
-This is the workspace from which
-.I nightly
-will fetch sources to either populate or update your workspace;
-it defaults to $CLONE_WS.
-.RE
-.LP
-.B CLONE_WS
-.RS 5
-This is the workspace from which
-.I nightly
-will fetch sources by default.  This is
-often distinct from the parent, particularly if the parent is a gate.
-.RE
-.LP
-.B SRC
-.RS 5
-Root of OS-Net source code, referenced by the Makefiles.  It is
-the starting point of build activity.  It should be expressed
-in terms of $CODEMGR_WS.
-.RE
-.LP
-.B ROOT
-.RS 5
-Root of the proto area for the build.  The makefiles direct
-installation of build products to this area and
-direct references to these files by builds of commands and other
-targets.  It should be expressed in terms of $CODEMGR_WS.
-.LP
-If $MULTI_PROTO is "no", $ROOT may contain a DEBUG or non-DEBUG
-build.  If $MULTI_PROTO is "yes", $ROOT contains the DEBUG build and
-$ROOT-nd contains the non-DEBUG build.
-.RE
-.LP
-.B TOOLS_ROOT
-.RS 5
-Root of the tools proto area for the build.  The makefiles direct
-installation of tools build products to this area.  Unless \fB+t\fR
-is part of $NIGHTLY_OPTIONS, these tools will be used during the
-build.
-.LP
-As built by nightly, this will always contain non-DEBUG objects.
-Therefore, this will always have a -nd suffix, regardless of
-$MULTI_PROTO.
-.RE
-.LP
-.B MACH
-.RS 5
-The instruction set architecture of the build machine as given
-by \fIuname -p\fP, e.g. sparc, i386.
-.RE
-.LP
-.B LOCKNAME
-.RS 5
-The name of the file used to lock out multiple runs of
-.IR nightly .
-This should generally be left to the default setting.
-.RE
-.LP
-.B ATLOG
-.RS 5
-The location of the log directory maintained by
-.IR nightly .
-This should generally be left to the default setting.
-.RE
-.LP
-.B LOGFILE
-.RS 5
-The name of the log file in the $ATLOG directory maintained by
-.IR nightly .
-This should generally be left to the default setting.
-.RE
-.LP
-.B STAFFER
-.RS 5
-The non-root account to use on the build machine for the
-bringover from the clone or parent workspace.
-This may not be the same identify used by the SCM.
-.RE
-.LP
-.B MAILTO
-.RS 5
-The address to be used to send completion e-mail at the end of
-the build (for the \-m option).
-.RE
-.LP
-.B MAILFROM
-.RS 5
-The address to be used for From: in the completion e-mail at the
-end of the build (for the \-m option).
-.RE
-.LP
-.B REF_PROTO_LIST
-.RS 5
-Name of file used with protocmp to compare proto area contents.
-.RE
-.LP
-.B PARENT_ROOT
-.RS 5
-The parent root, which is the destination for copying the proto
-area(s) when using the \-U option.
-.RE
-.LP
-.B PARENT_TOOLS_ROOT
-.RS 5
-The parent tools root, which is the destination for copying the tools
-proto area when using the \-U option.
-.RE
-.LP
-.B RELEASE
-.RS 5
-The release version number to be used; e.g., 5.10.1 (Note: this is set
-in Makefile.master and should not normally be overridden).
-.RE
-.LP
-.B VERSION
-.RS 5
-The version text string to be used; e.g., "onnv:`date '+%Y-%m-%d'`".
-.RE
-.LP
-.B RELEASE_DATE
-.RS 5
-The release date text to be used; e.g., October 2009. If not set in
-your environment file, then this text defaults to the output from
-$(LC_ALL=C date +"%B %Y"); e.g., "October 2009".
-.RE
-.LP
-.B RELEASE_BUILD
-.RS 5
-Define this to build a release with a non-DEBUG kernel. 
-Generally, let
-.I nightly
-set this for you based on its options.
-.RE
-.LP
-.B PKGARCHIVE
-.RS 5
-The destination for packages.  This may be relative to
-$CODEMGR_WS for private packages or relative to $PARENT_WS
-if you have different workspaces for different architectures
-but want one hierarchy of packages.
-.RE
-.LP
-.B MAKEFLAGS
-.RS 5
-Set default flags to make; e.g., -k to build all targets regardless of errors.
-.RE
-.LP
-.B UT_NO_USAGE_TRACKING
-.RS 5
-Disables usage reporting by listed Devpro tools. Otherwise it sends mail
-to some Devpro machine every time the tools are used.
-.RE
-.LP
-.B LINTDIRS
-.RS 5
-Directories to lint with the \-l option.
-.RE
-.LP
-.B BUILD_TOOLS
-.RS 5
-BUILD_TOOLS is the root of all tools including the compilers; e.g.,
-/ws/onnv-tools.  It is used by the makefile system, but not nightly.
-.RE
-.LP
-.B ONBLD_TOOLS
-.RS 5
-ONBLD_TOOLS is the root of all the tools that are part of SUNWonbld; e.g.,
-/ws/onnv-tools/onbld.  By default, it is derived from
-.BR BUILD_TOOLS .
-It is used by the makefile system, but not nightly.
-.RE
-.LP
-.B SPRO_ROOT
-.RS 5
-The gate-defined default location for the Sun compilers, e.g.
-/ws/onnv-tools/SUNWspro.  By default, it is derived from
-.BR BUILD_TOOLS .
-It is used by the makefile system, but not nightly.
-.RE
-.LP
-.B JAVA_ROOT
-.RS 5
-The location for the java compilers for the build, generally /usr/java.
-.RE
-.LP
-.B OPTHOME
-.RS 5
-The gate-defined default location of things formerly in /opt; e.g.,
-/ws/onnv-tools.  This is used by nightly, but not the makefiles.
-.RE
-.LP
-.B TEAMWARE
-.RS 5
-The gate-defined default location for the Teamware tools; e.g.,
-/ws/onnv-tools/SUNWspro.  By default, it is derived from
-.BR OPTHOME .
-This is used by nightly, but not the makefiles.  There is no
-corresponding variable for Mercurial or Subversion, which are assumed
-to be installed in the default path.
-.RE
-.LP
-.B ON_CLOSED_BINS
-.RS 5
-OpenSolaris builds do not contain the closed source tree.  Instead,
-the developer downloads a closed binaries tree and unpacks it.  
-.B ON_CLOSED_BINS
-tells nightly
-where to find these closed binaries, so that it can add them into the
-build.
-.RE
-.LP
-.B CHECK_PATHS
-.RS 5
-Normally, nightly runs the 'checkpaths' script to check for
-discrepancies among the files that list paths to other files, such as
-exception lists and req.flg.  Set this flag to 'n' to disable this
-check, which appears in the nightly output as "Check lists of files."
-.RE
-.LP
-.B CHECK_DMAKE
-.RS 5
-Nightly validates that the version of dmake encountered is known to be
-safe to use.  Set this flag to 'n' to disable this test, allowing any
-version of dmake to be used.
-.RE
-.LP
-.B MULTI_PROTO
-.RS 5
-If "no" (the default), 
-.I nightly
-will reuse $ROOT for both the DEBUG and non-DEBUG builds.  If "yes",
-the DEBUG build will go in $ROOT and the non-DEBUG build will go in
-$ROOT-nd.  Other values will be treated as "no".
-.RE
-.LP
-.SH NIGHTLY HOOK ENVIRONMENT VARIABLES
-.LP
-Several optional environment variables may specify commands to run at
-various points during the build.  Commands specified in the hook
-variable will be run in a subshell; command output will be appended to
-the mail message and log file.  If the hook exits with a non-zero
-status, the build is aborted immediately.  Environment variables
-defined in the environment file will be available.
-.LP
-.B SYS_PRE_NIGHTLY
-.RS 5
-Run just after the workspace lock is acquired.  This is reserved for
-per-build-machine customizations and should be set only in /etc/nightly.conf
-.RE
-.LP
-.B PRE_NIGHTLY
-.RS 5
-Run just after SYS_PRE_NIGHTLY.
-.RE
-.LP
-.B PRE_BRINGOVER
-.RS 5
-Run just before bringover is started; not run if no bringover is done.
-.RE
-.LP
-.B POST_BRINGOVER
-.RS 5
-Run just after bringover completes; not run if no bringover is done.
-.RE
-.LP
-.B POST_NIGHTLY
-.RS 5
-Run after the build completes, with the return status of nightly - one
-of "Completed", "Interrupted", or "Failed" - available in the
-environment variable NIGHTLY_STATUS.
-.RE
-.LP
-.B SYS_POST_NIGHTLY
-.RS 5
-This is reserved for per-build-machine customizations, and runs
-immedately after POST_NIGHTLY.
-.RE
-.LP
-.SH FILES
-.LP
-.RS 5
-/etc/nightly.conf
-.RE
-.LP
-If present, nightly executes this file just prior to executing the
-.I env
-file.  
-.SH EXAMPLES
-.LP
-Start with the example file in usr/src/tools/env/developer.sh
-(or gatekeeper.sh), copy to myenv and make your changes.
-.LP
-.PD 0
-# grep NIGHTLY_OPTIONS myenv
-.LP
-NIGHTLY_OPTIONS="-ACrlapDm"
-.LP
-export NIGHTLY_OPTIONS
-.LP
-# /opt/onbld/bin/nightly -i myenv
-.PD
-.LP
-.SH SEE ALSO
-.BR bldenv (1)
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/nightly.1onbld	Wed Sep 30 19:35:41 2015
@@ -0,0 +1,563 @@
+.\" "
+.\" " The contents of this file are subject to the terms of the
+.\" " Common Development and Distribution License (the "License").
+.\" " You may not use this file except in compliance with the License.
+.\" "
+.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" " or http://www.opensolaris.org/os/licensing.
+.\" " See the License for the specific language governing permissions
+.\" " and limitations under the License.
+.\" "
+.\" " When distributing Covered Code, include this CDDL HEADER in each
+.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" " If applicable, add the following below this CDDL HEADER, with the
+.\" " fields enclosed by brackets "[]" replaced with your own identifying
+.\" " information: Portions Copyright [yyyy] [name of copyright owner]
+.\" "
+.\" " CDDL HEADER END
+.\" "
+.\" "Copyright (c) 1999, 2010, Oracle and/or its affiliates. All rights reserved.
+.\" "Copyright 2012 Joshua M. Clulow <josh@sysmgr.org>
+.\" "
+.TH nightly 1ONBLD "Jan 28, 2014"
+.SH NAME
+.I nightly
+\- build an OS-Net consolidation overnight
+.SH SYNOPSIS
+\fBnightly [-in] [-V VERS] <env_file>\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "nightly" "" "\fBnightly\fP"
+.LP
+.I nightly,
+the mother of all build scripts,
+can bringover, build, archive, package, error check, and
+generally do everything it takes to
+turn OS/Net consolidation source code into useful stuff.
+It is customizable to permit you to run anything from a
+simple build to all of the cross-checking a gatekeeper
+needs.  The advantage to using
+.I nightly
+is that you build things correctly, consistently and
+automatically, with the best practices; building with
+.I nightly
+can mean never having to say you're sorry to your
+gatekeeper.
+.LP
+More
+specifically,
+.I nightly
+performs the following tasks, in order, if
+all these things are desired:
+.LP
+.RS
+.TP
+\(bu
+perform a "make clobber" to clean up old binaries
+.TP
+\(bu
+bringover from the identified parent gate/clone
+.TP
+\(bu
+perform non-DEBUG and DEBUG builds
+.TP
+\(bu
+list proto area files and compare with previous list
+.TP
+\(bu
+copy updated proto area to parent
+.TP
+\(bu
+list shared lib interface and compare with previous list
+.TP
+\(bu
+perform a "make lint" of the kernel and report errors
+.TP
+\(bu
+perform a "make check" to report hdrchk/cstyle errors
+.TP
+\(bu
+report the presence of any core files
+.TP
+\(bu
+check the ELF runtime attributes of all dynamic objects
+.TP
+\(bu
+check for unreferenced files
+.TP
+\(bu
+report on which proto area objects have changed (since the last build)
+.TP
+\(bu
+report the total build time
+.TP
+\(bu
+save a detailed log file for reference
+.TP
+\(bu
+mail the user a summary of the completed build
+.RE
+.LP
+The actions of the script are almost completely determined by
+the environment variables in the
+.I env
+file, the only necessary argument.  Ths only thing you really
+need to use 
+.I nightly
+is an
+.I env
+file that does what you want.
+.LP
+Like most of the other build tools in usr/src/tools, this script tends
+to change on a fairly regular basis; do not expect to be able to build
+OS/Net with a version of nightly significantly older than your source
+tree.  It has what is effectively a Consolidation Private relationship
+to other build tools and with many parts of the OS/Net makefiles,
+although it may also be used to build other consolidations.
+.LP
+.SH NIGHTLY_OPTIONS
+The environment variable NIGHTLY_OPTIONS controls the actions
+.I nightly
+will take as it proceeds.
+The -i, -n, +t and -V options may also be used from the command
+line to control the actions without editing your environment file.
+The -i and -n options complete the build more quickly by bypassing
+some actions. If NIGHTLY_OPTIONS is not set, then "-Bmt" build
+options will be used.
+
+.B Basic action options
+.TP 10
+.B \-D
+Do a build with DEBUG on (non-DEBUG is built by default)
+.TP
+.B \-F
+Do _not_ do a non-DEBUG build (use with -D to get just a DEBUG build)
+.TP
+.B \-M
+Do not run pmodes (safe file permission checker)
+.TP
+.B \-i
+Do an incremental build, suppressing the "make clobber" that by
+default removes all existing binaries and derived files.  From the
+command line, -i also suppresses the lint pass and the cstyle/hdrchk
+pass
+.TP
+.B \-n
+Suppress the bringover so that the build will start immediately with
+current source code
+.TP
+.B \-p
+Create packages for regular install
+.TP
+.B \-U
+Update proto area in the parent workspace
+.TP
+.B \-u
+Update the parent workspace with files generated by the build, as follows.
+.RS
+.TP
+\(bu
+Copy proto_list_${MACH} and friends to usr/src in the parent.
+.TP
+\(bu
+When used with -f, build a usr/src/unrefmaster.out in
+the parent by merging all the usr/src/unref-${MACH}.out files in the
+parent.
+.TP
+\(bu
+When used with -A or -r, copy the contents of the resulting
+ELF-data.${MACH} directory to usr/src/ELF-data.${MACH} in the parent
+workspace.
+.RE
+.TP
+.B \-m
+Send mail to $MAILTO at end of build
+.TP
+.B \-t
+Build and use the tools in $SRC/tools (default setting).
+.TP
+.B \+t
+Use the build tools in "$ONBLD_TOOLS/bin".
+
+.LP
+.B Code checking options
+.TP 10
+.B \-A
+Check for ABI discrepancies in .so files.
+It is only required for shared object developers when there is an
+addition, deletion or change of interface in the .so files.
+.TP
+.B \-C
+Check for cstyle/hdrchk errors
+.TP
+.B \-f
+Check for unreferenced files.  Since the full workspace must be built
+in order to accurately identify unreferenced files, -f is ignored for
+incremental (-i) builds, or builds that do not include -l, and -p.
+.TP
+.B \-r
+Check the ELF runtime attributes of all dynamic objects
+.TP
+.B \-l
+Do "make lint" in $LINTDIRS (default: $SRC n)
+.TP
+.B \-N
+Do not run protocmp or checkpaths (note: this option is not
+recommended, especially in conjunction with the \-p option)
+.TP
+.B \-w
+Report which proto area objects differ between this and the last build.
+See wsdiff(1ONBLD) for details. Note that the proto areas used for comparison
+are the last ones constructed as part of the build. As an example, if both
+a non-debug and debug build are performed (in that order), then the debug
+proto area will be used for comparison (which might not be what you want).
+.LP
+.B Groups of options
+.TP 10
+.B \-G
+Gate keeper default group of options (-u)
+.TP
+.B \-I
+Integration engineer default group of options (-mpu)
+.TP
+.B \-R
+Default group of options for building a release (-mp)
+
+.LP
+.B Miscellaneous options
+.TP 10
+.B \-V VERS
+set the build version string to VERS, overriding VERSION
+
+.LP
+.SH ENVIRONMENT VARIABLES
+.LP
+Here is a list of prominent environment variables that 
+.I nightly
+references and the meaning of each variable.
+.LP
+.RE
+.B CODEMGR_WS
+.RS 5
+The root of your workspace, including whatever metadata is kept by
+the source code management system.  This is the workspace in which the
+build will be done. 
+.RE
+.LP
+.B PARENT_WS
+.RS 5
+The root of the workspace that is the parent of the
+one being built.  This is particularly relevant for configurations
+with a main
+workspace and build workspaces underneath it; see the 
+\-u and \-U
+options as well as the PKGARCHIVE environment variable, for more
+information.
+.RE
+.LP
+.B BRINGOVER_WS
+.RS 5
+This is the workspace from which
+.I nightly
+will fetch sources to either populate or update your workspace;
+it defaults to $CLONE_WS.
+.RE
+.LP
+.B CLONE_WS
+.RS 5
+This is the workspace from which
+.I nightly
+will fetch sources by default.  This is
+often distinct from the parent, particularly if the parent is a gate.
+.RE
+.LP
+.B SRC
+.RS 5
+Root of OS-Net source code, referenced by the Makefiles.  It is
+the starting point of build activity.  It should be expressed
+in terms of $CODEMGR_WS.
+.RE
+.LP
+.B ROOT
+.RS 5
+Root of the proto area for the build.  The makefiles direct
+installation of build products to this area and
+direct references to these files by builds of commands and other
+targets.  It should be expressed in terms of $CODEMGR_WS.
+.LP
+If $MULTI_PROTO is "no", $ROOT may contain a DEBUG or non-DEBUG
+build.  If $MULTI_PROTO is "yes", $ROOT contains the DEBUG build and
+$ROOT-nd contains the non-DEBUG build.
+.RE
+.LP
+.B TOOLS_ROOT
+.RS 5
+Root of the tools proto area for the build.  The makefiles direct
+installation of tools build products to this area.  Unless \fB+t\fR
+is part of $NIGHTLY_OPTIONS, these tools will be used during the
+build.
+.LP
+As built by nightly, this will always contain non-DEBUG objects.
+Therefore, this will always have a -nd suffix, regardless of
+$MULTI_PROTO.
+.RE
+.LP
+.B MACH
+.RS 5
+The instruction set architecture of the build machine as given
+by \fIuname -p\fP, e.g. sparc, i386.
+.RE
+.LP
+.B LOCKNAME
+.RS 5
+The name of the file used to lock out multiple runs of
+.IR nightly .
+This should generally be left to the default setting.
+.RE
+.LP
+.B ATLOG
+.RS 5
+The location of the log directory maintained by
+.IR nightly .
+This should generally be left to the default setting.
+.RE
+.LP
+.B LOGFILE
+.RS 5
+The name of the log file in the $ATLOG directory maintained by
+.IR nightly .
+This should generally be left to the default setting.
+.RE
+.LP
+.B STAFFER
+.RS 5
+The non-root account to use on the build machine for the
+bringover from the clone or parent workspace.
+This may not be the same identify used by the SCM.
+.RE
+.LP
+.B MAILTO
+.RS 5
+The address to be used to send completion e-mail at the end of
+the build (for the \-m option).
+.RE
+.LP
+.B MAILFROM
+.RS 5
+The address to be used for From: in the completion e-mail at the
+end of the build (for the \-m option).
+.RE
+.LP
+.B REF_PROTO_LIST
+.RS 5
+Name of file used with protocmp to compare proto area contents.
+.RE
+.LP
+.B PARENT_ROOT
+.RS 5
+The parent root, which is the destination for copying the proto
+area(s) when using the \-U option.
+.RE
+.LP
+.B PARENT_TOOLS_ROOT
+.RS 5
+The parent tools root, which is the destination for copying the tools
+proto area when using the \-U option.
+.RE
+.LP
+.B RELEASE
+.RS 5
+The release version number to be used; e.g., 5.10.1 (Note: this is set
+in Makefile.master and should not normally be overridden).
+.RE
+.LP
+.B VERSION
+.RS 5
+The version text string to be used; e.g., "onnv:`date '+%Y-%m-%d'`".
+.RE
+.LP
+.B RELEASE_DATE
+.RS 5
+The release date text to be used; e.g., October 2009. If not set in
+your environment file, then this text defaults to the output from
+$(LC_ALL=C date +"%B %Y"); e.g., "October 2009".
+.RE
+.LP
+.B RELEASE_BUILD
+.RS 5
+Define this to build a release with a non-DEBUG kernel. 
+Generally, let
+.I nightly
+set this for you based on its options.
+.RE
+.LP
+.B PKGARCHIVE
+.RS 5
+The destination for packages.  This may be relative to
+$CODEMGR_WS for private packages or relative to $PARENT_WS
+if you have different workspaces for different architectures
+but want one hierarchy of packages.
+.RE
+.LP
+.B MAKEFLAGS
+.RS 5
+Set default flags to make; e.g., -k to build all targets regardless of errors.
+.RE
+.LP
+.B UT_NO_USAGE_TRACKING
+.RS 5
+Disables usage reporting by listed Devpro tools. Otherwise it sends mail
+to some Devpro machine every time the tools are used.
+.RE
+.LP
+.B LINTDIRS
+.RS 5
+Directories to lint with the \-l option.
+.RE
+.LP
+.B BUILD_TOOLS
+.RS 5
+BUILD_TOOLS is the root of all tools including the compilers; e.g.,
+/ws/onnv-tools.  It is used by the makefile system, but not nightly.
+.RE
+.LP
+.B ONBLD_TOOLS
+.RS 5
+ONBLD_TOOLS is the root of all the tools that are part of SUNWonbld; e.g.,
+/ws/onnv-tools/onbld.  By default, it is derived from
+.BR BUILD_TOOLS .
+It is used by the makefile system, but not nightly.
+.RE
+.LP
+.B SPRO_ROOT
+.RS 5
+The gate-defined default location for the Sun compilers, e.g.
+/ws/onnv-tools/SUNWspro.  By default, it is derived from
+.BR BUILD_TOOLS .
+It is used by the makefile system, but not nightly.
+.RE
+.LP
+.B JAVA_ROOT
+.RS 5
+The location for the java compilers for the build, generally /usr/java.
+.RE
+.LP
+.B OPTHOME
+.RS 5
+The gate-defined default location of things formerly in /opt; e.g.,
+/ws/onnv-tools.  This is used by nightly, but not the makefiles.
+.RE
+.LP
+.B TEAMWARE
+.RS 5
+The gate-defined default location for the Teamware tools; e.g.,
+/ws/onnv-tools/SUNWspro.  By default, it is derived from
+.BR OPTHOME .
+This is used by nightly, but not the makefiles.  There is no
+corresponding variable for Mercurial or Subversion, which are assumed
+to be installed in the default path.
+.RE
+.LP
+.B ON_CLOSED_BINS
+.RS 5
+OpenSolaris builds do not contain the closed source tree.  Instead,
+the developer downloads a closed binaries tree and unpacks it.  
+.B ON_CLOSED_BINS
+tells nightly
+where to find these closed binaries, so that it can add them into the
+build.
+.RE
+.LP
+.B CHECK_PATHS
+.RS 5
+Normally, nightly runs the 'checkpaths' script to check for
+discrepancies among the files that list paths to other files, such as
+exception lists and req.flg.  Set this flag to 'n' to disable this
+check, which appears in the nightly output as "Check lists of files."
+.RE
+.LP
+.B CHECK_DMAKE
+.RS 5
+Nightly validates that the version of dmake encountered is known to be
+safe to use.  Set this flag to 'n' to disable this test, allowing any
+version of dmake to be used.
+.RE
+.LP
+.B MULTI_PROTO
+.RS 5
+If "no" (the default), 
+.I nightly
+will reuse $ROOT for both the DEBUG and non-DEBUG builds.  If "yes",
+the DEBUG build will go in $ROOT and the non-DEBUG build will go in
+$ROOT-nd.  Other values will be treated as "no".
+.RE
+.LP
+.SH NIGHTLY HOOK ENVIRONMENT VARIABLES
+.LP
+Several optional environment variables may specify commands to run at
+various points during the build.  Commands specified in the hook
+variable will be run in a subshell; command output will be appended to
+the mail message and log file.  If the hook exits with a non-zero
+status, the build is aborted immediately.  Environment variables
+defined in the environment file will be available.
+.LP
+.B SYS_PRE_NIGHTLY
+.RS 5
+Run just after the workspace lock is acquired.  This is reserved for
+per-build-machine customizations and should be set only in /etc/nightly.conf
+.RE
+.LP
+.B PRE_NIGHTLY
+.RS 5
+Run just after SYS_PRE_NIGHTLY.
+.RE
+.LP
+.B PRE_BRINGOVER
+.RS 5
+Run just before bringover is started; not run if no bringover is done.
+.RE
+.LP
+.B POST_BRINGOVER
+.RS 5
+Run just after bringover completes; not run if no bringover is done.
+.RE
+.LP
+.B POST_NIGHTLY
+.RS 5
+Run after the build completes, with the return status of nightly - one
+of "Completed", "Interrupted", or "Failed" - available in the
+environment variable NIGHTLY_STATUS.
+.RE
+.LP
+.B SYS_POST_NIGHTLY
+.RS 5
+This is reserved for per-build-machine customizations, and runs
+immedately after POST_NIGHTLY.
+.RE
+.LP
+.SH FILES
+.LP
+.RS 5
+/etc/nightly.conf
+.RE
+.LP
+If present, nightly executes this file just prior to executing the
+.I env
+file.  
+.SH EXAMPLES
+.LP
+Start with the example file in usr/src/tools/env/developer.sh
+(or gatekeeper.sh), copy to myenv and make your changes.
+.LP
+.PD 0
+# grep NIGHTLY_OPTIONS myenv
+.LP
+NIGHTLY_OPTIONS="-ACrlapDm"
+.LP
+export NIGHTLY_OPTIONS
+.LP
+# /opt/onbld/bin/nightly -i myenv
+.PD
+.LP
+.SH SEE ALSO
+.BR bldenv (1ONBLD)
--- old/usr/src/tools/scripts/onu.1	Wed Sep 30 19:35:41 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,190 +0,0 @@
-.\" " CDDL HEADER START
-.\" "
-.\" " The contents of this file are subject to the terms of the
-.\" " Common Development and Distribution License (the "License").
-.\" " You may not use this file except in compliance with the License.
-.\" "
-.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" " or http://www.opensolaris.org/os/licensing.
-.\" " See the License for the specific language governing permissions
-.\" " and limitations under the License.
-.\" "
-.\" " When distributing Covered Code, include this CDDL HEADER in each
-.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" " If applicable, add the following below this CDDL HEADER, with the
-.\" " fields enclosed by brackets "[]" replaced with your own identifying
-.\" " information: Portions Copyright [yyyy] [name of copyright owner]
-.\" "
-.\" " CDDL HEADER END
-.\" "
-.\" "Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
-.\" "Copyright 2010, Richard Lowe
-.\" "
-.TH onu 1 "28 August 2010"
-.SH NAME
-.I onu
-\- OS/Net Update
-.SH SYNOPSIS
-\fBonu [opts] [-s <beName>] -t <beName>\fP
-.br
-\fBonu [opts] -r\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "onu" "" "\fBonu\fP"
-.LP
-.I onu 
-is a replacement for
-.I bfu
-used to update a system with the latest set of IPS packages for the ON
-(OS/Net) consolidation of Solaris, using beadm(1M) to create a new Boot
-Environment (BE) and pkg(1) to update the image.
-.SH OPTIONS
-.LP
-The following global options are supported:
-.TP 4
-.B \-c <consolidation>
-Specifies the consolidation being installed via 
-.IR onu ,
-used to locate the publisher from which that consolidation is currently
-installed.  This is almost always "osnet".
-.TP 4
-.B \-d <dir>
-Specifies that <dir> contains the repo.redist sub-directory;
-.I onu
-will run a depot using this packaging repository.
-Note that -d ignores -u and -U as well
-as the environment variables used by those options.
-.TP 4
-.B \-u <URI>
-Specifies that <URI> should be used as the origin URI for the publisher
-packaging repository.  See \fBONURI\fP below for default values.
-.TP 4
-.B \-U <publisher>
-Specifies that <publisher> should be used as the publisher name for
-the packaging repository.  See \fBONPUB\fP below for default values.
-.TP 4
-.B \-v
-Verbose mode.
-.LP
-The first form of onu creates a new BE and then updates it, and takes
-the following options:
-.TP 4
-.B \-s <beName>
-Specifies that <beName> should be used as the source Boot Environment to
-clone.  The default is the active BE.
-.TP 4
-.B \-t <beName>
-Specifies the target BE name.  This argument is required; there
-is no default value.
-.TP 4
-.B \-Z
-Do not update any installed zones.
-.LP
-The second form of onu takes the following option:
-.TP 4
-.B \-r
-In the current BE configure the requested publisher appropriately, without
-updating.
-.SH EXIT STATUS
-.LP
-The following exit values are returned:
-.TP 4
-.B 0
-The command completed successfully.
-No errors or warnings were reported.
-.LP
-.TP 4
-.B 1
-Incorrect usage.
-.LP
-.TP 4
-.B 2
-One of the commands used by the script failed.
-.SH NOTES
-.LP
-Former users of bfu should note the following ways in which onu behaves
-differently from bfu.  First, as noted above, onu creates a new BE, rather
-than updating an existing BE in-place.  Second, onu will not install packages
-that are older than what is already installed in the source BE.  Third,
-conflicts in system configuration files are automatically resolved according
-to the files' "preserve" attribute, as described in pkg(5).
-.LP
-If the
-.B -d
-option is given to specify a repository directory, the new
-publishers will not be available in the new BE. This can prevent correct
-zone installs or cause issues with installing additional packages
-sourced from the ON repositories. In both cases, the \fB-r\fR option
-can be used in the new BE to re-enable the publishers. See
-\fBEXAMPLES\fR.
-.LP
-Use of
-.I onu
-will prevent use of zone attach for ipkg-brand zones in the new BE,
-since the
-.B entire
-incorporation is removed.
-.LP
-By default,
-.I onu
-will attempt to update any ipkg-brand installed zones on the system; the
-.B -Z
-option may be used to disable this behavior.
-.SH EXAMPLES
-.LP
-\fBExample 1\fR Installing latest ON nightly build
-.LP
-.SP
-.IN +2
-.NF
-# onu -t new-nightly-be
-.FI
-.IN -2
-.SP
-.LP
-\fBExample 2\fR Installing an ON build from a directory
-.LP
-.SP
-.IN +2
-.NF
-# onu -d /path/to/my/ws/packages/`uname -p`/nightly -t new-nightly-be
-.FI
-.IN -2
-.SP
-.LP
-\fBExample 3\fR Installing additional packages in the new BE
-.LP
-.SP
-.IN +2
-.NF
-# onu -d /path/to/my/ws/packages/`uname -p`/nightly -t new-nightly-be
-.br
-# reboot
-.br
-# onu -r -d /path/to/my/ws/packages/`uname -p`/nightly
-.br
-# pkg install netcat
-.br
-#
-.FI
-.IN -2
-.SP
-.SH ENVIRONMENT
-.LP
-ONURI
-.IP
-If the -u option is not provided, and this variable is set, it will be used
-as the origin URI for the publisher packaging repository.  If -u is not
-provided and this variable is not set, http://ipkg.sfbay/on-nightly will
-be used.
-.LP
-ONPUB
-.IP
-If the -U option is not provided, and this variable is set, it will be
-used as the publisher name for the packaging repository.  If -U is not
-provided and this variable is not set, on-nightly will be used.
-.LP
-.SH SEE ALSO
-.BR beadm "(1M), "
-.BR pkg "(1), "
-.BR pkg "(5) "
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/onu.1onbld	Wed Sep 30 19:35:41 2015
@@ -0,0 +1,190 @@
+.\" " CDDL HEADER START
+.\" "
+.\" " The contents of this file are subject to the terms of the
+.\" " Common Development and Distribution License (the "License").
+.\" " You may not use this file except in compliance with the License.
+.\" "
+.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" " or http://www.opensolaris.org/os/licensing.
+.\" " See the License for the specific language governing permissions
+.\" " and limitations under the License.
+.\" "
+.\" " When distributing Covered Code, include this CDDL HEADER in each
+.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" " If applicable, add the following below this CDDL HEADER, with the
+.\" " fields enclosed by brackets "[]" replaced with your own identifying
+.\" " information: Portions Copyright [yyyy] [name of copyright owner]
+.\" "
+.\" " CDDL HEADER END
+.\" "
+.\" "Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
+.\" "Copyright 2010, Richard Lowe
+.\" "
+.TH onu 1ONBLD "28 August 2010"
+.SH NAME
+.I onu
+\- OS/Net Update
+.SH SYNOPSIS
+\fBonu [opts] [-s <beName>] -t <beName>\fP
+.br
+\fBonu [opts] -r\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "onu" "" "\fBonu\fP"
+.LP
+.I onu 
+is a replacement for
+.I bfu
+used to update a system with the latest set of IPS packages for the ON
+(OS/Net) consolidation of Solaris, using beadm(1M) to create a new Boot
+Environment (BE) and pkg(1) to update the image.
+.SH OPTIONS
+.LP
+The following global options are supported:
+.TP 4
+.B \-c <consolidation>
+Specifies the consolidation being installed via 
+.IR onu ,
+used to locate the publisher from which that consolidation is currently
+installed.  This is almost always "osnet".
+.TP 4
+.B \-d <dir>
+Specifies that <dir> contains the repo.redist sub-directory;
+.I onu
+will run a depot using this packaging repository.
+Note that -d ignores -u and -U as well
+as the environment variables used by those options.
+.TP 4
+.B \-u <URI>
+Specifies that <URI> should be used as the origin URI for the publisher
+packaging repository.  See \fBONURI\fP below for default values.
+.TP 4
+.B \-U <publisher>
+Specifies that <publisher> should be used as the publisher name for
+the packaging repository.  See \fBONPUB\fP below for default values.
+.TP 4
+.B \-v
+Verbose mode.
+.LP
+The first form of onu creates a new BE and then updates it, and takes
+the following options:
+.TP 4
+.B \-s <beName>
+Specifies that <beName> should be used as the source Boot Environment to
+clone.  The default is the active BE.
+.TP 4
+.B \-t <beName>
+Specifies the target BE name.  This argument is required; there
+is no default value.
+.TP 4
+.B \-Z
+Do not update any installed zones.
+.LP
+The second form of onu takes the following option:
+.TP 4
+.B \-r
+In the current BE configure the requested publisher appropriately, without
+updating.
+.SH EXIT STATUS
+.LP
+The following exit values are returned:
+.TP 4
+.B 0
+The command completed successfully.
+No errors or warnings were reported.
+.LP
+.TP 4
+.B 1
+Incorrect usage.
+.LP
+.TP 4
+.B 2
+One of the commands used by the script failed.
+.SH NOTES
+.LP
+Former users of bfu should note the following ways in which onu behaves
+differently from bfu.  First, as noted above, onu creates a new BE, rather
+than updating an existing BE in-place.  Second, onu will not install packages
+that are older than what is already installed in the source BE.  Third,
+conflicts in system configuration files are automatically resolved according
+to the files' "preserve" attribute, as described in pkg(5).
+.LP
+If the
+.B -d
+option is given to specify a repository directory, the new
+publishers will not be available in the new BE. This can prevent correct
+zone installs or cause issues with installing additional packages
+sourced from the ON repositories. In both cases, the \fB-r\fR option
+can be used in the new BE to re-enable the publishers. See
+\fBEXAMPLES\fR.
+.LP
+Use of
+.I onu
+will prevent use of zone attach for ipkg-brand zones in the new BE,
+since the
+.B entire
+incorporation is removed.
+.LP
+By default,
+.I onu
+will attempt to update any ipkg-brand installed zones on the system; the
+.B -Z
+option may be used to disable this behavior.
+.SH EXAMPLES
+.LP
+\fBExample 1\fR Installing latest ON nightly build
+.LP
+.SP
+.IN +2
+.NF
+# onu -t new-nightly-be
+.FI
+.IN -2
+.SP
+.LP
+\fBExample 2\fR Installing an ON build from a directory
+.LP
+.SP
+.IN +2
+.NF
+# onu -d /path/to/my/ws/packages/`uname -p`/nightly -t new-nightly-be
+.FI
+.IN -2
+.SP
+.LP
+\fBExample 3\fR Installing additional packages in the new BE
+.LP
+.SP
+.IN +2
+.NF
+# onu -d /path/to/my/ws/packages/`uname -p`/nightly -t new-nightly-be
+.br
+# reboot
+.br
+# onu -r -d /path/to/my/ws/packages/`uname -p`/nightly
+.br
+# pkg install netcat
+.br
+#
+.FI
+.IN -2
+.SP
+.SH ENVIRONMENT
+.LP
+ONURI
+.IP
+If the -u option is not provided, and this variable is set, it will be used
+as the origin URI for the publisher packaging repository.  If -u is not
+provided and this variable is not set, http://ipkg.sfbay/on-nightly will
+be used.
+.LP
+ONPUB
+.IP
+If the -U option is not provided, and this variable is set, it will be
+used as the publisher name for the packaging repository.  If -U is not
+provided and this variable is not set, on-nightly will be used.
+.LP
+.SH SEE ALSO
+.BR beadm "(1M), "
+.BR pkg "(1), "
+.BR pkg "(5) "
--- old/usr/src/tools/scripts/sccscheck.1	Wed Sep 30 19:35:41 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,62 +0,0 @@
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.\" ident	"%Z%%M%	%I%	%E% SMI"
-.\"
-.TH sccscheck 1 "7 April 2006"
-.SH NAME
-.I sccscheck
-\- 
-.SH SYNOPSIS
-.B sccscheck
-filename
-.SH DESCRIPTION
-The standard solaris 
-.I make(1)
-is SCCS-aware, automatically checking out files if they are out of
-date with respect to the SCCS file; however, this is of little value
-in the context of teamware and of no value if a non-SCCS SCM system is
-used, and can lead to hard-to-diagnose build failures  in the presence
-of recursive parallel make.
-The
-.I sccscheck
-script is used from the OS/Net Makefile.master file as a substitute
-for make(1)'s default handling of SCCS files; it generates errors
-preceded by "sccscheck: error", and warnings preceded by "sccscheck:
-warning".
-
-By default an out-of-date source file is treated as a non-event, and the
-build continues onward; in most cases this will avoid unnecessary
-rebuilds of other targets depending on the out-of-date source file.
-.SH ENVIRONMENT
-If set to a non-empty string, SCCSCHECK_WARN will cause sccscheck to
-emit a verbose warning when an out-of-date source file is encountered;
-the build will continue but the resulting build logs will be large.
-
-If set to a non-empty string, SCCSCHECK_FAIL will cause sccscheck
-to treat out-of-date source files as an error rather than a
-warning.
-
-If both are set, behavior will be as if only SCCSCHECK_FAIL is set.
-
-
-
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/sccscheck.1onbld	Wed Sep 30 19:35:41 2015
@@ -0,0 +1,60 @@
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.TH sccscheck 1ONBLD "7 April 2006"
+.SH NAME
+.I sccscheck
+\- 
+.SH SYNOPSIS
+.B sccscheck
+filename
+.SH DESCRIPTION
+The standard solaris 
+.I make(1)
+is SCCS-aware, automatically checking out files if they are out of
+date with respect to the SCCS file; however, this is of little value
+in the context of teamware and of no value if a non-SCCS SCM system is
+used, and can lead to hard-to-diagnose build failures  in the presence
+of recursive parallel make.
+The
+.I sccscheck
+script is used from the OS/Net Makefile.master file as a substitute
+for make(1)'s default handling of SCCS files; it generates errors
+preceded by "sccscheck: error", and warnings preceded by "sccscheck:
+warning".
+
+By default an out-of-date source file is treated as a non-event, and the
+build continues onward; in most cases this will avoid unnecessary
+rebuilds of other targets depending on the out-of-date source file.
+.SH ENVIRONMENT
+If set to a non-empty string, SCCSCHECK_WARN will cause sccscheck to
+emit a verbose warning when an out-of-date source file is encountered;
+the build will continue but the resulting build logs will be large.
+
+If set to a non-empty string, SCCSCHECK_FAIL will cause sccscheck
+to treat out-of-date source files as an error rather than a
+warning.
+
+If both are set, behavior will be as if only SCCSCHECK_FAIL is set.
+
+
+
--- old/usr/src/tools/scripts/webrev.1	Wed Sep 30 19:35:41 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,450 +0,0 @@
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2010 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.\"
-.TH webrev 1 "7 Feb 2014"
-.SH NAME
-webrev \- Generate HTML codereview materials
-.SH SYNOPSIS
-.B webrev
-[
-.I common-options
-]
-
-.B webrev
-[
-.I common-options
-]
-.I file-list-file
-|
-.I -
-
-.B webrev
-[
-.I common-options
-]
-.B -w
-.I wx-file
-
-.SH DESCRIPTION
-.B webrev
-builds a set of HTML files suitable for performing code review of
-source changes in a web browser.
-It supports Mercurial, Git and Subversion repositories.
-At its most basic, usage is:
-.nf
-        $ webrev
-.fi
-
-In which case \fBwebrev\fR attempts to figure out the list of files
-for review.  If that fails, or if more control
-over the set of files is needed, a \fIfile list\fR may be specified.
-\fBwebrev\fR also attempts to deduce a
-.I basis for comparison
-(interchangeably called the \fIparent\fR, but see SCM INTERACTIONS below).
-A basis for comparison is needed in order to determine the differences
-introduced by the code changes under review.
-
-By default, \fBwebrev\fR creates a \fIwebrev\fR directory in the
-workspace directory that contains the generated HTML files, a generated
-PDF review, and a patch representing the changes.  It also places a
-copy of the file list in that directory, and of both the old and new
-raw files in the \fB$webrev_root/raw_files\fR directory.
-To output the webrev somewhere other than the default location, use the
-\fI-o <outdir>\fR option, or set the \fBWDIR\fR environment variable.
-For example:
-.nf
-        $ webrev -o ~/public_html/myreview/
-.fi
-.PP
-In the index file, each file is listed on a line with a link to the
-relevant review materials.  Comments for each change will be included
-automatically.  Cross references to bug (or other information) tracking
-databases in the comments will become hyperlinks in the associated web
-interface, according to the rules in CROSS REFERENCING below.
-
-As a review aid, content may be added to the \fIindex\fR file in two ways.
-First, the author may manually edit the file (for example by including
-text that explains the changes in front of the links for each file).
-Note that if webrev is run again, manual edits will be lost.  Second,
-if a file named \fIwebrev-info\fR is present at the root of the workspace,
-it will be automatically included in the \fIindex\fR file.  To include a
-different file, see the \fI-i\fR option.
-
-For each file in the file list, \fBwebrev\fR compares the file with the
-version in the basis for comparison (i.e. the parent workspace) and
-generates a variety of HTML renderings of the differences between
-the two files; which of these renderings to use is largely a matter
-of personal preference.  Additional, webrev emits a patch, the old
-and new versions of the file, and a "raw" copy of the file which is
-suitable for download.  For files which express differences, source
-is formatted according to the following color coding:
-.IP
-.nf
-     unchanged : black
-       removed : brown
-       changed : blue
-           new : bold blue
-.fi
-
-.SH SCM INTERACTIONS
-.PP
-.B webrev
-attempts to interact with the source code management system currently in use.  
-.B webrev
-needs to be able locate the code under review (i.e. the workspace) and
-the basis for comparison (i.e. the parent).  The method for doing so
-depends upon the SCM in use, which
-.B webrev
-will also attempt to auto-discover.  In all cases,
-.B webrev
-must either discover the list of files which have changed, or else this list
-must be manually specified, either in "webrev file list" format or in "wx"
-format.
-See FILE LIST for more details.
-.PP
-In all cases, if the user has activated the workspace with the
-.BR ws (1)
-or
-.BR bldenv (1)
-commands, \fBwebrev\fR will use the \fBCODEMGR_PARENT\fR and
-\fBCODEMGR_WS\fR environment variables to identify parent and child
-workspaces respectively.
-To manually specify the basis for comparison, use the -p option or
-specify the \fBCODEMGR_PARENT\fR variable in either the file list or
-the environment.
-
-.SS Discovering the SCM in use.
-.B webrev
-makes use of
-.BR which_scm (1)
-to determine the SCM in use for a given workspace.
-
-.SS Mercurial
-In the case of Mercurial \fBwebrev\fR will attempt to use the output
-from the
-.BR hg (1)
-"hg root" command to identify the workspace root, and the
-"hg path default" command to identify the parent workspace.
-
-.SS Git
-In the case of Git \fBwebrev\fR will attempt to use the output from the
-.BR git (1)
-"git rev-parse --git-dir" command to identify the workspace root, and will
-attempt to use the remote branch which the current branch is tracking as the
-parent, if none is specified 'origin/master' will be used.
-
-The parent specified when using git is, in all cases, a git 'tree-ish' and
-never an actual git repository, remote or otherwise.  Anything specifiable to
-git as a tree-ish should, similarly, be specifiable as a parent for webrev.
-This includes branches, explicit revisions, reflog entries, etc. See
-.BR git-rev-parse (1)
-
-.SS Subversion
-In the case of Subversion \fBwebrev\fR will attempt to use the output
-from the
-.BR svn (1)
-"svn info" to find the workspace root and subversion repository URL.
-.PP
-The file list will be created from the output of the "svn status" command.
-
-.SH CROSS REFERENCING
-.PP
-After extracting comments (see FILE LIST below),
-.B webrev
-will translate cross references into hyperlinks.  By default, information
-about available information tracking systems can be found in
-/opt/onbld/etc/its.reg, and the specification of a local domain and
-selection and prioritization of systems
-in /opt/onbld/etc/its.conf.  These file formats are self documenting.  Also
-see the -I and -C options below.
-.SH OPTIONS
-.TP 10
-.BI "-C " priority-file
-In addition to the system default and an optional user-supplied ~/.its.conf,
-use the specified file to specify a local domain list and prioritize the list
-of information tracking systems to be searched automatically when resolving cross
-references.
-.TP 10
-.BI "-D"
-Delete remote webrev via SFTP. Default remote host is \fIcr.opensolaris.org\fR,
-default remote directory for removal is the same as workspace/repository
-basename. Remote target can be overriden using -t option. If combined with
--U the deletion will be performed first. Also, if used together with -U
-and the removal fails, no upload is done. Without -U option no webrev will
-be generated, just like if -n option was used. The deletion is done by
-moving the webrev to special directory in user's home directory. It is
-expected that the remote host periodically runs a script which deletes
-the contents of this directory. See the ENVIRONMENT VARIABLES section for
-more details about this directory.
-.TP 10
-.BI "-I " information-file
-Use the specified file to seed the list of information tracking systems.
-.TP 10
-.BI "-i " include-file
-Include the specified file into the index.html file which is generated
-as part of the webrev.  This allows a snippet of XHTML to be added by
-the webrev author. User content is contained by a <div> tag and
-the markup should validate as XHTML 1.0 Transitional.
-.TP 10
-.BI "-N"
-Suppress all comments from all output forms html, txt and pdf.
-.TP 10
-.BI "-n"
-Do not generate webrev. Useful whenever only upload is needed.
-.TP 10
-.B -O
-Enable \fIOpenSolaris\fR mode: information tracking system hyperlinks
-are generated using the EXTERNAL_URL field from the specified its.reg entry,
-instead of the default INTERNAL_URL_domain field, and sources which appear in
-\fIusr/closed\fR are automatically elided from the review.
-.TP 10
-.BI "-o " output-dir
-Place output from running the script in the directory specified.  If
-specified, this option takes precedence over the WDIR environment variable.
-.TP 10
-.BI "-p " basis-of-comparison
-Specify a basis of comparison meaningful for the SCM currently in use.
-See SCM INTERACTIONS and INCREMENTAL REVIEWS.
-.TP 10
-.BI "-t " target
-Upload target. Specified in form of URI identifier. For SCP/SFTP it is
-\fIssh://user@remote_host:remote_dir\fR and for rsync it is
-\fIrsync://user@remote_host:remote_dir\fR. This option can override the
--o option if the URI is fully specified. The target is relative to
-the top level directory of the default sftp/rsync directory tree.
-.TP 10
-.BI "-U"
-Upload the webrev. Default remote host is \fIcr.opensolaris.org\fR.
-Default transport is rsync. If it fails, fallback to SCP/SFTP transport
-is done.
-.TP 10
-.BI "-w " wx-file
-Extract the file list from the wx "active" file specified.  'wx' uses
-this mode when invoking webrev.  The list is assumed to be in the
-format expected by the \fIwx\fR package.  See FILE LIST, below.
-
-.SH FILE LIST
-.PP
-.B Webrev
-needs to be told or to discover which files have changed in a
-given workspace.  By default,
-.B webrev
-will attempt to autodetect the
-list of changed files by first consulting 
-.BR wx "(1)."
-If this information is not available, webrev tries to consult the SCM (Source
-Code Manager) currently in use.  If that fails, the user must intervene by
-specifying either a file list or additional options specific to the SCM in use.
-
-.SS Webrev Format
-A webrev formatted file list contains a list of all the files to
-be included in the review with paths relative to the workspace
-directory, e.g.
-.IP
-.nf
-\f(CWusr/src/uts/common/fs/nfs/nfs_subr.c
-usr/src/uts/common/fs/nfs/nfs_export.c
-usr/src/cmd/fs.d/nfs/mountd/mountd.c
-.fi
-.PP
-Include the paths of any files added, deleted, or modified.
-You can keep this list of files in the webrev directory
-that webrev creates in the workspace directory
-(CODEMGR_WS).
-
-If CODEMGR_WS is not set, it may be specified as an environment variable
-within the file list, e.g.
-.IP
-.nf
-\f(CWCODEMGR_WS=/home/brent/myws
-usr/src/uts/common/fs/nfs/nfs_subr.c
-usr/src/uts/common/fs/nfs/nfs_export.c
-usr/src/cmd/fs.d/nfs/mountd/mountd.c
-.fi
-.PP
-To compare the workspace against one other than the parent (see also
-the -p option), include a CODEMGR_PARENT line in the file list, like:
-.IP
-.nf
-\f(CWCODEMGR_WS=/home/brent/myws
-CODEMGR_PARENT=/ws/onnv-gate
-usr/src/uts/common/fs/nfs/nfs_subr.c
-usr/src/uts/common/fs/nfs/nfs_export.c
-usr/src/cmd/fs.d/nfs/mountd/mountd.c
-.fi
-.PP
-Finally, run webrev with the name of the file containing the file list as an
-argument, e.g.
-.nf
-        $ webrev file.list
-.fi
-.PP
-If "-" is supplied as the name of the file, then stdin will be used.
-
-.SS wx Format
-If the \fI-w\fR flag is specified then \fBwebrev\fR
-will assume the file list is in the format expected by the "wx" package:
-pathname lines alternating with SCCS comment lines separated by blank
-lines, e.g.
-.IP
-.nf
-\f(CWusr/src/uts/common/fs/nfs/nfs_subr.c
-
-1206578 Fix spelling error in comment
-
-usr/src/uts/common/fs/nfs/nfs_export.c
-
-4039272 cstyle fixes
-
-usr/src/cmd/fs.d/nfs/mountd/mountd.c
-
-1927634 mountd daemon doesn't handle expletives
-.fi
-
-.SH INCREMENTAL REVIEWS
-When conducting multiple rounds of code review, it may be desirable to
-generate a webrev which represents the delta between reviews.  In this
-case, set the parent workspace to the path to the old webrev:
-
-.IP
-.nf
-\f(CW$ webrev -o ~/public_html/myreview-rd2/ \\
-         -p ~/public_html/myreview/
-.fi
-
-.SH ENVIRONMENT VARIABLES
-The following environment variables allow for customization of \fBwebrev\fR:
-
-.PP
-\fBCDIFFCMD\fR and \fBUDIFFCMD\fR are used when generating Cdiffs and Udiffs
-respectively; their default values are "diff -b -C 5" and "diff -b -U
-5".  To generate diffs with more (or less) than 5 lines of context or
-with more (or less) strict whitespace handling, set one or both of
-these variables in the user environment accordingly.
-
-\fBWDIR\fR sets the output directory.  It is functionally equivalent to
-the \fI-o\fR option.
-
-\fBWDIFF\fR specifies the command used to generate Wdiffs. Wdiff generates a
-full unified context listing with line numbers where unchanged
-sections of code may be expanded and collapsed.  It also provides a
-"split" feature that shows the same file in two HTML frames one above the
-other.  The default path for this script is
-/ws/onnv-gate/public/bin/wdiff but WDIFF may be set to customize this
-to use a more convenient location.
-
-\fBWEBREV_TRASH_DIR\fR specifies alternative location of trash directory
-for remote webrev deletion using the \fI-D\fR option. The directory is
-relative to the top level directory of the default sftp/rsync directory tree.
-The default value of this directory is ".trash".
-
-.SH UPLOADING WEBREVS
-A webrev can be uploaded to remote site using the -U option. To simply
-generate new webrev and upload it to the default remote host use the following
-command:
-.IP
-.nf
-\f(CW$ webrev -U
-.fi
-.PP
-This will generate the webrev to local directory named 'webrev' and upload it
-to remote host with remote directory name equal to local workspace/repository
-name. To change both local and remote directory name, -U can be combined with
--o option. The following command will store the webrev to local directory named
-"foo.onnv" and upload it to the remote host with the same directory name:
-.IP
-.nf
-\f(CW$ webrev -U -o $CODEMGR_WS/foo.onnv
-.fi
-.PP
-If there is a need for manual change of the webrev before uploading,
--U can be combined with -n option so that first command will just generate
-the webrev and the second command will upload it without generating it again:
-.IP
-.nf
-\f(CW$ webrev
-\f(CW$ webrev -n -U
-.fi
-.PP
-For custom remote targets, -t option allows to specify all components:
-.IP
-.nf
-\f(CW$ webrev -U -t \\
-	ssh://user@cr.opensolaris.org:foo/bar/bugfix.onnv
-.fi
-.PP
-If the remote path is specified as absolute, \fBwebrev\fR will assume all the
-directories are already created. If the path is relative, \fBwebrev\fR will
-try to create all needed directories. This only works with SCP/SFTP transport.
-.PP
-By default, rsync transport will use SSH for transferring the data to remote
-site. To specify custom username, use entry in SSH client configuration file,
-for example:
-.IP
-.nf
-\f(CWHost cr.opensolaris.org
-  Hostname cr.opensolaris.org
-  User vkotal
-.fi
-
-.SH DELETING WEBREVS
-When deleting a webrev directory on remote site which has a different name
-than the basename of local repository it is necessary to specify the output
-option:
-.IP
-.nf
-\f(CW$ webrev -Do webrev-foo.onnv
-.fi
-.PP
-Otherwise \fBwebrev\fR will attempt to remove remote directory with the same
-name as basename of the local repository.
-.PP
-For the nested directory case it is necessary to specify the full target:
-.IP
-.nf
-\f(CW$ webrev -D -t \\
-	ssh://user@cr.opensolaris.org:foo/bar/bugfix.onnv
-.fi
-.PP
-This will remove just the \fIbugfix.onnv\fR directory.
-
-.SH SEE ALSO
-.BR hg "(1),"
-.BR git "(1),"
-.BR ssh_config "(4),"
-.BR svn "(1),"
-.BR which_scm "(1)"
-
-.SH ACKNOWLEDGEMENTS
-Acknowledgements to Rob Thurlow, Mike Eisler, Lin Ling,
-Rod Evans, Mike Kupfer, Greg Onufer, Glenn Skinner,
-Oleg Larin, David Robinson, Matthew Cross, David L. Paktor,
-Neal Gafter, John Beck, Darren Moffat, Norm Shulman, Bill Watson,
-Pedro Rubio and Bill Shannon for valuable feedback and insight in
-building webrev.
-
-Have fun!
-.br
-		Brent Callaghan  11/28/96
-
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/webrev.1onbld	Wed Sep 30 19:35:41 2015
@@ -0,0 +1,450 @@
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2010 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.\"
+.TH webrev 1ONBLD "7 Feb 2014"
+.SH NAME
+webrev \- Generate HTML codereview materials
+.SH SYNOPSIS
+.B webrev
+[
+.I common-options
+]
+
+.B webrev
+[
+.I common-options
+]
+.I file-list-file
+|
+.I -
+
+.B webrev
+[
+.I common-options
+]
+.B -w
+.I wx-file
+
+.SH DESCRIPTION
+.B webrev
+builds a set of HTML files suitable for performing code review of
+source changes in a web browser.
+It supports Mercurial, Git and Subversion repositories.
+At its most basic, usage is:
+.nf
+        $ webrev
+.fi
+
+In which case \fBwebrev\fR attempts to figure out the list of files
+for review.  If that fails, or if more control
+over the set of files is needed, a \fIfile list\fR may be specified.
+\fBwebrev\fR also attempts to deduce a
+.I basis for comparison
+(interchangeably called the \fIparent\fR, but see SCM INTERACTIONS below).
+A basis for comparison is needed in order to determine the differences
+introduced by the code changes under review.
+
+By default, \fBwebrev\fR creates a \fIwebrev\fR directory in the
+workspace directory that contains the generated HTML files, a generated
+PDF review, and a patch representing the changes.  It also places a
+copy of the file list in that directory, and of both the old and new
+raw files in the \fB$webrev_root/raw_files\fR directory.
+To output the webrev somewhere other than the default location, use the
+\fI-o <outdir>\fR option, or set the \fBWDIR\fR environment variable.
+For example:
+.nf
+        $ webrev -o ~/public_html/myreview/
+.fi
+.PP
+In the index file, each file is listed on a line with a link to the
+relevant review materials.  Comments for each change will be included
+automatically.  Cross references to bug (or other information) tracking
+databases in the comments will become hyperlinks in the associated web
+interface, according to the rules in CROSS REFERENCING below.
+
+As a review aid, content may be added to the \fIindex\fR file in two ways.
+First, the author may manually edit the file (for example by including
+text that explains the changes in front of the links for each file).
+Note that if webrev is run again, manual edits will be lost.  Second,
+if a file named \fIwebrev-info\fR is present at the root of the workspace,
+it will be automatically included in the \fIindex\fR file.  To include a
+different file, see the \fI-i\fR option.
+
+For each file in the file list, \fBwebrev\fR compares the file with the
+version in the basis for comparison (i.e. the parent workspace) and
+generates a variety of HTML renderings of the differences between
+the two files; which of these renderings to use is largely a matter
+of personal preference.  Additional, webrev emits a patch, the old
+and new versions of the file, and a "raw" copy of the file which is
+suitable for download.  For files which express differences, source
+is formatted according to the following color coding:
+.IP
+.nf
+     unchanged : black
+       removed : brown
+       changed : blue
+           new : bold blue
+.fi
+
+.SH SCM INTERACTIONS
+.PP
+.B webrev
+attempts to interact with the source code management system currently in use.  
+.B webrev
+needs to be able locate the code under review (i.e. the workspace) and
+the basis for comparison (i.e. the parent).  The method for doing so
+depends upon the SCM in use, which
+.B webrev
+will also attempt to auto-discover.  In all cases,
+.B webrev
+must either discover the list of files which have changed, or else this list
+must be manually specified, either in "webrev file list" format or in "wx"
+format.
+See FILE LIST for more details.
+.PP
+In all cases, if the user has activated the workspace with the
+.BR ws (1ONBLD)
+or
+.BR bldenv (1ONBLD)
+commands, \fBwebrev\fR will use the \fBCODEMGR_PARENT\fR and
+\fBCODEMGR_WS\fR environment variables to identify parent and child
+workspaces respectively.
+To manually specify the basis for comparison, use the -p option or
+specify the \fBCODEMGR_PARENT\fR variable in either the file list or
+the environment.
+
+.SS Discovering the SCM in use.
+.B webrev
+makes use of
+.BR which_scm (1ONBLD)
+to determine the SCM in use for a given workspace.
+
+.SS Mercurial
+In the case of Mercurial \fBwebrev\fR will attempt to use the output
+from the
+.BR hg (1)
+"hg root" command to identify the workspace root, and the
+"hg path default" command to identify the parent workspace.
+
+.SS Git
+In the case of Git \fBwebrev\fR will attempt to use the output from the
+.BR git (1)
+"git rev-parse --git-dir" command to identify the workspace root, and will
+attempt to use the remote branch which the current branch is tracking as the
+parent, if none is specified 'origin/master' will be used.
+
+The parent specified when using git is, in all cases, a git 'tree-ish' and
+never an actual git repository, remote or otherwise.  Anything specifiable to
+git as a tree-ish should, similarly, be specifiable as a parent for webrev.
+This includes branches, explicit revisions, reflog entries, etc. See
+.BR git-rev-parse (1)
+
+.SS Subversion
+In the case of Subversion \fBwebrev\fR will attempt to use the output
+from the
+.BR svn (1)
+"svn info" to find the workspace root and subversion repository URL.
+.PP
+The file list will be created from the output of the "svn status" command.
+
+.SH CROSS REFERENCING
+.PP
+After extracting comments (see FILE LIST below),
+.B webrev
+will translate cross references into hyperlinks.  By default, information
+about available information tracking systems can be found in
+/opt/onbld/etc/its.reg, and the specification of a local domain and
+selection and prioritization of systems
+in /opt/onbld/etc/its.conf.  These file formats are self documenting.  Also
+see the -I and -C options below.
+.SH OPTIONS
+.TP 10
+.BI "-C " priority-file
+In addition to the system default and an optional user-supplied ~/.its.conf,
+use the specified file to specify a local domain list and prioritize the list
+of information tracking systems to be searched automatically when resolving cross
+references.
+.TP 10
+.BI "-D"
+Delete remote webrev via SFTP. Default remote host is \fIcr.opensolaris.org\fR,
+default remote directory for removal is the same as workspace/repository
+basename. Remote target can be overriden using -t option. If combined with
+-U the deletion will be performed first. Also, if used together with -U
+and the removal fails, no upload is done. Without -U option no webrev will
+be generated, just like if -n option was used. The deletion is done by
+moving the webrev to special directory in user's home directory. It is
+expected that the remote host periodically runs a script which deletes
+the contents of this directory. See the ENVIRONMENT VARIABLES section for
+more details about this directory.
+.TP 10
+.BI "-I " information-file
+Use the specified file to seed the list of information tracking systems.
+.TP 10
+.BI "-i " include-file
+Include the specified file into the index.html file which is generated
+as part of the webrev.  This allows a snippet of XHTML to be added by
+the webrev author. User content is contained by a <div> tag and
+the markup should validate as XHTML 1.0 Transitional.
+.TP 10
+.BI "-N"
+Suppress all comments from all output forms html, txt and pdf.
+.TP 10
+.BI "-n"
+Do not generate webrev. Useful whenever only upload is needed.
+.TP 10
+.B -O
+Enable \fIOpenSolaris\fR mode: information tracking system hyperlinks
+are generated using the EXTERNAL_URL field from the specified its.reg entry,
+instead of the default INTERNAL_URL_domain field, and sources which appear in
+\fIusr/closed\fR are automatically elided from the review.
+.TP 10
+.BI "-o " output-dir
+Place output from running the script in the directory specified.  If
+specified, this option takes precedence over the WDIR environment variable.
+.TP 10
+.BI "-p " basis-of-comparison
+Specify a basis of comparison meaningful for the SCM currently in use.
+See SCM INTERACTIONS and INCREMENTAL REVIEWS.
+.TP 10
+.BI "-t " target
+Upload target. Specified in form of URI identifier. For SCP/SFTP it is
+\fIssh://user@remote_host:remote_dir\fR and for rsync it is
+\fIrsync://user@remote_host:remote_dir\fR. This option can override the
+-o option if the URI is fully specified. The target is relative to
+the top level directory of the default sftp/rsync directory tree.
+.TP 10
+.BI "-U"
+Upload the webrev. Default remote host is \fIcr.opensolaris.org\fR.
+Default transport is rsync. If it fails, fallback to SCP/SFTP transport
+is done.
+.TP 10
+.BI "-w " wx-file
+Extract the file list from the wx "active" file specified.  'wx' uses
+this mode when invoking webrev.  The list is assumed to be in the
+format expected by the \fIwx\fR package.  See FILE LIST, below.
+
+.SH FILE LIST
+.PP
+.B Webrev
+needs to be told or to discover which files have changed in a
+given workspace.  By default,
+.B webrev
+will attempt to autodetect the
+list of changed files by first consulting 
+.BR wx "(1)."
+If this information is not available, webrev tries to consult the SCM (Source
+Code Manager) currently in use.  If that fails, the user must intervene by
+specifying either a file list or additional options specific to the SCM in use.
+
+.SS Webrev Format
+A webrev formatted file list contains a list of all the files to
+be included in the review with paths relative to the workspace
+directory, e.g.
+.IP
+.nf
+\f(CWusr/src/uts/common/fs/nfs/nfs_subr.c
+usr/src/uts/common/fs/nfs/nfs_export.c
+usr/src/cmd/fs.d/nfs/mountd/mountd.c
+.fi
+.PP
+Include the paths of any files added, deleted, or modified.
+You can keep this list of files in the webrev directory
+that webrev creates in the workspace directory
+(CODEMGR_WS).
+
+If CODEMGR_WS is not set, it may be specified as an environment variable
+within the file list, e.g.
+.IP
+.nf
+\f(CWCODEMGR_WS=/home/brent/myws
+usr/src/uts/common/fs/nfs/nfs_subr.c
+usr/src/uts/common/fs/nfs/nfs_export.c
+usr/src/cmd/fs.d/nfs/mountd/mountd.c
+.fi
+.PP
+To compare the workspace against one other than the parent (see also
+the -p option), include a CODEMGR_PARENT line in the file list, like:
+.IP
+.nf
+\f(CWCODEMGR_WS=/home/brent/myws
+CODEMGR_PARENT=/ws/onnv-gate
+usr/src/uts/common/fs/nfs/nfs_subr.c
+usr/src/uts/common/fs/nfs/nfs_export.c
+usr/src/cmd/fs.d/nfs/mountd/mountd.c
+.fi
+.PP
+Finally, run webrev with the name of the file containing the file list as an
+argument, e.g.
+.nf
+        $ webrev file.list
+.fi
+.PP
+If "-" is supplied as the name of the file, then stdin will be used.
+
+.SS wx Format
+If the \fI-w\fR flag is specified then \fBwebrev\fR
+will assume the file list is in the format expected by the "wx" package:
+pathname lines alternating with SCCS comment lines separated by blank
+lines, e.g.
+.IP
+.nf
+\f(CWusr/src/uts/common/fs/nfs/nfs_subr.c
+
+1206578 Fix spelling error in comment
+
+usr/src/uts/common/fs/nfs/nfs_export.c
+
+4039272 cstyle fixes
+
+usr/src/cmd/fs.d/nfs/mountd/mountd.c
+
+1927634 mountd daemon doesn't handle expletives
+.fi
+
+.SH INCREMENTAL REVIEWS
+When conducting multiple rounds of code review, it may be desirable to
+generate a webrev which represents the delta between reviews.  In this
+case, set the parent workspace to the path to the old webrev:
+
+.IP
+.nf
+\f(CW$ webrev -o ~/public_html/myreview-rd2/ \\
+         -p ~/public_html/myreview/
+.fi
+
+.SH ENVIRONMENT VARIABLES
+The following environment variables allow for customization of \fBwebrev\fR:
+
+.PP
+\fBCDIFFCMD\fR and \fBUDIFFCMD\fR are used when generating Cdiffs and Udiffs
+respectively; their default values are "diff -b -C 5" and "diff -b -U
+5".  To generate diffs with more (or less) than 5 lines of context or
+with more (or less) strict whitespace handling, set one or both of
+these variables in the user environment accordingly.
+
+\fBWDIR\fR sets the output directory.  It is functionally equivalent to
+the \fI-o\fR option.
+
+\fBWDIFF\fR specifies the command used to generate Wdiffs. Wdiff generates a
+full unified context listing with line numbers where unchanged
+sections of code may be expanded and collapsed.  It also provides a
+"split" feature that shows the same file in two HTML frames one above the
+other.  The default path for this script is
+/ws/onnv-gate/public/bin/wdiff but WDIFF may be set to customize this
+to use a more convenient location.
+
+\fBWEBREV_TRASH_DIR\fR specifies alternative location of trash directory
+for remote webrev deletion using the \fI-D\fR option. The directory is
+relative to the top level directory of the default sftp/rsync directory tree.
+The default value of this directory is ".trash".
+
+.SH UPLOADING WEBREVS
+A webrev can be uploaded to remote site using the -U option. To simply
+generate new webrev and upload it to the default remote host use the following
+command:
+.IP
+.nf
+\f(CW$ webrev -U
+.fi
+.PP
+This will generate the webrev to local directory named 'webrev' and upload it
+to remote host with remote directory name equal to local workspace/repository
+name. To change both local and remote directory name, -U can be combined with
+-o option. The following command will store the webrev to local directory named
+"foo.onnv" and upload it to the remote host with the same directory name:
+.IP
+.nf
+\f(CW$ webrev -U -o $CODEMGR_WS/foo.onnv
+.fi
+.PP
+If there is a need for manual change of the webrev before uploading,
+-U can be combined with -n option so that first command will just generate
+the webrev and the second command will upload it without generating it again:
+.IP
+.nf
+\f(CW$ webrev
+\f(CW$ webrev -n -U
+.fi
+.PP
+For custom remote targets, -t option allows to specify all components:
+.IP
+.nf
+\f(CW$ webrev -U -t \\
+	ssh://user@cr.opensolaris.org:foo/bar/bugfix.onnv
+.fi
+.PP
+If the remote path is specified as absolute, \fBwebrev\fR will assume all the
+directories are already created. If the path is relative, \fBwebrev\fR will
+try to create all needed directories. This only works with SCP/SFTP transport.
+.PP
+By default, rsync transport will use SSH for transferring the data to remote
+site. To specify custom username, use entry in SSH client configuration file,
+for example:
+.IP
+.nf
+\f(CWHost cr.opensolaris.org
+  Hostname cr.opensolaris.org
+  User vkotal
+.fi
+
+.SH DELETING WEBREVS
+When deleting a webrev directory on remote site which has a different name
+than the basename of local repository it is necessary to specify the output
+option:
+.IP
+.nf
+\f(CW$ webrev -Do webrev-foo.onnv
+.fi
+.PP
+Otherwise \fBwebrev\fR will attempt to remove remote directory with the same
+name as basename of the local repository.
+.PP
+For the nested directory case it is necessary to specify the full target:
+.IP
+.nf
+\f(CW$ webrev -D -t \\
+	ssh://user@cr.opensolaris.org:foo/bar/bugfix.onnv
+.fi
+.PP
+This will remove just the \fIbugfix.onnv\fR directory.
+
+.SH SEE ALSO
+.BR hg "(1),"
+.BR git "(1),"
+.BR ssh_config "(4),"
+.BR svn "(1),"
+.BR which_scm "(1ONBLD)"
+
+.SH ACKNOWLEDGEMENTS
+Acknowledgements to Rob Thurlow, Mike Eisler, Lin Ling,
+Rod Evans, Mike Kupfer, Greg Onufer, Glenn Skinner,
+Oleg Larin, David Robinson, Matthew Cross, David L. Paktor,
+Neal Gafter, John Beck, Darren Moffat, Norm Shulman, Bill Watson,
+Pedro Rubio and Bill Shannon for valuable feedback and insight in
+building webrev.
+
+Have fun!
+.br
+		Brent Callaghan  11/28/96
+
--- old/usr/src/tools/scripts/which_scm.1	Wed Sep 30 19:35:41 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,77 +0,0 @@
-.\"
-.\" CDDL HEADER START
-.\"
-.\" The contents of this file are subject to the terms of the
-.\" Common Development and Distribution License (the "License").
-.\" You may not use this file except in compliance with the License.
-.\"
-.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" or http://www.opensolaris.org/os/licensing.
-.\" See the License for the specific language governing permissions
-.\" and limitations under the License.
-.\"
-.\" When distributing Covered Code, include this CDDL HEADER in each
-.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" If applicable, add the following below this CDDL HEADER, with the
-.\" fields enclosed by brackets "[]" replaced with your own identifying
-.\" information: Portions Copyright [yyyy] [name of copyright owner]
-.\"
-.\" CDDL HEADER END
-.\"
-.\" Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
-.\" Use is subject to license terms.
-.\"
-.TH which_scm 1 "18 September 2009"
-.SH NAME
-which_scm \- Report Source Code Management system
-.SH SYNOPSIS
-.B which_scm
-
-.SH DESCRIPTION
-.B which_scm
-detects the Source Code Management (SCM) system in use, and prints a
-single line of text containing a one-word name for the SCM, followed
-by a space, and then the top-level directory path for the workspace.
-
-The typical usage within a ksh script is:
-.nf
-        which_scm | read SCM_TYPE CODEMGR_WS || exit 1
-.fi
-
-If CODEMGR_WS is set in the environment, then \fBwhich_scm\fR
-checks only that directory, assuming that it is the top of the tree.
-
-If CODEMGR_WS is not set, then \fBwhich_scm\fR searches upwards to
-find the containing workspace path, and reports that path.
-
-.B which_scm
-can detect the following types of SCM systems (these are the keywords
-used in the output format):
-.nf
-	cvs
-	git
-	mercurial
-	rcs
-	sccs
-	subversion
-	teamware
-.fi
-
-If the type of SCM in use is not known, then the string "unknown" is
-printed, and the path returned is $CODEMGR_WS (if set) or the current
-working directory.  The command may exit with an error if the SCM
-could be detected, but is unusable.
-
-.SH ENVIRONMENT VARIABLES
-The following environment variable is used by \fBwhich_scm\fR:
-
-.PP
-\fBCODEMGR_WS\fR path to current workspace.
-
-.SH SEE ALSO
-.IR cvs(1) ,
-.IR git(1) ,
-.IR hg(1) ,
-.IR sccs(1)
-.IR svn(1) ,
-.IR workspace(1)
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/which_scm.1onbld	Wed Sep 30 19:35:41 2015
@@ -0,0 +1,77 @@
+.\"
+.\" CDDL HEADER START
+.\"
+.\" The contents of this file are subject to the terms of the
+.\" Common Development and Distribution License (the "License").
+.\" You may not use this file except in compliance with the License.
+.\"
+.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" or http://www.opensolaris.org/os/licensing.
+.\" See the License for the specific language governing permissions
+.\" and limitations under the License.
+.\"
+.\" When distributing Covered Code, include this CDDL HEADER in each
+.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" If applicable, add the following below this CDDL HEADER, with the
+.\" fields enclosed by brackets "[]" replaced with your own identifying
+.\" information: Portions Copyright [yyyy] [name of copyright owner]
+.\"
+.\" CDDL HEADER END
+.\"
+.\" Copyright 2008 Sun Microsystems, Inc.  All rights reserved.
+.\" Use is subject to license terms.
+.\"
+.TH which_scm 1ONBLD "18 September 2009"
+.SH NAME
+which_scm \- Report Source Code Management system
+.SH SYNOPSIS
+.B which_scm
+
+.SH DESCRIPTION
+.B which_scm
+detects the Source Code Management (SCM) system in use, and prints a
+single line of text containing a one-word name for the SCM, followed
+by a space, and then the top-level directory path for the workspace.
+
+The typical usage within a ksh script is:
+.nf
+        which_scm | read SCM_TYPE CODEMGR_WS || exit 1
+.fi
+
+If CODEMGR_WS is set in the environment, then \fBwhich_scm\fR
+checks only that directory, assuming that it is the top of the tree.
+
+If CODEMGR_WS is not set, then \fBwhich_scm\fR searches upwards to
+find the containing workspace path, and reports that path.
+
+.B which_scm
+can detect the following types of SCM systems (these are the keywords
+used in the output format):
+.nf
+	cvs
+	git
+	mercurial
+	rcs
+	sccs
+	subversion
+	teamware
+.fi
+
+If the type of SCM in use is not known, then the string "unknown" is
+printed, and the path returned is $CODEMGR_WS (if set) or the current
+working directory.  The command may exit with an error if the SCM
+could be detected, but is unusable.
+
+.SH ENVIRONMENT VARIABLES
+The following environment variable is used by \fBwhich_scm\fR:
+
+.PP
+\fBCODEMGR_WS\fR path to current workspace.
+
+.SH SEE ALSO
+.IR cvs(1) ,
+.IR git(1) ,
+.IR hg(1) ,
+.IR sccs(1)
+.IR svn(1) ,
+.IR workspace(1)
--- old/usr/src/tools/scripts/ws.1	Wed Sep 30 19:35:41 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,444 +0,0 @@
-.\" ident	"%Z%%M%	%I%	%E% SMI"
-.\" " CDDL HEADER START
-.\" "
-.\" " The contents of this file are subject to the terms of the
-.\" " Common Development and Distribution License, Version 1.0 only
-.\" " (the "License").  You may not use this file except in compliance
-.\" " with the License.
-.\" "
-.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" " or http://www.opensolaris.org/os/licensing.
-.\" " See the License for the specific language governing permissions
-.\" " and limitations under the License.
-.\" "
-.\" " When distributing Covered Code, include this CDDL HEADER in each
-.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" " If applicable, add the following below this CDDL HEADER, with the
-.\" " fields enclosed by brackets "[]" replaced with your own identifying
-.\" " information: Portions Copyright [yyyy] [name of copyright owner]
-.\" "
-.\" " CDDL HEADER END
-.\" "
-.\" "Copyright 2004 Sun Microsystems, Inc."
-.\" "All rights reserved"
-.\" "Use is subject to license terms."
-.TH WS 1 "28 January 1992"
-.SH NAME
-.I ws 
-\- enable SunOS avocet environments
-.SH SYNOPSIS
-.B ws
-[-e] [workspace_name]
-.LP
-.SH DESCRIPTION
-.IX "Avocet" "ws" "" "\fBws\fP"
-.LP
-.I Ws 
-will configure your environment to build the SunOS
-source base from an
-.I avocet
-workspace.  The
-.I ws
-script sets up the environment variables for a SunOS avocet
-workspace and spawns a shell for the environment 
-that has been setup.  In configuring the environment
-.I ws
-sets up the environment variables to define in which proto areas
-you will build against as well as the proto area the will be your
-install target.
-.LP
-The following Environment variables are set when you invoke this script:
-.LP
-.RS 5
-.nf
-CODEMGR_WS
-SRC
-ROOT
-PARENT_ROOT
-PATH
-MAKEFLAGS
-ENVCPPFLAGS{1-4}
-ENVLDLIBS{1-3}
-.fi
-.RE
-.LP
-The MAKEFLAGS environment variable is set to force make to
-read default make variables from the environment.
-.LP
-The ENVCPPFLAGS{1-4} and the ENVLDLIBS{1-3} environment variables
-are used to configure a hierarchy of proto areas to be used
-when compiling and linking in the SunOS environment.
-The values for these environment variables will be set according to
-your values for PROTO1, PROTO2, and PROTO3 variables(discussed below).
-.LP
-Workspace names can be specified in two forms:  pathname and
-hostname:pathname.  If the hostname:pathname form is used
-the script will access the environment through the /net automounter
-maps.  If <workspace> is is a relative pathname not found
-in the current directory, check for it in those
-directories listed in the CODEMGR_WSPATH variable (refer to the
-workspace(1) man page for more info on CODEMGR_WSPATH).  
-.LP
-Note that if a workspace argument is not given ws will try to determine
-if the current directory is in a workspace and set the environment for
-that workspace.
-.LP
-.I ws
-will also check for the presense of the ONBLD construction set 
-(/opt/onbld), if it is found it will prepend the 
-ONBLD construction set directory to the front of your PATH.
-If you set your path in your shell
-start-up file (eg: .cshrc) then that will undo what what
-.I ws
-has done.  If you do this in your shell start-up script,
-conditionally protect
-.I ws 
-from your modification with something like this:
-.LP
-.RS 5
-.nf
-if ( ! $?ONBLD_DIR  ) then
-   set path=( ~/bin $path )	# or however you wish to modify path
-endif
-.fi
-.RE
-.LP
-NOTE: this is a csh example, the code would vary with the shell type.
-.LP
-.SH OPTIONS
-.LP
-.TP
-.B \-e
-prevent ws from calling exit or exec, useful for setting environment in
-another Bourne (sh) compatible shell (hint: source ws -e)
-.LP
-.SH USAGE
-.LP
-At start-up time 
-.I ws 
-will determine the number of proto areas to
-be searched and in what order.  This information is configured
-during the first invocation of 
-.I ws
-for each workspace in the protodefs
-file.  This file is located under the avocet directory
-in your workspace:
-.LP
-.RS 5
-.nf
-$CODEMGR_WS/avocet/sunos/protodefs
-.fi
-.RE
-.LP
-In this file you may configure from one to four proto 
-variables (PROTO1, PROTO2, PROTO3, TERMPROTO).  
-These variables define the order in
-which the proto areas will be searched, starting with the PROTO1
-directory and ending in the PROTO3 directory.  
-.LP
-When you define the PROTO hierarchy you are defining a list of proto
-directories in which to search for header files and libraries during
-a build. Refer to the
-Examples section below on how you might configure these PROTO
-definitions.
-.LP
-Also, your initial value for ROOT will be assigned to PROTO1.  This
-means that if you do any install builds in the SunOS source tree;
-they will install in the proto area pointed to by PROTO1. 
-.LP
-The format for the protodefs file is very simple, it follows the
-shell script formats for assigning variables.  Here is an 
-example of some definitions
-you might find in a protodefs file:
-.LP
-.RS 5
-.nf
-PROTO1=$CODEMGR_WS/proto
-PROTO2=/parents_path/proto
-.fi
-.RE
-.LP
-The above example would specify 
-that the current workspaces proto area is
-to be searched first, and then the parent workspace's proto area will be
-searched for included files and libraries.  In that order.
-.LP
-The TERMPROTO variable is a special case from PROTO{1-3}, it is
-used to specify a terminating search path for your compiling
-and linking.  If you specify a TERMPROTO directory then during 
-your compile and link your search path for libraries and include
-files will terminate there.  If you do not specify the
-TERMPROTO variable, then the terminating point for searches will
-be on the native machine. On a 5.x machine this will be /usr/include
-and /usr/lib.
-.LP
-The default values for PROTO1 and PROTO2 will be set by
-.I ws
-initially to point to your current workspaces proto area and 
-the proto area
-of the workspace's parent, if the parent is an Avocet
-workspace.  
-.LP
-The PROTO{1-3} variables will then be used to set your ROOT variable and
-to set the ENVCPPFLAGS{1-4} and the ENVDLLIBS{1-3} environment variables.
-These will be set to an architecture specific directory under
-each PROTO* directory.  If, for example, PROTO1 had been set
-to PROTO1=/ws/train/proto then ROOT would be set to 
-ROOT=/ws/train/proto/root_${MACH}.  MACH would be equal to the
-architecture of the machine you are running on (ie: `uname -p`).
-.LP
-The exception to this is if there is already an existing non-architecture
-specific populated proto area 
-under one of the PROTO{1-3} variables.  If this is the case then the
-ROOT and other flags will be based on that instead of an architecture
-specific sub-directory.
-.LP
-.SH ISSUES
-.LP
-The use of Constrained Files is very different between an NSE
-environment and an avocet workspace.  Constrained files are files which
-are derived but files that you do not have source code for.  For
-example in an NSE environment, a library would be a constrained file if
-you acquired a command that depended on that library but you did not
-acquire the library's sources.  If a user is used to working in an NSE
-environment they should be aware of the differences.
-.LP
-In an NSE environment the user was isolated from updates to both
-constrained files and source files
-alike in the parent environment.  You did not see updates
-to constrained files until you 
-.I resynced 
-a command or object which depended on the
-constrained file in question.  
-This is no longer the case under Avocet.  
-.LP
-If you are using
-.I ws
-to refer to a copy of such a library located in your parent
-workspace's proto area, you are no longer isolated as you were use
-the NSE.
-If your parent updates its copy of the constrained file(libc.so)
-in it's proto area and you are referencing the parents
-proto area via ws, then
-that update is immediately visible to you.  The next time you
-build a new command in your avocet workspace you will be building
-against the new copy of the constrained file(libc.so) which you
-obtain from your parents proto area, you are no longer isolated from
-these updates as you were in the NSE.
-.LP
-If you would like to be isolated from updates in the
-world around you there are a couple of approaches you can take.  First,
-if you bringover a full copy of the SunOS source base you could
-build your own PROTO area which you would link against.  
-Secondly, you could link against a private
-PROTO area which is a stable snapshot of a global proto area.
-This proto area could be a subset
-of a full proto area and contain only those files which you are concerned
-about.  Both of these methods would protect you from updates to files
-because you would be in full control of the proto areas you are linking
-against.  It would be your responsiblity to update your proto area
-as your work progressed.
-.LP
-.SH EXAMPLES
-.LP
-In the following examples you will modify the 
-${CODEMGR_WS}/avocet/sunos/protodefs file to define PROTO{1-3}
-to configure a proto hierarchy to be associated with your
-avocet workspace.  I have selected the four
-most common examples that will be used with avocet workspaces,
-there can be many other combinations.
-.LP
-In the first example we will 
-configure a workspace named 
-caltrans:/bld/child,
-and it is a child of an avocet workspace named dunk:/build/parent.  The
-parent workspace (dunk:/build/parent)
-is a complete copy of the usr/src source tree, while the
-current workspace(caltrans:/bld/child) is a subset of the full
-source base.  The current(child) workspace only contains the usr/src/cmd 
-directories.  The proto areas that
-we want to search are the current workspaces proto area(/bld/child/proto)
-and then the proto area of the parent(/net/dunk/build/parent/proto), in that
-order.  
-Actually, this example is the default behavior if the workspace
-is not a child of an NSE parent.  No modification would actually have
-to have been done to the protodefs file.
-Here is what the protodefs file would look like:
-.LP
-.RS 5
-.nf
-PROTO1=/bld/scrapbook/proto
-PROTO2=/net/dunk/build/ws/proto
-.fi
-.RE
-.LP
-This example represents a model where the current workspaces needs
-to reference a superset of its own proto area in order to build.
-.LP
-Secondly, let us consider a workspace you have named 
-polyslo:/charlie/tuna.  Your
-workspace only contains the source code for the usr/src/cmd
-directories.  Secondly, your avocet parent(dunk:/build/popeye) is not a 
-full copy of
-the source base, but it does have some files in the proto area which
-you want to refer to.  Lastly, you have a global proto area which you
-will refer to if you have not found a header file or library in either
-of the two previous proto areas, this global proto area is located
-at rainman:/space/I-team-protoarea.  Here is what your protodefs file
-would look like:
-.LP
-.RS 5
-.nf
-PROTO1=/charlie/tuna/proto
-PROTO2=/net/dunk/build/popeye/proto
-PROTO3=/net/rainman/space/I-team-protoarea
-.fi 
-.RE
-.LP
-The above model is meant to show you some of the configurability that can
-be done
-.I ws.
-Here you have three proto areas that are searched one after the other.  You
-might configure an environment like this if needed to refer to some
-files that are in the PROTO2 area, but these files are not 
-easily placed into the 'global' I-Team proto area of PROTO3.  It should
-also be noted that there is a performance penalty for such a configuration.
-During each compile the compiler is now potentially searching through
-three directory structures to resolve the include files, this will slow
-things down.  If performance is critical you should also be aware
-of which 'subnets' the PROTO areas are located on.  The farther away
-the PROTO area is from the 'subnet' you are building on the greater
-the performance hit during compiles.
-.LP
-Next, here is a very simple example.  We have a workspace which is a small
-subset of the usr/src/cmd directory named(caltrans:/build/small_cmd) that
-has no proto area associated with it.  For our proto area we will refer
-to a Global 'I-Team' proto area for all of our files.  This area is
-located at rainman:/space/global_proto_area.  In the protodefs file
-we will only need to define PROTO1 for this example:
-.RS 5
-.nf 
-PROTO1=/net/rainman/space/global_proto_area
-.fi
-.RE
-.LP
-This is the example you would follow for very small workspaces
-with which you do not intend to modify and install any headers
-or libraries.  All of the
-include files and libraries will be pulled from the I-TEAM proto area.
-The advantage to this model is speed, there is only one area in which
-the compiler is going to search for include files and libraries, this
-will help the compilers performance.  Also, you should be aware that 
-ROOT is equal to PROTO1.  If you attempt to do an install build it
-will attempt to modify the I-Team proto area that you are pointing at!
-.LP
-Lastly, we have an avocet workspace named 
-caltrans:/bld/nse_child which is the child of an NSE environment.  
-Because the parent of the workspace is an NSE environment, that parent
-does not have a PROTO area associated with it that we can 
-refer to.  Instead there is a global PROTO area that is maintained
-by our 'I-Team' leader that we will refer to.  That global area
-is located at rainman:/space/I-team-protoarea.  Here is what
-the protodefs file would look like:
-.LP
-.RS 5
-.nf
-PROTO1=/bld/nse_child
-PROTO2=/net/rainman/space/I-team-protoarea
-.fi
-.RE
-.LP
-This model differs from the one above in that we can not reference
-the parents proto area because the parent in an NSE environment.  
-Instead for our second proto area we point to a stable proto
-area outside of the NSE.
-.LP
-.SH ENVIRONMENT VARIABLES
-.LP
-Here is a list of the environment variables that 
-.I ws
-will set and how they are used:
-.LP
-CODEMGR_WS         
-.fi
-.RS 5
-Absolute pathname to the Avocet workspace.  This environment variable
-is referenced by the
-.I bringover
-,
-.I putback
-,
-and
-.I workspace
-commands.
-.RE
-SRC
-.RS 5
-Root of SunOS source code, referenced by SunOS Makefiles.
-.RE
-ROOT
-.RS 5
-Initial proto area for this workspace.  Again this is used by the 
-SunOS Makefiles.  This value is set based on PROTO1 as defined in
-the protodefs file.  ROOT is also the destination of 
-.I install 
-operations.
-.RE
-PARENT_ROOT
-.RS 5
-Parent proto area for this workspace.  This is used by the 
-SunOS Makefiles.  This value is set based on PROTO2 as defined in
-the protodefs file. 
-.RE
-PATH
-.RS 5
-If the construction set exists (/opt/onbld) it will  be prepended to 
-the search path.
-.RE
-MAKEFLAGS
-.RS 5
-Default MAKEFLAGS used by 
-.I make,
-set to 'e' for higher environment precedence.
-.RE
-ENVCPPFLAGS{1-4}
-.RS 5
-This set of environment variables is used to set the 
-CPPFLAGS.master macro within the SunOS source tree.  These values
-usually point to a hierarchy of Include directories for the build
-to search through.
-.RE
-ENVLDLIBS{1-3}
-.RS 5
-This set of environment variables is used to set the LDLIBS.master
-macro within the SunOS source tree.  These values usually point
-to a hierarchy of directories to search for libraries.
-.RE
-.LP
-.SH FILES
-.LP
-.nf
-$CODEMGR_WS/avocet/sunos/protodefs
-.fi
-.LP
-.SH "SEE ALSO"
-.LP
-.IR workspace (1),
-.IR bringover (1),
-.IR putback (1),
-.IR protodefs(5)
-.LP
-.SH BUGS
-.LP
-TERMPROTO is broken.
-On 5.x builds TERMPROTO is incompatible with the C++ driver.  The bug
-is that the C++ driver does not use the standard SVR4 notation
-for the -Y I, option.
-.LP
-.I ws
-can have problems with the automounter.  If you refer to a workspace
-using a relative path, and that workspace is mounted via the automounter, 
-then that workspace will be refered to via the /tmp_mnt/*
-location.  It's best to deal with automounted workspaces through
-an absolute pathname when running
-.I ws.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/ws.1onbld	Wed Sep 30 19:35:41 2015
@@ -0,0 +1,443 @@
+.\" " CDDL HEADER START
+.\" "
+.\" " The contents of this file are subject to the terms of the
+.\" " Common Development and Distribution License, Version 1.0 only
+.\" " (the "License").  You may not use this file except in compliance
+.\" " with the License.
+.\" "
+.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" " or http://www.opensolaris.org/os/licensing.
+.\" " See the License for the specific language governing permissions
+.\" " and limitations under the License.
+.\" "
+.\" " When distributing Covered Code, include this CDDL HEADER in each
+.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" " If applicable, add the following below this CDDL HEADER, with the
+.\" " fields enclosed by brackets "[]" replaced with your own identifying
+.\" " information: Portions Copyright [yyyy] [name of copyright owner]
+.\" "
+.\" " CDDL HEADER END
+.\" "
+.\" "Copyright 2004 Sun Microsystems, Inc."
+.\" "All rights reserved"
+.\" "Use is subject to license terms."
+.TH WS 1ONBLD "28 January 1992"
+.SH NAME
+.I ws 
+\- enable SunOS avocet environments
+.SH SYNOPSIS
+.B ws
+[-e] [workspace_name]
+.LP
+.SH DESCRIPTION
+.IX "Avocet" "ws" "" "\fBws\fP"
+.LP
+.I Ws 
+will configure your environment to build the SunOS
+source base from an
+.I avocet
+workspace.  The
+.I ws
+script sets up the environment variables for a SunOS avocet
+workspace and spawns a shell for the environment 
+that has been setup.  In configuring the environment
+.I ws
+sets up the environment variables to define in which proto areas
+you will build against as well as the proto area the will be your
+install target.
+.LP
+The following Environment variables are set when you invoke this script:
+.LP
+.RS 5
+.nf
+CODEMGR_WS
+SRC
+ROOT
+PARENT_ROOT
+PATH
+MAKEFLAGS
+ENVCPPFLAGS{1-4}
+ENVLDLIBS{1-3}
+.fi
+.RE
+.LP
+The MAKEFLAGS environment variable is set to force make to
+read default make variables from the environment.
+.LP
+The ENVCPPFLAGS{1-4} and the ENVLDLIBS{1-3} environment variables
+are used to configure a hierarchy of proto areas to be used
+when compiling and linking in the SunOS environment.
+The values for these environment variables will be set according to
+your values for PROTO1, PROTO2, and PROTO3 variables(discussed below).
+.LP
+Workspace names can be specified in two forms:  pathname and
+hostname:pathname.  If the hostname:pathname form is used
+the script will access the environment through the /net automounter
+maps.  If <workspace> is is a relative pathname not found
+in the current directory, check for it in those
+directories listed in the CODEMGR_WSPATH variable (refer to the
+workspace(1) man page for more info on CODEMGR_WSPATH).  
+.LP
+Note that if a workspace argument is not given ws will try to determine
+if the current directory is in a workspace and set the environment for
+that workspace.
+.LP
+.I ws
+will also check for the presense of the ONBLD construction set 
+(/opt/onbld), if it is found it will prepend the 
+ONBLD construction set directory to the front of your PATH.
+If you set your path in your shell
+start-up file (eg: .cshrc) then that will undo what what
+.I ws
+has done.  If you do this in your shell start-up script,
+conditionally protect
+.I ws 
+from your modification with something like this:
+.LP
+.RS 5
+.nf
+if ( ! $?ONBLD_DIR  ) then
+   set path=( ~/bin $path )	# or however you wish to modify path
+endif
+.fi
+.RE
+.LP
+NOTE: this is a csh example, the code would vary with the shell type.
+.LP
+.SH OPTIONS
+.LP
+.TP
+.B \-e
+prevent ws from calling exit or exec, useful for setting environment in
+another Bourne (sh) compatible shell (hint: source ws -e)
+.LP
+.SH USAGE
+.LP
+At start-up time 
+.I ws 
+will determine the number of proto areas to
+be searched and in what order.  This information is configured
+during the first invocation of 
+.I ws
+for each workspace in the protodefs
+file.  This file is located under the avocet directory
+in your workspace:
+.LP
+.RS 5
+.nf
+$CODEMGR_WS/avocet/sunos/protodefs
+.fi
+.RE
+.LP
+In this file you may configure from one to four proto 
+variables (PROTO1, PROTO2, PROTO3, TERMPROTO).  
+These variables define the order in
+which the proto areas will be searched, starting with the PROTO1
+directory and ending in the PROTO3 directory.  
+.LP
+When you define the PROTO hierarchy you are defining a list of proto
+directories in which to search for header files and libraries during
+a build. Refer to the
+Examples section below on how you might configure these PROTO
+definitions.
+.LP
+Also, your initial value for ROOT will be assigned to PROTO1.  This
+means that if you do any install builds in the SunOS source tree;
+they will install in the proto area pointed to by PROTO1. 
+.LP
+The format for the protodefs file is very simple, it follows the
+shell script formats for assigning variables.  Here is an 
+example of some definitions
+you might find in a protodefs file:
+.LP
+.RS 5
+.nf
+PROTO1=$CODEMGR_WS/proto
+PROTO2=/parents_path/proto
+.fi
+.RE
+.LP
+The above example would specify 
+that the current workspaces proto area is
+to be searched first, and then the parent workspace's proto area will be
+searched for included files and libraries.  In that order.
+.LP
+The TERMPROTO variable is a special case from PROTO{1-3}, it is
+used to specify a terminating search path for your compiling
+and linking.  If you specify a TERMPROTO directory then during 
+your compile and link your search path for libraries and include
+files will terminate there.  If you do not specify the
+TERMPROTO variable, then the terminating point for searches will
+be on the native machine. On a 5.x machine this will be /usr/include
+and /usr/lib.
+.LP
+The default values for PROTO1 and PROTO2 will be set by
+.I ws
+initially to point to your current workspaces proto area and 
+the proto area
+of the workspace's parent, if the parent is an Avocet
+workspace.  
+.LP
+The PROTO{1-3} variables will then be used to set your ROOT variable and
+to set the ENVCPPFLAGS{1-4} and the ENVDLLIBS{1-3} environment variables.
+These will be set to an architecture specific directory under
+each PROTO* directory.  If, for example, PROTO1 had been set
+to PROTO1=/ws/train/proto then ROOT would be set to 
+ROOT=/ws/train/proto/root_${MACH}.  MACH would be equal to the
+architecture of the machine you are running on (ie: `uname -p`).
+.LP
+The exception to this is if there is already an existing non-architecture
+specific populated proto area 
+under one of the PROTO{1-3} variables.  If this is the case then the
+ROOT and other flags will be based on that instead of an architecture
+specific sub-directory.
+.LP
+.SH ISSUES
+.LP
+The use of Constrained Files is very different between an NSE
+environment and an avocet workspace.  Constrained files are files which
+are derived but files that you do not have source code for.  For
+example in an NSE environment, a library would be a constrained file if
+you acquired a command that depended on that library but you did not
+acquire the library's sources.  If a user is used to working in an NSE
+environment they should be aware of the differences.
+.LP
+In an NSE environment the user was isolated from updates to both
+constrained files and source files
+alike in the parent environment.  You did not see updates
+to constrained files until you 
+.I resynced 
+a command or object which depended on the
+constrained file in question.  
+This is no longer the case under Avocet.  
+.LP
+If you are using
+.I ws
+to refer to a copy of such a library located in your parent
+workspace's proto area, you are no longer isolated as you were use
+the NSE.
+If your parent updates its copy of the constrained file(libc.so)
+in it's proto area and you are referencing the parents
+proto area via ws, then
+that update is immediately visible to you.  The next time you
+build a new command in your avocet workspace you will be building
+against the new copy of the constrained file(libc.so) which you
+obtain from your parents proto area, you are no longer isolated from
+these updates as you were in the NSE.
+.LP
+If you would like to be isolated from updates in the
+world around you there are a couple of approaches you can take.  First,
+if you bringover a full copy of the SunOS source base you could
+build your own PROTO area which you would link against.  
+Secondly, you could link against a private
+PROTO area which is a stable snapshot of a global proto area.
+This proto area could be a subset
+of a full proto area and contain only those files which you are concerned
+about.  Both of these methods would protect you from updates to files
+because you would be in full control of the proto areas you are linking
+against.  It would be your responsiblity to update your proto area
+as your work progressed.
+.LP
+.SH EXAMPLES
+.LP
+In the following examples you will modify the 
+${CODEMGR_WS}/avocet/sunos/protodefs file to define PROTO{1-3}
+to configure a proto hierarchy to be associated with your
+avocet workspace.  I have selected the four
+most common examples that will be used with avocet workspaces,
+there can be many other combinations.
+.LP
+In the first example we will 
+configure a workspace named 
+caltrans:/bld/child,
+and it is a child of an avocet workspace named dunk:/build/parent.  The
+parent workspace (dunk:/build/parent)
+is a complete copy of the usr/src source tree, while the
+current workspace(caltrans:/bld/child) is a subset of the full
+source base.  The current(child) workspace only contains the usr/src/cmd 
+directories.  The proto areas that
+we want to search are the current workspaces proto area(/bld/child/proto)
+and then the proto area of the parent(/net/dunk/build/parent/proto), in that
+order.  
+Actually, this example is the default behavior if the workspace
+is not a child of an NSE parent.  No modification would actually have
+to have been done to the protodefs file.
+Here is what the protodefs file would look like:
+.LP
+.RS 5
+.nf
+PROTO1=/bld/scrapbook/proto
+PROTO2=/net/dunk/build/ws/proto
+.fi
+.RE
+.LP
+This example represents a model where the current workspaces needs
+to reference a superset of its own proto area in order to build.
+.LP
+Secondly, let us consider a workspace you have named 
+polyslo:/charlie/tuna.  Your
+workspace only contains the source code for the usr/src/cmd
+directories.  Secondly, your avocet parent(dunk:/build/popeye) is not a 
+full copy of
+the source base, but it does have some files in the proto area which
+you want to refer to.  Lastly, you have a global proto area which you
+will refer to if you have not found a header file or library in either
+of the two previous proto areas, this global proto area is located
+at rainman:/space/I-team-protoarea.  Here is what your protodefs file
+would look like:
+.LP
+.RS 5
+.nf
+PROTO1=/charlie/tuna/proto
+PROTO2=/net/dunk/build/popeye/proto
+PROTO3=/net/rainman/space/I-team-protoarea
+.fi 
+.RE
+.LP
+The above model is meant to show you some of the configurability that can
+be done
+.I ws.
+Here you have three proto areas that are searched one after the other.  You
+might configure an environment like this if needed to refer to some
+files that are in the PROTO2 area, but these files are not 
+easily placed into the 'global' I-Team proto area of PROTO3.  It should
+also be noted that there is a performance penalty for such a configuration.
+During each compile the compiler is now potentially searching through
+three directory structures to resolve the include files, this will slow
+things down.  If performance is critical you should also be aware
+of which 'subnets' the PROTO areas are located on.  The farther away
+the PROTO area is from the 'subnet' you are building on the greater
+the performance hit during compiles.
+.LP
+Next, here is a very simple example.  We have a workspace which is a small
+subset of the usr/src/cmd directory named(caltrans:/build/small_cmd) that
+has no proto area associated with it.  For our proto area we will refer
+to a Global 'I-Team' proto area for all of our files.  This area is
+located at rainman:/space/global_proto_area.  In the protodefs file
+we will only need to define PROTO1 for this example:
+.RS 5
+.nf 
+PROTO1=/net/rainman/space/global_proto_area
+.fi
+.RE
+.LP
+This is the example you would follow for very small workspaces
+with which you do not intend to modify and install any headers
+or libraries.  All of the
+include files and libraries will be pulled from the I-TEAM proto area.
+The advantage to this model is speed, there is only one area in which
+the compiler is going to search for include files and libraries, this
+will help the compilers performance.  Also, you should be aware that 
+ROOT is equal to PROTO1.  If you attempt to do an install build it
+will attempt to modify the I-Team proto area that you are pointing at!
+.LP
+Lastly, we have an avocet workspace named 
+caltrans:/bld/nse_child which is the child of an NSE environment.  
+Because the parent of the workspace is an NSE environment, that parent
+does not have a PROTO area associated with it that we can 
+refer to.  Instead there is a global PROTO area that is maintained
+by our 'I-Team' leader that we will refer to.  That global area
+is located at rainman:/space/I-team-protoarea.  Here is what
+the protodefs file would look like:
+.LP
+.RS 5
+.nf
+PROTO1=/bld/nse_child
+PROTO2=/net/rainman/space/I-team-protoarea
+.fi
+.RE
+.LP
+This model differs from the one above in that we can not reference
+the parents proto area because the parent in an NSE environment.  
+Instead for our second proto area we point to a stable proto
+area outside of the NSE.
+.LP
+.SH ENVIRONMENT VARIABLES
+.LP
+Here is a list of the environment variables that 
+.I ws
+will set and how they are used:
+.LP
+CODEMGR_WS         
+.fi
+.RS 5
+Absolute pathname to the Avocet workspace.  This environment variable
+is referenced by the
+.I bringover
+,
+.I putback
+,
+and
+.I workspace
+commands.
+.RE
+SRC
+.RS 5
+Root of SunOS source code, referenced by SunOS Makefiles.
+.RE
+ROOT
+.RS 5
+Initial proto area for this workspace.  Again this is used by the 
+SunOS Makefiles.  This value is set based on PROTO1 as defined in
+the protodefs file.  ROOT is also the destination of 
+.I install 
+operations.
+.RE
+PARENT_ROOT
+.RS 5
+Parent proto area for this workspace.  This is used by the 
+SunOS Makefiles.  This value is set based on PROTO2 as defined in
+the protodefs file. 
+.RE
+PATH
+.RS 5
+If the construction set exists (/opt/onbld) it will  be prepended to 
+the search path.
+.RE
+MAKEFLAGS
+.RS 5
+Default MAKEFLAGS used by 
+.I make,
+set to 'e' for higher environment precedence.
+.RE
+ENVCPPFLAGS{1-4}
+.RS 5
+This set of environment variables is used to set the 
+CPPFLAGS.master macro within the SunOS source tree.  These values
+usually point to a hierarchy of Include directories for the build
+to search through.
+.RE
+ENVLDLIBS{1-3}
+.RS 5
+This set of environment variables is used to set the LDLIBS.master
+macro within the SunOS source tree.  These values usually point
+to a hierarchy of directories to search for libraries.
+.RE
+.LP
+.SH FILES
+.LP
+.nf
+$CODEMGR_WS/avocet/sunos/protodefs
+.fi
+.LP
+.SH "SEE ALSO"
+.LP
+.IR workspace (1),
+.IR bringover (1ONBLD),
+.IR putback (1),
+.IR protodefs(5)
+.LP
+.SH BUGS
+.LP
+TERMPROTO is broken.
+On 5.x builds TERMPROTO is incompatible with the C++ driver.  The bug
+is that the C++ driver does not use the standard SVR4 notation
+for the -Y I, option.
+.LP
+.I ws
+can have problems with the automounter.  If you refer to a workspace
+using a relative path, and that workspace is mounted via the automounter, 
+then that workspace will be refered to via the /tmp_mnt/*
+location.  It's best to deal with automounted workspaces through
+an absolute pathname when running
+.I ws.
--- old/usr/src/tools/scripts/wsdiff.1	Wed Sep 30 19:35:42 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,199 +0,0 @@
-.\" " CDDL HEADER START
-.\" "
-.\" " The contents of this file are subject to the terms of the
-.\" " Common Development and Distribution License (the "License").
-.\" " You may not use this file except in compliance with the License.
-.\" "
-.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" " or http://www.opensolaris.org/os/licensing.
-.\" " See the License for the specific language governing permissions
-.\" " and limitations under the License.
-.\" "
-.\" " When distributing Covered Code, include this CDDL HEADER in each
-.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" " If applicable, add the following below this CDDL HEADER, with the
-.\" " fields enclosed by brackets "[]" replaced with your own identifying
-.\" " information: Portions Copyright [yyyy] [name of copyright owner]
-.\" "
-.\" " CDDL HEADER END
-.\" "
-.\" " Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
-.\" "
-.TH wsdiff 1 "15 Jul 2010"
-.I wsdiff
-\- report differences between proto area objects
-.SH SYNOPSIS
-\fBwsdiff [-dvVst] [-r \fIresults\fP] [-i \fIfilelist\fP] \fIold\fP \fInew\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "wsdiff" "" "\fBwsdiff\fP"
-.LP
-The wsdiff utility detects and reports on object differences found between
-two proto areas constructed from the same workspace. This can be useful
-when trying to understand which objects have changed as a result of a particular
-source change.
-.LP
-\fIold\fP specifies the baseline proto area constructed without the source
-change. \fInew\fP specifies the proto area constructed with the source
-change. Both \fIold\fP and \fInew\fP should be constructed from the same
-workspace, otherwise wsdiff will find object differences not associated
-with the source change.
-.SH OPTIONS
-.TP 10
-.B -d
-Print debug information. The debug lines are prefixed with ##.
-.TP 10
-.B -v
-Do not truncate the diffs logged to the results file. By default wsdiff
-will truncate the length of a sufficiently long set of object diffs to preserve
-the readability of the results file. -v can be used to override this behaviour.
-.TP 10
-.B -V
-Log observed differences for all ELF sections, rather than logging only the first
-difference found. When wsdiff encounters an ELF section difference, by default
-it will log the difference associated with that section only, and move on. -V forces
-wsdiff to log all ELF section differences found between two objects, rather than
-just the first. Because of the extra work involved, this may slow wsdiff down
-considerably.
-.TP 10
-.B -s
-Produce sorted lists. This is handy when comparing multiple wsdiff outputs
-because wsdiff runs in multithreaded mode so the list of differences is not
-sorted and can differ between multiple runs.
-.TP 10
-.B -t
-Look for the onbld tools in $SRC/tools rather than /opt/onbld/bin
-.TP 10
-.B -r
-Log results to the specified log file. The log file contains a list of new, deleted,
-and changed objects, as well as diffs signifying what wsdiff found to be different.
-.TP 10
-.B -i
-Specify which objects should be compared by wsdiff via an input file list (See
-EXAMPLES).
-.LP
-.SH OUTPUT
-.LP
-The list of objects appearing to differ between \fIold\fP and \fInew\fP is
-printed to stdout. If -r was specified, the list of differing objects and
-their differrences are logged to \fIresults\fP.
-.LP
-.SH EXAMPLES
-.PP
-\fBExample 1: Using wsdiff to determine patch deliverables\fR
-.PP
-The following example shows how to use wsdiff to determine the set of objects
-requiring (re)delivery via patch as a result of a given source change:
-.LP
-Starting with a built workspace, move the existing proto area aside:
-.LP
-.nf
-user@example$ ls
-Codemgr_wsdata/  proto/           usr/
-
-user@example$ mv proto proto.old
-.fi
-.LP
-Next, integrate the source changes, rebuild, and invoke wsdiff specifying the
-old and new proto areas:
-.LP
-.nf
-user@example$ ls
-Codemgr_wsdata/  proto/           proto.old/      usr/
-
-user@example$ wsdiff proto.old proto
-platform/SUNW,SPARC-Enterprise/kernel/sparcv9/unix
-platform/SUNW,Sun-Fire-15000/kernel/sparcv9/unix
-platform/sun4v/kernel/sparcv9/unix
-platform/sun4u/kernel/sparcv9/unix
-platform/SUNW,Ultra-Enterprise-10000/kernel/sparcv9/unix
-platform/SUNW,Sun-Fire/kernel/sparcv9/unix
-.fi
-.PP
-\fBExample 2: The wsdiff results file\fR
-.PP
-With the -r option, wsdiff will log the list of objects that appear different, as well
-as a set of diffs highlighting the observed difference:
-.LP
-.nf
-user@example$ wsdiff -r results proto.old proto
-platform/SUNW,SPARC-Enterprise/kernel/sparcv9/unix
-platform/SUNW,Sun-Fire-15000/kernel/sparcv9/unix
-platform/sun4v/kernel/sparcv9/unix
-platform/sun4u/kernel/sparcv9/unix
-platform/SUNW,Ultra-Enterprise-10000/kernel/sparcv9/unix
-platform/SUNW,Sun-Fire/kernel/sparcv9/unix
-
-user@example$ cat results
-# This file was produced by wsdiff
-# 2006/7/10 at 18:28:56
-Base proto area: proto.old/
-Patch (new) proto area: proto/
-Results file: results
-
-platform/SUNW,SPARC-Enterprise/kernel/sparcv9/unix
-NOTE: ELF .text difference detected.
-
-89562,89567c89562,89567
-<     lgrp_cpu_init+0x158:    9e 10 20 01  mov       0x1, %o7
-<     lgrp_cpu_init+0x15c:    b3 2b d0 1c  sllx      %o7, %i4, %i1
-<     lgrp_cpu_init+0x160:    9a 12 40 19  or        %o1, %i1, %o5
-<     lgrp_cpu_init+0x164:    da 76 a0 30  stx       %o5, [%i2 + 0x30]
-<     lgrp_cpu_init+0x168:    d8 04 e0 00  ld        [%l3], %o4
-<     lgrp_cpu_init+0x16c:    80 a3 20 00  cmp       %o4, 0x0
----
->     lgrp_cpu_init+0x158:    9a 10 20 01  mov       0x1, %o5
->     lgrp_cpu_init+0x15c:    b3 2b 50 1c  sllx      %o5, %i4, %i1
->     lgrp_cpu_init+0x160:    98 12 00 19  or        %o0, %i1, %o4
->     lgrp_cpu_init+0x164:    d8 76 a0 30  stx       %o4, [%i2 + 0x30]
->     lgrp_cpu_init+0x168:    d6 04 e0 00  ld        [%l3], %o3
->     lgrp_cpu_init+0x16c:    80 a2 e0 00  cmp       %o3, 0x0
-
-...
-
-.fi
-.PP
-\fBExample 3: Using an input file list\fR
-.PP
-The -i option tells wsdiff to compare a specific list of objects. This can be useful
-in conjunction with other options that direct wsdiff to log more verbosely, allowing
-one to "drill down" into a particular object's differences:
-.LP
-.nf
-user@example$ echo "usr/lib/mdb/kvm/sparcv9/genunix.so" > flist
-user@example$ wsdiff -vV -r results -i flist proto.old proto
-usr/lib/mdb/kvm/sparcv9/genunix.so
-
-user@example$ cat results
-<... verbose differences only for genunix.so ...>
-.fi
-.PP
-\fBExample 4: Invoking wsdiff through nightly(1)\fR
-.PP
-By specifying -w in NIGHTLY_OPTIONS, nightly(1) will use wsdiff(1) to determine
-which objects look different, compared to the previous build. A pre-existing proto area
-must exist for wsdiff(1) to compare against. nightly(1) will move aside the
-pre-existing proto area (renaming it to $ROOT.prev under proto), and will
-invoke wsdiff at the end of the build. The list of changed objects will be reported
-in the nightly mail message, and a results file "wsdiff_results" will appear in the
-nightly log area.
-.PP
-\fBExample 5: Influencing the level of paralelism\fR
-.PP
-wsdiff spawns a number of threads by default after it determines the list
-of files for comparison. Default number of threads is based on the number of
-on-line CPUs present in the system. To set the number of threads for processing
-to some other value the DMAKE_MAX_JOBS environment variable can be used:
-.LP
-.nf
-$ DMAKE_MAX_JOBS=24 wsdiff proto_base proto_patch
-.fi
-.PP
-Note that this variable is also used for nightly(1) so when run from
-nightly(1), wsdiff will honor the setting.
-.LP
-.SH SEE ALSO
-.LP
-.IR lintdump(1),
-.IR nightly(1),
-.IR elfdump(1),
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/wsdiff.1onbld	Wed Sep 30 19:35:42 2015
@@ -0,0 +1,198 @@
+.\" " CDDL HEADER START
+.\" "
+.\" " The contents of this file are subject to the terms of the
+.\" " Common Development and Distribution License (the "License").
+.\" " You may not use this file except in compliance with the License.
+.\" "
+.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" " or http://www.opensolaris.org/os/licensing.
+.\" " See the License for the specific language governing permissions
+.\" " and limitations under the License.
+.\" "
+.\" " When distributing Covered Code, include this CDDL HEADER in each
+.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" " If applicable, add the following below this CDDL HEADER, with the
+.\" " fields enclosed by brackets "[]" replaced with your own identifying
+.\" " information: Portions Copyright [yyyy] [name of copyright owner]
+.\" "
+.\" " CDDL HEADER END
+.\" "
+.\" " Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
+.\" "
+.TH wsdiff 1ONBLD "15 Jul 2010"
+.I wsdiff
+\- report differences between proto area objects
+.SH SYNOPSIS
+\fBwsdiff [-dvVst] [-r \fIresults\fP] [-i \fIfilelist\fP] \fIold\fP \fInew\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "wsdiff" "" "\fBwsdiff\fP"
+.LP
+The wsdiff utility detects and reports on object differences found between
+two proto areas constructed from the same workspace. This can be useful
+when trying to understand which objects have changed as a result of a particular
+source change.
+.LP
+\fIold\fP specifies the baseline proto area constructed without the source
+change. \fInew\fP specifies the proto area constructed with the source
+change. Both \fIold\fP and \fInew\fP should be constructed from the same
+workspace, otherwise wsdiff will find object differences not associated
+with the source change.
+.SH OPTIONS
+.TP 10
+.B -d
+Print debug information. The debug lines are prefixed with ##.
+.TP 10
+.B -v
+Do not truncate the diffs logged to the results file. By default wsdiff
+will truncate the length of a sufficiently long set of object diffs to preserve
+the readability of the results file. -v can be used to override this behaviour.
+.TP 10
+.B -V
+Log observed differences for all ELF sections, rather than logging only the first
+difference found. When wsdiff encounters an ELF section difference, by default
+it will log the difference associated with that section only, and move on. -V forces
+wsdiff to log all ELF section differences found between two objects, rather than
+just the first. Because of the extra work involved, this may slow wsdiff down
+considerably.
+.TP 10
+.B -s
+Produce sorted lists. This is handy when comparing multiple wsdiff outputs
+because wsdiff runs in multithreaded mode so the list of differences is not
+sorted and can differ between multiple runs.
+.TP 10
+.B -t
+Look for the onbld tools in $SRC/tools rather than /opt/onbld/bin
+.TP 10
+.B -r
+Log results to the specified log file. The log file contains a list of new, deleted,
+and changed objects, as well as diffs signifying what wsdiff found to be different.
+.TP 10
+.B -i
+Specify which objects should be compared by wsdiff via an input file list (See
+EXAMPLES).
+.LP
+.SH OUTPUT
+.LP
+The list of objects appearing to differ between \fIold\fP and \fInew\fP is
+printed to stdout. If -r was specified, the list of differing objects and
+their differrences are logged to \fIresults\fP.
+.LP
+.SH EXAMPLES
+.PP
+\fBExample 1: Using wsdiff to determine patch deliverables\fR
+.PP
+The following example shows how to use wsdiff to determine the set of objects
+requiring (re)delivery via patch as a result of a given source change:
+.LP
+Starting with a built workspace, move the existing proto area aside:
+.LP
+.nf
+user@example$ ls
+Codemgr_wsdata/  proto/           usr/
+
+user@example$ mv proto proto.old
+.fi
+.LP
+Next, integrate the source changes, rebuild, and invoke wsdiff specifying the
+old and new proto areas:
+.LP
+.nf
+user@example$ ls
+Codemgr_wsdata/  proto/           proto.old/      usr/
+
+user@example$ wsdiff proto.old proto
+platform/SUNW,SPARC-Enterprise/kernel/sparcv9/unix
+platform/SUNW,Sun-Fire-15000/kernel/sparcv9/unix
+platform/sun4v/kernel/sparcv9/unix
+platform/sun4u/kernel/sparcv9/unix
+platform/SUNW,Ultra-Enterprise-10000/kernel/sparcv9/unix
+platform/SUNW,Sun-Fire/kernel/sparcv9/unix
+.fi
+.PP
+\fBExample 2: The wsdiff results file\fR
+.PP
+With the -r option, wsdiff will log the list of objects that appear different, as well
+as a set of diffs highlighting the observed difference:
+.LP
+.nf
+user@example$ wsdiff -r results proto.old proto
+platform/SUNW,SPARC-Enterprise/kernel/sparcv9/unix
+platform/SUNW,Sun-Fire-15000/kernel/sparcv9/unix
+platform/sun4v/kernel/sparcv9/unix
+platform/sun4u/kernel/sparcv9/unix
+platform/SUNW,Ultra-Enterprise-10000/kernel/sparcv9/unix
+platform/SUNW,Sun-Fire/kernel/sparcv9/unix
+
+user@example$ cat results
+# This file was produced by wsdiff
+# 2006/7/10 at 18:28:56
+Base proto area: proto.old/
+Patch (new) proto area: proto/
+Results file: results
+
+platform/SUNW,SPARC-Enterprise/kernel/sparcv9/unix
+NOTE: ELF .text difference detected.
+
+89562,89567c89562,89567
+<     lgrp_cpu_init+0x158:    9e 10 20 01  mov       0x1, %o7
+<     lgrp_cpu_init+0x15c:    b3 2b d0 1c  sllx      %o7, %i4, %i1
+<     lgrp_cpu_init+0x160:    9a 12 40 19  or        %o1, %i1, %o5
+<     lgrp_cpu_init+0x164:    da 76 a0 30  stx       %o5, [%i2 + 0x30]
+<     lgrp_cpu_init+0x168:    d8 04 e0 00  ld        [%l3], %o4
+<     lgrp_cpu_init+0x16c:    80 a3 20 00  cmp       %o4, 0x0
+---
+>     lgrp_cpu_init+0x158:    9a 10 20 01  mov       0x1, %o5
+>     lgrp_cpu_init+0x15c:    b3 2b 50 1c  sllx      %o5, %i4, %i1
+>     lgrp_cpu_init+0x160:    98 12 00 19  or        %o0, %i1, %o4
+>     lgrp_cpu_init+0x164:    d8 76 a0 30  stx       %o4, [%i2 + 0x30]
+>     lgrp_cpu_init+0x168:    d6 04 e0 00  ld        [%l3], %o3
+>     lgrp_cpu_init+0x16c:    80 a2 e0 00  cmp       %o3, 0x0
+
+...
+
+.fi
+.PP
+\fBExample 3: Using an input file list\fR
+.PP
+The -i option tells wsdiff to compare a specific list of objects. This can be useful
+in conjunction with other options that direct wsdiff to log more verbosely, allowing
+one to "drill down" into a particular object's differences:
+.LP
+.nf
+user@example$ echo "usr/lib/mdb/kvm/sparcv9/genunix.so" > flist
+user@example$ wsdiff -vV -r results -i flist proto.old proto
+usr/lib/mdb/kvm/sparcv9/genunix.so
+
+user@example$ cat results
+<... verbose differences only for genunix.so ...>
+.fi
+.PP
+\fBExample 4: Invoking wsdiff through nightly(1ONBLD)\fR
+.PP
+By specifying -w in NIGHTLY_OPTIONS, nightly(1ONBLD) will use wsdiff(1ONBLD) to determine
+which objects look different, compared to the previous build. A pre-existing proto area
+must exist for wsdiff(1ONBLD) to compare against. nightly(1ONBLD) will move aside the
+pre-existing proto area (renaming it to $ROOT.prev under proto), and will
+invoke wsdiff at the end of the build. The list of changed objects will be reported
+in the nightly mail message, and a results file "wsdiff_results" will appear in the
+nightly log area.
+.PP
+\fBExample 5: Influencing the level of paralelism\fR
+.PP
+wsdiff spawns a number of threads by default after it determines the list
+of files for comparison. Default number of threads is based on the number of
+on-line CPUs present in the system. To set the number of threads for processing
+to some other value the DMAKE_MAX_JOBS environment variable can be used:
+.LP
+.nf
+$ DMAKE_MAX_JOBS=24 wsdiff proto_base proto_patch
+.fi
+.PP
+Note that this variable is also used for nightly(1ONBLD) so when run from
+nightly(1ONBLD), wsdiff will honor the setting.
+.LP
+.SH SEE ALSO
+.LP
+.IR nightly(1ONBLD),
+.IR elfdump(1),
--- old/usr/src/tools/scripts/xref.1	Wed Sep 30 19:35:42 2015
+++ /dev/null	Wed Sep 30 19:25:04 2015
@@ -1,167 +0,0 @@
-.\" " CDDL HEADER START
-.\" "
-.\" " The contents of this file are subject to the terms of the
-.\" " Common Development and Distribution License (the "License").
-.\" " You may not use this file except in compliance with the License.
-.\" "
-.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
-.\" " or http://www.opensolaris.org/os/licensing.
-.\" " See the License for the specific language governing permissions
-.\" " and limitations under the License.
-.\" "
-.\" " When distributing Covered Code, include this CDDL HEADER in each
-.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
-.\" " If applicable, add the following below this CDDL HEADER, with the
-.\" " fields enclosed by brackets "[]" replaced with your own identifying
-.\" " information: Portions Copyright [yyyy] [name of copyright owner]
-.\" "
-.\" " CDDL HEADER END
-.\" "
-.\" "Copyright 2009 Sun Microsystems, Inc.  All rights reserved."
-.\" "Use is subject to license terms."
-.TH xref 1 "10 Aug 2009"
-.SH NAME
-.I xref
-\- build and maintain source cross-references
-.SH SYNOPSIS
-\fBxref [-cfp] [-m <makefile>] [-x cscope|ctags|etags[,...]] [<subtree> ...]\fP
-.LP
-.SH DESCRIPTION
-.IX "OS-Net build tools" "xref" "" "\fBxref\fP"
-.LP
-.I xref
-is a simple tool for building and maintaining source cross-references for
-subtrees of a workspace.  By default, xref builds cscope-fast, ctags, and
-etags (if available; see NOTES) source cross-references for all of the
-eligible files underneath each named subtree, plus any additional eligible
-files reported by flg.flp(1).  File eligibility is determined by pattern
-matching -- by default, files matching the following patterns are
-eligible:
-
-	*.[Ccdshlxy] Makefile* *.il* *.cc llib-* *.xml *.dtd.* *.ndl
-
-However, this default behavior can be changed, either through command-line
-options or by setting the cross-reference customization macros (see
-\fICUSTOMIZATION MACROS\fP) in the Makefile rooted at each specified
-subtree.
-.LP
-Any number of subtrees can be specified; if no subtrees are specified,
-then the current working directory is assumed.  Relative subtrees are
-assumed to be relative to the current working directory.
-.SH OPTIONS
-.TP 10
-.B -c
-Clobber (rather than build) cross-references.
-.TP 10
-.B -f
-Do not use flg.flp(1) to locate additional related files.  This option is
-ignored if \fB-c\fP is specified.
-.TP
-.B -m \fImakefile\fP
-Use the customization macros specified in \fImakefile\fP when building the
-cross-reference, rather than those in Makefile.  If no Makefile exists
-or no customizations are desired, then /dev/null may be used.
-.TP 10
-.B -p
-Remove any proto-area include directories from the include path list when
-building the cross-reference.  This is chiefly useful when the built
-cross-reference will be shared with others that either cannot or should
-not access the proto areas associated with the workspace used to construct
-the cross-reference. This option is ignored if \fB-c\fP is specified.
-.TP 10
-.B -x cscope|tags|etags
-Operate on only the specified cross-references.  More than one
-cross-reference can be operated on by specifying a comma-separated list
-(see \fIEXAMPLES\fP).  By default, all supported cross-references are
-operated on.
-.SH CUSTOMIZATION MACROS
-The xref tool uses a private Makefile, xref.mk, to perform the actual
-construction and maintenance of each cross-reference.  While the logic in
-xref.mk is sufficient for most situations, some subtrees of a workspace
-may require additional fine-tuning (e.g., to exclude machine-generated
-source files, or to include source files with unusual filenames).  To
-accomodate this, xref.mk itself \fBincludes\fP the the file named
-\fIMakefile\fP (or the filename specified via -m) at the root of each
-specified subtree.  This Makefile in turn may customize the
-cross-reference by setting any of the following macros:
-.LP
-.B XRDIRS
-.RS 4
-The list of directories to build the cross-reference over; defaults to
-`.'.  Directories containing source files most likely to be of interest to
-those using the cross-reference should be listed earlier.
-.RE
-.LP
-.B XRPRUNE
-.RS 4
-The list of directories to prune out.
-.RE
-.LP
-.B XRADD
-.RS 4
-The list of additional filename patterns to include.
-.RE
-.LP
-.B XRDEL
-.RS 4
-The list of additional filename patterns to exclude.
-.RE
-.LP
-XRINCDIRS
-.RS 4
-The list of additional include paths, in "foo bar" format.
-.RE
-.LP
-.B XRINCS
-.RS 4
-The list of additional include paths, in "-Ifoo -Ibar" format.
-.RE
-.SH EXAMPLES
-Build cscope-fast, ctags, and etags cross-references for the subtree
-rooted at the current working directory:
-.LP
-$ xref
-.LP
-Build cscope-fast, ctags, and etags cross-references for $SRC/cmd/agents:
-.LP
-$ xref $SRC/cmd/agents
-.LP
-Build just the cscope-fast cross-reference for $SRC, and do not use
-flg.flp(1) (since there are no additional source files to find):
-.LP
-$ xref -f -x cscope $SRC
-.LP
-Build just the standard cscope cross-reference for $SRC/uts:
-.LP
-$ CSCOPE=cscope CSFLAGS=-b xref -x cscope $SRC/uts
-.LP
-Build a cscope database containing just the ZFS source:
-.LP
-.nf
-$ cd $SRC
-$ cat > /tmp/zfs.mk
-XRDIRS=uts/common/fs/zfs common/zfs lib/libzfs cmd/zfs cmd/zpool
-.fi
-$ xref -f -x cscope -m /tmp/zfs.mk
-.LP
-.SH ENVIRONMENT VARIABLES
-Because xref uses xref.mk to carry out the requested operations and
-invokes make(1) with the -e option, the value of any macros used by
-xref.mk can be overridden through environment variables.  This is 
-chiefly useful for customizing the programs used to build the cross
-references; see \fIEXAMPLES\fP.
-.LP
-.SH SEE ALSO
-.LP
-.IR make(1),
-.IR bringover(1),
-.IR flg.flp(1)
-.SH NOTES
-The etags utility is no longer bundled with the Sun Studio, which
-means it may not be available on all developer systems.  If xref cannot
-locate the etags utility and the -x option has not been specified, then
-xref will silently not build etags.
-.LP
-The ETAGS environment variable can be used to specify an alternate
-path to the etags utility.  For instance, to use the one included with
-SUNWgnu-emacs, set ETAGS to /usr/gnu/bin/etags prior to invoking xref.
--- /dev/null	Wed Sep 30 19:25:04 2015
+++ new/usr/src/tools/scripts/xref.1onbld	Wed Sep 30 19:35:42 2015
@@ -0,0 +1,167 @@
+.\" " CDDL HEADER START
+.\" "
+.\" " The contents of this file are subject to the terms of the
+.\" " Common Development and Distribution License (the "License").
+.\" " You may not use this file except in compliance with the License.
+.\" "
+.\" " You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
+.\" " or http://www.opensolaris.org/os/licensing.
+.\" " See the License for the specific language governing permissions
+.\" " and limitations under the License.
+.\" "
+.\" " When distributing Covered Code, include this CDDL HEADER in each
+.\" " file and include the License file at usr/src/OPENSOLARIS.LICENSE.
+.\" " If applicable, add the following below this CDDL HEADER, with the
+.\" " fields enclosed by brackets "[]" replaced with your own identifying
+.\" " information: Portions Copyright [yyyy] [name of copyright owner]
+.\" "
+.\" " CDDL HEADER END
+.\" "
+.\" "Copyright 2009 Sun Microsystems, Inc.  All rights reserved."
+.\" "Use is subject to license terms."
+.TH xref 1ONBLD "10 Aug 2009"
+.SH NAME
+.I xref
+\- build and maintain source cross-references
+.SH SYNOPSIS
+\fBxref [-cfp] [-m <makefile>] [-x cscope|ctags|etags[,...]] [<subtree> ...]\fP
+.LP
+.SH DESCRIPTION
+.IX "OS-Net build tools" "xref" "" "\fBxref\fP"
+.LP
+.I xref
+is a simple tool for building and maintaining source cross-references for
+subtrees of a workspace.  By default, xref builds cscope-fast, ctags, and
+etags (if available; see NOTES) source cross-references for all of the
+eligible files underneath each named subtree, plus any additional eligible
+files reported by flg.flp(1ONBLD).  File eligibility is determined by pattern
+matching -- by default, files matching the following patterns are
+eligible:
+
+	*.[Ccdshlxy] Makefile* *.il* *.cc llib-* *.xml *.dtd.* *.ndl
+
+However, this default behavior can be changed, either through command-line
+options or by setting the cross-reference customization macros (see
+\fICUSTOMIZATION MACROS\fP) in the Makefile rooted at each specified
+subtree.
+.LP
+Any number of subtrees can be specified; if no subtrees are specified,
+then the current working directory is assumed.  Relative subtrees are
+assumed to be relative to the current working directory.
+.SH OPTIONS
+.TP 10
+.B -c
+Clobber (rather than build) cross-references.
+.TP 10
+.B -f
+Do not use flg.flp(1ONBLD) to locate additional related files.  This option is
+ignored if \fB-c\fP is specified.
+.TP
+.B -m \fImakefile\fP
+Use the customization macros specified in \fImakefile\fP when building the
+cross-reference, rather than those in Makefile.  If no Makefile exists
+or no customizations are desired, then /dev/null may be used.
+.TP 10
+.B -p
+Remove any proto-area include directories from the include path list when
+building the cross-reference.  This is chiefly useful when the built
+cross-reference will be shared with others that either cannot or should
+not access the proto areas associated with the workspace used to construct
+the cross-reference. This option is ignored if \fB-c\fP is specified.
+.TP 10
+.B -x cscope|tags|etags
+Operate on only the specified cross-references.  More than one
+cross-reference can be operated on by specifying a comma-separated list
+(see \fIEXAMPLES\fP).  By default, all supported cross-references are
+operated on.
+.SH CUSTOMIZATION MACROS
+The xref tool uses a private Makefile, xref.mk, to perform the actual
+construction and maintenance of each cross-reference.  While the logic in
+xref.mk is sufficient for most situations, some subtrees of a workspace
+may require additional fine-tuning (e.g., to exclude machine-generated
+source files, or to include source files with unusual filenames).  To
+accomodate this, xref.mk itself \fBincludes\fP the the file named
+\fIMakefile\fP (or the filename specified via -m) at the root of each
+specified subtree.  This Makefile in turn may customize the
+cross-reference by setting any of the following macros:
+.LP
+.B XRDIRS
+.RS 4
+The list of directories to build the cross-reference over; defaults to
+`.'.  Directories containing source files most likely to be of interest to
+those using the cross-reference should be listed earlier.
+.RE
+.LP
+.B XRPRUNE
+.RS 4
+The list of directories to prune out.
+.RE
+.LP
+.B XRADD
+.RS 4
+The list of additional filename patterns to include.
+.RE
+.LP
+.B XRDEL
+.RS 4
+The list of additional filename patterns to exclude.
+.RE
+.LP
+XRINCDIRS
+.RS 4
+The list of additional include paths, in "foo bar" format.
+.RE
+.LP
+.B XRINCS
+.RS 4
+The list of additional include paths, in "-Ifoo -Ibar" format.
+.RE
+.SH EXAMPLES
+Build cscope-fast, ctags, and etags cross-references for the subtree
+rooted at the current working directory:
+.LP
+$ xref
+.LP
+Build cscope-fast, ctags, and etags cross-references for $SRC/cmd/agents:
+.LP
+$ xref $SRC/cmd/agents
+.LP
+Build just the cscope-fast cross-reference for $SRC, and do not use
+flg.flp(1ONBLD) (since there are no additional source files to find):
+.LP
+$ xref -f -x cscope $SRC
+.LP
+Build just the standard cscope cross-reference for $SRC/uts:
+.LP
+$ CSCOPE=cscope CSFLAGS=-b xref -x cscope $SRC/uts
+.LP
+Build a cscope database containing just the ZFS source:
+.LP
+.nf
+$ cd $SRC
+$ cat > /tmp/zfs.mk
+XRDIRS=uts/common/fs/zfs common/zfs lib/libzfs cmd/zfs cmd/zpool
+.fi
+$ xref -f -x cscope -m /tmp/zfs.mk
+.LP
+.SH ENVIRONMENT VARIABLES
+Because xref uses xref.mk to carry out the requested operations and
+invokes make(1) with the -e option, the value of any macros used by
+xref.mk can be overridden through environment variables.  This is 
+chiefly useful for customizing the programs used to build the cross
+references; see \fIEXAMPLES\fP.
+.LP
+.SH SEE ALSO
+.LP
+.IR make(1),
+.IR bringover(1ONBLD)
+.IR flg.flp(1ONBLD)
+.SH NOTES
+The etags utility is no longer bundled with the Sun Studio, which
+means it may not be available on all developer systems.  If xref cannot
+locate the etags utility and the -x option has not been specified, then
+xref will silently not build etags.
+.LP
+The ETAGS environment variable can be used to specify an alternate
+path to the etags utility.  For instance, to use the one included with
+SUNWgnu-emacs, set ETAGS to /usr/gnu/bin/etags prior to invoking xref.
