Remove netatm from HEAD as it is not MPSAFE and relies on the now removed

NET_NEEDS_GIANT.  netatm has been disconnected from the build for ten
months in HEAD/RELENG_7.  Specifics:

- netatm include files
- netatm command line management tools
- libatm
- ATM parts in rescue and sysinstall
- sample configuration files and documents
- kernel support as a module or in NOTES
- netgraph wrapper nodes for netatm
- ctags data for netatm.
- netatm-specific device drivers.

MFC after:	3 weeks
Reviewed by:	bz
Discussed with:	bms, bz, harti

10 files changed, 0 insertions, 1521 deletions

diff --git a/share/examples/Makefile b/share/examples/Makefile
index 072f6c8..6e1fb70 100644
--- a/share/examples/Makefile
+++ b/share/examples/Makefile
@@ -34,9 +34,6 @@ LDIRS=	BSD_daemon \
 	startslip \
 	sunrpc
 
-# Disabled in 7.0 as netatm is not MPSAFE.
-#LDIRS+=	atm
-
 XFILES=	BSD_daemon/FreeBSD.pfa \
 	BSD_daemon/README \
 	BSD_daemon/beastie.eps \
@@ -239,17 +236,6 @@ XFILES=	BSD_daemon/FreeBSD.pfa \
 	sunrpc/sort/sort.x \
 	sunrpc/sort/sort_proc.c
 
-# Disabled in 7.0 as netatm is not MPSAFE.
-#XFILES+=	atm/NOTES \
-#	atm/README \
-#	atm/Startup \
-#	atm/atm-config.sh \
-#	atm/atm-sockets.txt \
-#	atm/cpcs-design.txt \
-#	atm/fore-microcode.txt \
-#	atm/sscf-design.txt \
-#	atm/sscop-design.txt
-
 BINDIR= ${SHAREDIR}/examples
 
 NO_OBJ=
diff --git a/share/examples/atm/NOTES b/share/examples/atm/NOTES
deleted file mode 100644
index aad4190..0000000
--- a/share/examples/atm/NOTES
+++ /dev/null
@@ -1,54 +0,0 @@
-
-                                   HARP Notes
-                                   1998-09-14
-
-This is a list of currently known incompatibilities and miscellaneous gotchas 
-in HARP.  
-
-To report new items, please send mail to harp-bugs@magic.net.
-
-================================================================================
-
-
-Efficient Driver and DMA sizes
-==============================
-
-The Efficient adapter moves PDUs between host memory and adapter memory with 
-the help of DMA descriptor lists. Each DMA descriptor consists of two words. 
-Word 0 contains a DMA type identifier and a repetition count. Word 1 contains 
-the physical (not virtual) host buffer address. Each DMA type is really an 
-encoding of the burst size for the DMA. (See /usr/src/sys/dev/hea/eni.h for
-more on the DMA types.) HARP was originally developed using burst sizes of 
-8_WORD, 4_WORD, and 1_WORD sizes. Each DMA request would be built to first 
-move as much data as possible using an 8_WORD burst. This should leave 0-7 
-words left over. If there were more than 3 words remaining, a 4_WORD DMA burst 
-would be scheduled. The remaining data must then be 0-3 words in length and 
-would be moved with 1_WORD bursts. The use of large burst sizes makes more 
-efficient use of DMA by performing the same amount of work in fewer cycles.
-
-Several users have reported problems with DMA which were characterized by error
-messages of the form:
-
-	"eni_output: Transmit drain queue is full. Resources will be lost."
-or
-	"eni_output: not enough room in DMA queue".
-
-It was determined that these systems do not support the use of four- or 
-eight-word DMA bursts.  To resolve this problem, HARP now #ifdef's around the 
-8_WORD and 4_WORD DMA setup and #undef's both values by default. This results 
-in the default operation of the Efficient driver to use only 1_WORD DMA bursts.
-
-If you wish to experiment with larger DMA bursts, you can edit the file
-/usr/src/sys/dev/hea/eni_transmit.c and change the #undef to a #define for 
-DMA_USE_8WORD and/or DMA_USE_4WORD. You will need to rebuild and install your 
-kernel for this change to take effect.
-
-We are exploring solutions which would allow HARP to determine which DMA bursts
-are supported by the system at run-time.  This would allow the Efficient device
-driver to make use of larger, more efficient burst sizes where supported 
-without halting on systems which can't support the larger sizes.
-
-
-
-	@(#) $FreeBSD$
-
diff --git a/share/examples/atm/README b/share/examples/atm/README
deleted file mode 100644
index a2e23f2..0000000
--- a/share/examples/atm/README
+++ /dev/null
@@ -1,140 +0,0 @@
-
-		===================================
-		HARP  |  Host ATM Research Platform
-		===================================
-
-		              HARP 3
-
-
-What is this stuff?
--------------------
-The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center,
-Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed
-the Host ATM Research Platform (HARP) software, which allows IP hosts to
-communicate over ATM networks using standard protocols.  It is intended to
-be a high-quality platform for IP/ATM research.
-
-HARP provides a way for IP hosts to connect to ATM networks.  It supports 
-standard methods of communication using IP over ATM.  A host's standard IP 
-software sends and receives datagrams via a HARP ATM interface.  HARP provides 
-functionality similar to (and typically replaces) vendor-provided ATM device 
-driver software.
-
-HARP includes full source code, making it possible for researchers to
-experiment with different approaches to running IP over ATM.  HARP is 
-self-contained; it requires no other licenses or commercial software packages.
-
-HARP implements support for the IETF Classical IP model for using IP over ATM 
-networks, including:
-
-   o IETF ATMARP address resolution client
-   o IETF ATMARP address resolution server
-   o IETF SCSP/ATMARP server
-   o UNI 3.1 and 3.0 signalling protocols
-   o Fore Systems's SPANS signalling protocol
-
-
-
-What's supported
-----------------
-The following are supported by HARP 3:
-
-   o ATM Host Interfaces
-	- FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters
-	- FORE Systems, Inc. PCA-200E ATM PCI Adapters
-	- Efficient Networks, Inc. ENI-155p ATM PCI Adapters
-
-   o ATM Signalling Protocols
-	- The ATM Forum UNI 3.1 signalling protocol
-	- The ATM Forum UNI 3.0 signalling protocol
-	- The ATM Forum ILMI address registration
-	- FORE Systems's proprietary SPANS signalling protocol
-	- Permanent Virtual Channels (PVCs)
-
-   o IETF "Classical IP and ARP over ATM" model
-	- RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
-	- RFC 1577, "Classical IP and ARP over ATM"
-	- RFC 1626, "Default IP MTU for use over ATM AAL5"
-	- RFC 1755, "ATM Signaling Support for IP over ATM"
-	- RFC 2225, "Classical IP and ARP over ATM"
-	- RFC 2334, "Server Cache Synchronization Protocol (SCSP)"
-	- Internet Draft draft-ietf-ion-scsp-atmarp-00.txt,
-		"A Distributed ATMARP Service Using SCSP"
-
-   o ATM Sockets interface
-	- The file atm-sockets.txt contains further information
-
-
-What's not supported
---------------------
-The following major features of the above list are not currently supported:
-
-	o UNI point-to-multipoint support
-	o Driver support for Traffic Control/Quality of Service
-	o SPANS multicast and MPP support
-	o SPANS signalling using Efficient adapters
-
-
-For further information
------------------------
-For additional information about HARP, please see:
-
-	http://www.msci.magic.net
-
-
-Suggestions and Problem Reports
--------------------------------
-While HARP is made available "as is" and is not supported, ANG is continuing
-development of HARP.  We welcome suggestions for new or enhanced features, 
-summaries of your experience with HARP, as well as reports of problems which
-you may experience.  Feel free to contact us at harp-bugs@magic.net.
-
-ANG is maintaining a mail list of those who wish to share their experiences
-with HARP, learn of others' experiences, or receive information about future 
-releases of HARP.  The HARP mailing list is at harp@magic.net.  To be added
-to the list, send email to harp-request@magic.net.
-
-
-Acknowledgments
----------------
-This software was developed under the sponsorship of the Defense Advanced 
-Research Projects Agency (DARPA).
-
-
-Citing HARP
------------
-When citing HARP in published works, please use the following citation:
-
-Host ATM Research Platform (HARP), Network Computing Services, Inc.
-This software was developed with the support of the Defense Advanced
-Research Projects Agency (DARPA).
-
-
-Copyright and Permitted Use
----------------------------
-The Host ATM Research Platform ("HARP") software (the "Software") is
-made available by Network Computing Services, Inc. ("NetworkCS")
-"AS IS".  NetworkCS does not provide maintenance, improvements or
-support of any kind.
-
-NETWORKCS MAKES NO WARRANTIES OR REPRESENTATIONS, EXPRESS OR IMPLIED,
-INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY
-AND FITNESS FOR A PARTICULAR PURPOSE, AS TO ANY ELEMENT OF THE
-SOFTWARE OR ANY SUPPORT PROVIDED IN CONNECTION WITH THIS SOFTWARE.
-In no event shall NetworkCS be responsible for any damages, including
-but not limited to consequential damages, arising from or relating to
-any use of the Software or related support.
-
-Copyright 1994-1998 Network Computing Services, Inc.
-
-Copies of this Software may be made, however, the above copyright
-notice must be reproduced on all copies.
-
-Portions of this Software include materials copyrighted by the Regents of
-the University of California and by Sun Microsystems, Inc.  The applicable
-copyright notices are reproduced in the files where the material appears.
-
---------------------------------------------------------------------------------
-
-	@(#) $FreeBSD$
-
diff --git a/share/examples/atm/Startup b/share/examples/atm/Startup
deleted file mode 100644
index 8898e45..0000000
--- a/share/examples/atm/Startup
+++ /dev/null
@@ -1,127 +0,0 @@
-HARP ATM Startup Configuration Instructions
-===========================================
-
-The following steps are required in order to use the HARP ATM software.
-See the file atm-config.sh for an example ATM startup script.
-
-1.  Each ATM physical interface must be configured with one or more network
-    interfaces.  The physical interfaces are named:
-
-	FORE Systems: hfa0, hfa1, ...
-	Efficient Networks: hea0, hea1, ...
-
-    The network interface names and the number of network interfaces for a
-    particular physical interface are specified via the atm command.  The
-    network interface name prefix may be any alphabetic string, but the 
-    generated network interface names must be unique amongst all network
-    interfaces, including non-ATM interfaces.
-
-    To configure the network interfaces, type:
-
-	atm set netif <interface_name> <netif_prefix> <netif_count>
-
-    For example, the command:
-
-	atm set netif hfa0 ni 3
-
-    will generate the network interfaces ni0, ni1 and ni2 on the physical
-    interface hfa0.
-
-    For further details, see the man page atm(8).
-
-
-2.  Each ATM network interface (netif) must be configured with an IP network
-    address.  Each network interface must be on a different IP subnet.
-
-    To configure the network interface, type:
-
-	ifconfig <netif_name> <IP_address> up
-
-
-3.  Each ATM physical interface must have a signalling manager attached.  The
-    interfaces may have the same or different signalling managers.
- 
-    To attach a signalling manager, type:
-
-	atm attach <interface_name> <signalling_manager_name>
-
-	where <signalling_manager_name> may be:
-
-		sigpvc - to only support PVCs on the interface;
-		spans - to run FORE Systems SPANS signalling protocol across 
-			the interface, plus support of PVCs;
-		uni30 - to run ATM Forum UNI 3.0 signalling protocol across 
-			the interface, plus support of PVCs;
-		uni31 - to run ATM Forum UNI 3.1 signalling protocol across 
-			the interface, plus support of PVCs;
-
-    For further details, see the man page atm(8).
-
-
-4.  Each of the host's PVCs (if any) must be defined.  
- 
-    To define a PVC, type:
-
-	atm add pvc <interface_name> <vpi> <vci> <aal> <encaps> <owner> ....
-
-	where <interface_name> is the name of the ATM physical interface 
-			over which the PVC is being defined;
-	      <vpi> is the VPI value for the PVC;
-	      <vci> is the VCI value for the PVC;
-	      <aal> is the AAL type which the PVC endpoints will use;
-	      <encaps> is the encapsulation which the PVC endpoints will use;
-	      <owner> specifies the the owner of the PVC, which may be:
-			ip - the PVC is used for IP traffic;
-
-	additional parameters may be required, depending on the PVC owner:
-
-	for owner=ip,
-	      <netif_name> is the name of the PVC's network interface;
-	      <dst> specifies the IP address at the remote end of this PVC;
-
-    For further details, see the man page atm(8).
-
-
-5.  HARP includes an ILMI daemon, which will perform host address registration
-    with the ATM switch for ATM Forum UNI interfaces.  If ILMI support is
-    available and activated in the ATM switch and the ILMI daemon is running
-    (see ilmid(8)), no further registration procedures are required.  
-    The 'atm set prefix' command is not needed in this case.
-
-    If ILMI address registration support is not available or activated, then
-    the host must be manually registered with its switch.  There should be
-    a user command available on the switch in order to do the registration.
-
-    For example, if you are using a FORE Systems switch, you should enter
-    the following AMI command:
-
-	> conf nsap route new <host_nsap> 152 <switch_port> 0 
-
-    If you are using a Cisco LightStream 1010 switch, you would use the
-    following configuration command:
-
-       > atm route <host_nsap> atm <atm_interface_#> internal
-
-    For ATM Forum UNI interfaces, the 'atm set prefix' command must also
-    be issued when not using ILMI address registration.
-
-
-6.  HARP includes support for the Server Cache Synchronization Protocol (SCSP),
-    which can synchronize the ATMARP caches of multiple ATMARP servers.
-    Obviously, this is only useful on hosts which are ATMARP servers.
-
-    To run SCSP between servers, two daemons, scspd and atmarpd, must be
-    started.  Scspd implements the SCSP protocol and atmarpd provides an
-    interface between scspd and the ATMARP server in the kernel.  Scspd
-    requires a configuration file.  It will look for a configuration
-    file at /etc/scspd.conf unless told otherwise.
-    
-    An example of commands to start the two daemons is:
-
-	# scspd
-	# atmarpd <netif>
-
-    See the man pages scspd(8) and atmarpd(8) for further information.
-
-	@(#) $FreeBSD$
-
diff --git a/share/examples/atm/atm-config.sh b/share/examples/atm/atm-config.sh
deleted file mode 100755
index b15060e..0000000
--- a/share/examples/atm/atm-config.sh
+++ /dev/null
@@ -1,88 +0,0 @@
-#! /bin/sh
-#
-#
-# ===================================
-# HARP  |  Host ATM Research Platform
-# ===================================
-#
-#
-# This Host ATM Research Platform ("HARP") file (the "Software") is
-# made available by Network Computing Services, Inc. ("NetworkCS")
-# "AS IS".  NetworkCS does not provide maintenance, improvements or
-# support of any kind.
-#
-# NETWORKCS MAKES NO WARRANTIES OR REPRESENTATIONS, EXPRESS OR IMPLIED,
-# INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY
-# AND FITNESS FOR A PARTICULAR PURPOSE, AS TO ANY ELEMENT OF THE
-# SOFTWARE OR ANY SUPPORT PROVIDED IN CONNECTION WITH THIS SOFTWARE.
-# In no event shall NetworkCS be responsible for any damages, including
-# but not limited to consequential damages, arising from or relating to
-# any use of the Software or related support.
-#
-# Copyright 1994-1998 Network Computing Services, Inc.
-#
-# Copies of this Software may be made, however, the above copyright
-# notice must be reproduced on all copies.
-#
-#	@(#) $FreeBSD$
-#
-#
-
-#
-# Sample script to load and configure ATM software
-#
-
-#
-# Download FORE microcode into adapter(s)
-#
-# This step is only required if you are using FORE ATM adapters.
-# This assumes that the FORE microcode file pca200e.bin is in /etc.
-# See the file fore-microcode.txt for further details.
-#
-/sbin/fore_dnld -d /etc
-
-#
-# Define network interfaces
-#
-/sbin/atm set netif hfa0 <netif_prefix> 1
-
-#
-# Configure physical interfaces
-#
-/sbin/atm attach hfa0 uni31
-
-#
-# Start ILMI daemon (optional)
-#
-/sbin/ilmid
-
-#
-# Set ATM address prefix
-#
-# Only need to set prefix if using UNI and not using ILMI daemon
-#
-#/sbin/atm set prefix hfa0 <nsap_prefix>
-
-#
-# Configure network interfaces
-#
-/sbin/ifconfig <netif> <ip_addr> netmask + up
-/sbin/atm set arpserver <netif> <atm_address>
-
-#
-# Configure PVCs (optional)
-#
-#/sbin/atm add pvc hfa0 <vpi> <vci> aal5 null ip <netif> <ip_addr>
-
-#
-# Start SCSP daemons (optional)
-#
-# This step is only required if your host is configured as an ATMARP server
-# and you wish to synchronize its cache with the cache(s) of some other
-# server(s).  Scspd will look for its configuration file at /etc/scspd.conf.
-#
-#/usr/sbin/scspd
-#/usr/sbin/atmarpd <netif> ...
-
-exit 0
-
diff --git a/share/examples/atm/atm-sockets.txt b/share/examples/atm/atm-sockets.txt
deleted file mode 100644
index b4cc8e9..0000000
--- a/share/examples/atm/atm-sockets.txt
+++ /dev/null
@@ -1,572 +0,0 @@
-
-	HARP Native ATM Sockets API
-	===========================
-
-ATM sockets are an extension to the traditional BSD sockets API to allow
-direct user-level access to native ATM protocol services.  The ATM sockets
-extensions are implemented via the addition of a new protocol family (PF_ATM)
-and a new socket address structure (struct sockaddr_atm).  
-
-The HARP implementation of native ATM sockets capabilities is intended to be
-conformant with The Open Group specifications (with known differences listed 
-below) as defined in the following document:
-
-	The Open Group: Networking Services (XNS) Issue 5 
-		ISBN 1-85912-165-9
-		http://www.rdg.opengroup.org/public/pubs/catalog/c523.htm
-
-And in particular, it is based on the following ATM-specific sections in the
-above document:
-
-	ATM Transport Protocol Information for Sockets
-	ATM Transport Protocol Information for XTI
-	ATM Transport Headers
-
-The ATM sockets API is an implementation based on the definitions and
-descriptions set forth in the following document:
-
-	The ATM Forum: Native ATM Services: Semantic Description, Version 1.0
-		af-saa-0048.000
-		http://www.atmforum.com/atmforum/specs/approved.html
-
-
-Using the HARP Implementation
------------------------------
-This document only provides the HARP-specific information necessary for using 
-the ATM sockets API.  Please refer to the XNS document described above for
-all of the general interface specifications.  There is also sample source
-code for an ATM sockets application included at the end of this document.
-
-All user definitions for the HARP ATM sockets implementation are contained
-in the file /usr/include/netatm/atm.h.  This file must be included in the
-user's C program source file.  In this file, all HARP extensions to the base 
-XNS specifications are denoted with a comment string of "XNS_EXT".
-
-
-HARP Extensions to XNS Issue 5
-------------------------------
-o Socket address structure for ATM addresses
-
-  An ATM socket address structure was not specifically defined by XNS,
-  although the t_atm_sap structure was defined to be used as an ATM protocol
-  address.  Thus, HARP has defined an ATM socket address (using address
-  family AF_ATM) as a 'struct sockaddr_atm', which contains 'struct t_atm_sap'
-  as the protocol address.  This structure (properly cast) must be used on
-  all ATM socket system calls requiring a 'struct sockaddr' parameter.
-
-o Network Interface Selection socket option (T_ATM_NET_INTF)
-
-  This option is used to specify the name of the network interface to be
-  used to route an outgoing ATM call using a socket connection.  This option
-  is only needed when there are multiple ATM network interfaces defined on a
-  system.  If this option is not set, then the first network interface on
-  the first physical ATM interface defined will be used.
-
-  See the sample application below for an example of the use of this option.
-
-o LLC Multiplexing socket option (T_ATM_LLC)
-
-  For LLC encapsulated VCCs (BLLI Layer 2 Protocol == T_ATM_BLLI2_I8802),
-  HARP has implemented an LLC multiplexing facility.  In order to use this
-  multiplexing facility, a user must issue a setsockopt() call specifying the 
-  T_ATM_LLC option before the connect() or listen() system call is invoked.
-
-  If using the LLC multiplexor, the user will only receive PDUs which match
-  the LLC header information specified in the socket option.  The kernel 
-  multiplexing software will strip the LLC header from all inbound PDUs and 
-  add the specified LLC header to all outgoing PDUs - the user will never see 
-  the LLC header.  
-
-  For listening sockets, the listener will be notified for all incoming LLC 
-  calls (which also meet the other incoming call distribution selection 
-  criteria), since the LLC header information is only carried in the data 
-  PDUs, not in the signalling protocol.
-
-  The T_ATM_LLC_SHARING flag is used to denote whether this user wishes to
-  share the VCC with other LLC users requesting similar connection attributes 
-  to the same destination.
-
-o Application Name socket option (T_ATM_APP_NAME)
-
-  This option is used to associate an identifier string (typically, the
-  application's name) with an open ATM socket.  Currently, it is only used 
-  for the "Owner" field in the output of the 'atm show vcc' command.  If this 
-  option is not set, then the "Owner" field will default to "(AAL5)". 
-
-  See the sample application below for an example of the use of this option.
-
-o PVC support
-
-  The XNS document specifically does not provide support for ATM PVCs.
-  However, due in part to internal HARP requirements (the ILMI daemon), PVC
-  sockets are supported under the HARP implementation. 
-
-  To support PVC sockets, there is a new address format (T_ATM_PVC_ADDR) and
-  address definition (Atm_addr_pvc).   Since there is no actual signalling
-  involved in setting up a PVC, a PVC socket connection only defines the
-  local socket-to-pvc connection - the remainder of the virtual circuit through
-  the ATM network to the remote endpoint must be defined independent of the
-  local socket creation.  PVC socket connections are only allowed via the
-  connect() system call - listen()/accept() sockets cannot be supported.
-  Also, since there are no circuit parameters signalled, most of the 
-  setsockopt() options are silently ignored.
-
-o SPANS support
-
-  HARP has added ATM socket support for the FORE-proprietary SPANS address 
-  format (T_ATM_SPANS_ADDR).  A SPANS socket can only be established over 
-  an ATM physical interface which is using the SPANS signalling manager.
-  There is limited ATM socket option support - the socket options can be set, 
-  but most are silently ignored, since they are not applicable to the SPANS 
-  protocols.  The SPANS socket address support has not been thoroughly tested.
-
-o Miscellaneous user convenience typedefs, macros and defines
-
-
-XNS Issue 5 Features Not Supported in HARP
-------------------------------------------
-o ATM_PROTO_SSCOP
-
-  The socket protocol for reliable data transport (ATM_PROTO_SSCOP) is not
-  supported in this HARP release.  There is some initial skeleton code for
-  SSCOP support, but it was not completed.
-
-o Multipoint connections
-
-  The core HARP code does not provide support for multipoint connections, so,
-  obviously, multipoint socket connections are also not supported.  
-
-  The non-supported socket options are:
-	o T_ATM_ADD_LEAF
-	o T_ATM_DROP_LEAF
-	o T_ATM_LEAF_IND
-
-  The non-supported socket option values are:
-	o For the T_ATM_BEARER_CAP socket option:
-		o connection_configuration == T_ATM_1_TO_MANY
-
-
-Example ATM Socket Application
-------------------------------
-The following are simple example client and server applications using the ATM 
-socket API.
-
-/*
- * ATM API sample client application
- *
- * This application will open an ATM socket to a server, send a text string 
- * in a PDU and then read one PDU from the socket and print its contents.
- *
- */
-#include <stdio.h>
-#include <sys/param.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <net/if.h>
-#include <netatm/atm.h>
-
-#define	MAX_LEN		4096	/* Maximum PDU length */
-#define	MY_ID		11	/* BLLI Layer 2 protocol */
-#define MY_APPL		"Client"
-
-Atm_addr_nsap	dst_addr = {
-	0x47,
-#error FIX ME: Replace the 2 lines below with your nsap prefix and esi address
-	{0x00,0x05,0x80,0xff,0xdc,0x00,0x00,0x00,0x00,0x02,0xff,0xff},
-	{0x11,0x22,0x33,0x44,0x55,0x66},
-	0x00
-};
-
-static char	message[] = "A message from the client";
-
-void
-print_cause(int s)
-{
-	struct	t_atm_cause	cause;
-	int	optlen;
-
-	optlen = sizeof(cause);
-	if (getsockopt(s, T_ATM_SIGNALING, T_ATM_CAUSE, &cause, &optlen) < 0) {
-		perror("getsockopt(cause)");
-		return;
-	}
-	
-	fprintf(stderr, "Cause: coding=%d loc=%d cause=%d diag=(%d,%d,%d,%d)\n",
-		cause.coding_standard, cause.location, cause.cause_value,
-		cause.diagnostics[0], cause.diagnostics[1], 
-		cause.diagnostics[2], cause.diagnostics[3]);
-}
-
-main(argc, argv)
-	int	argc;
-	char	**argv;
-{
-	struct sockaddr_atm	satm;
-	struct t_atm_aal5	aal5;
-	struct t_atm_traffic	traffic;
-	struct t_atm_bearer	bearer;
-	struct t_atm_qos	qos;
-	struct t_atm_net_intf	netintf;
-	struct t_atm_app_name	appname;
-	char	buffer[MAX_LEN+1];
-	int	s, n, optlen;
-
-	/*
-	 * Create socket
-	 */
-	s = socket(AF_ATM, SOCK_SEQPACKET, ATM_PROTO_AAL5);
-	if (s < 0) {
-		perror("socket");
-		exit(1);
-	}
-
-	/*
-	 * Set up destination SAP
-	 */
-	bzero((caddr_t) &satm, sizeof(satm));
-	satm.satm_family = AF_ATM;
-#if (defined(BSD) && (BSD >= 199103))
-	satm.satm_len = sizeof(satm);
-#endif
-	/* Destination ATM address */
-	satm.satm_addr.t_atm_sap_addr.SVE_tag_addr = T_ATM_PRESENT;
-	satm.satm_addr.t_atm_sap_addr.SVE_tag_selector = T_ATM_PRESENT;
-	satm.satm_addr.t_atm_sap_addr.address_format = T_ATM_ENDSYS_ADDR;
-	satm.satm_addr.t_atm_sap_addr.address_length = sizeof(Atm_addr_nsap);
-	bcopy((caddr_t)&dst_addr,
-		(caddr_t)satm.satm_addr.t_atm_sap_addr.address,
-		sizeof(dst_addr));
-
-	/* BLLI Layer-2 protocol */
-	satm.satm_addr.t_atm_sap_layer2.SVE_tag = T_ATM_PRESENT;
-	satm.satm_addr.t_atm_sap_layer2.ID_type = T_ATM_USER_ID; 
-	satm.satm_addr.t_atm_sap_layer2.ID.user_defined_ID = MY_ID; 
-
-	/* BLLI Layer-3 protocol */
-	satm.satm_addr.t_atm_sap_layer3.SVE_tag = T_ATM_ABSENT;
-
-	/* BHLI protocol */
-	satm.satm_addr.t_atm_sap_appl.SVE_tag = T_ATM_ABSENT;
-
-	/*
-	 * Set up connection parameters
-	 */
-	aal5.forward_max_SDU_size = MAX_LEN;
-	aal5.backward_max_SDU_size = MAX_LEN;
-	aal5.SSCS_type = T_ATM_NULL;
-	optlen = sizeof(aal5);
-	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_AAL5, (caddr_t)&aal5,
-			optlen) < 0) {
-		perror("setsockopt(aal5)");
-		exit(1);
-	}
-
-	traffic.forward.PCR_high_priority = T_ATM_ABSENT;
-	traffic.forward.PCR_all_traffic = 100000;
-	traffic.forward.SCR_high_priority = T_ATM_ABSENT;
-	traffic.forward.SCR_all_traffic = T_ATM_ABSENT;
-	traffic.forward.MBS_high_priority = T_ATM_ABSENT;
-	traffic.forward.MBS_all_traffic = T_ATM_ABSENT;
-	traffic.forward.tagging = T_NO;
-	traffic.backward.PCR_high_priority = T_ATM_ABSENT;
-	traffic.backward.PCR_all_traffic = 100000;
-	traffic.backward.SCR_high_priority = T_ATM_ABSENT;
-	traffic.backward.SCR_all_traffic = T_ATM_ABSENT;
-	traffic.backward.MBS_high_priority = T_ATM_ABSENT;
-	traffic.backward.MBS_all_traffic = T_ATM_ABSENT;
-	traffic.backward.tagging = T_NO;
-	traffic.best_effort = T_YES;
-	optlen = sizeof(traffic);
-	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_TRAFFIC, (caddr_t)&traffic,
-			optlen) < 0) {
-		perror("setsockopt(traffic)");
-		exit(1);
-	}
-
-	bearer.bearer_class = T_ATM_CLASS_X;
-	bearer.traffic_type = T_ATM_NULL;
-	bearer.timing_requirements = T_ATM_NULL;
-	bearer.clipping_susceptibility = T_NO;
-	bearer.connection_configuration = T_ATM_1_TO_1;
-	optlen = sizeof(bearer);
-	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_BEARER_CAP, (caddr_t)&bearer,
-			optlen) < 0) {
-		perror("setsockopt(bearer)");
-		exit(1);
-	}
-
-	qos.coding_standard = T_ATM_NETWORK_CODING;
-	qos.forward.qos_class = T_ATM_QOS_CLASS_0;
-	qos.backward.qos_class = T_ATM_QOS_CLASS_0;
-	optlen = sizeof(qos);
-	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_QOS, (caddr_t)&qos,
-			optlen) < 0) {
-		perror("setsockopt(qos)");
-		exit(1);
-	}
-
-#ifdef REMOVE_TO_USE_NET_INTF
-#error FIX ME: Replace the ni0 below with the local atm network interface name
-	strncpy(netintf.net_intf, "ni0", IFNAMSIZ);
-	optlen = sizeof(netintf);
-	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_NET_INTF, (caddr_t)&netintf,
-			optlen) < 0) {
-		perror("setsockopt(net_intf)");
-		exit(1);
-	}
-#endif
-
-	strncpy(appname.app_name, MY_APPL, T_ATM_APP_NAME_LEN);
-	optlen = sizeof(appname);
-	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_APP_NAME, (caddr_t)&appname,
-			optlen) < 0) {
-		perror("setsockopt(app_name)");
-		exit(1);
-	}
-
-	/*
-	 * Now try to connect to destination
-	 */
-	if (connect(s, (struct sockaddr *) &satm, sizeof(satm)) < 0) {
-		perror("connect");
-		print_cause(s);
-		exit(1);
-	}
-
-	/*
-	 * Exchange message with peer
-	 */
-	if (write(s, message, sizeof(message)) != sizeof(message)) {
-		perror("write");
-		exit(1);
-	}
-
-	if ((n = read(s, buffer, MAX_LEN)) < 0) {
-		perror("read");
-		exit(1);
-	}
-
-	buffer[n] = '\0';
-	printf("received %d bytes: <%s>\n", n, buffer);
-
-	/*
-	 * Finish up
-	 */
-	if (close(s) < 0) {
-		perror("close");
-		exit(1);
-	}
-
-	exit(0);
-}
-
-
-
-/*
- * ATM API sample server application
- *
- * This application will loop forever listening for connections on an ATM 
- * socket.  When a new connection arrives, it will send a string in a PDU,
- * read one PDU from the socket and print its contents.
- *
- */
-#include <stdio.h>
-#include <sys/param.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <net/if.h>
-#include <netatm/atm.h>
-
-#define	MAX_LEN		4096	/* Maximum PDU length */
-#define	MY_ID		11	/* BLLI Layer 2 protocol */
-#define MY_APPL		"Server"
-
-static char	message[] = "A message from the server";
-
-void
-print_cause(int s)
-{
-	struct	t_atm_cause	cause;
-	int	optlen;
-
-	optlen = sizeof(cause);
-	if (getsockopt(s, T_ATM_SIGNALING, T_ATM_CAUSE, &cause, &optlen) < 0) {
-		perror("getsockopt(cause)");
-		return;
-	}
-	
-	fprintf(stderr, "Cause: coding=%d loc=%d cause=%d diag=(%d,%d,%d,%d)\n",
-		cause.coding_standard, cause.location, cause.cause_value,
-		cause.diagnostics[0], cause.diagnostics[1], 
-		cause.diagnostics[2], cause.diagnostics[3]);
-}
-
-main(argc, argv)
-	int	argc;
-	char	**argv;
-{
-	struct sockaddr_atm	satm;
-	struct t_atm_aal5	aal5;
-	struct t_atm_traffic	traffic;
-	struct t_atm_bearer	bearer;
-	struct t_atm_qos	qos;
-	struct t_atm_net_intf	netintf;
-	struct t_atm_app_name	appname;
-	char	buffer[MAX_LEN+1];
-	int	s, n, optlen;
-
-	/*
-	 * Create socket
-	 */
-	s = socket(AF_ATM, SOCK_SEQPACKET, ATM_PROTO_AAL5);
-	if (s < 0) {
-		perror("socket");
-		exit(1);
-	}
-
-	/*
-	 * Set up destination SAP
-	 */
-	bzero((caddr_t) &satm, sizeof(satm));
-	satm.satm_family = AF_ATM;
-#if (defined(BSD) && (BSD >= 199103))
-	satm.satm_len = sizeof(satm);
-#endif
-	/* Destination ATM address */
-	satm.satm_addr.t_atm_sap_addr.SVE_tag_addr = T_ATM_ANY;
-	satm.satm_addr.t_atm_sap_addr.SVE_tag_selector = T_ATM_ANY;
-
-	/* BLLI Layer-2 protocol */
-	satm.satm_addr.t_atm_sap_layer2.SVE_tag = T_ATM_PRESENT;
-	satm.satm_addr.t_atm_sap_layer2.ID_type = T_ATM_USER_ID; 
-	satm.satm_addr.t_atm_sap_layer2.ID.user_defined_ID = MY_ID; 
-
-	/* BLLI Layer-3 protocol */
-	satm.satm_addr.t_atm_sap_layer3.SVE_tag = T_ATM_ABSENT;
-
-	/* BHLI protocol */
-	satm.satm_addr.t_atm_sap_appl.SVE_tag = T_ATM_ABSENT;
-
-	/*
-	 * Set up connection parameters
-	 */
-	aal5.forward_max_SDU_size = MAX_LEN;
-	aal5.backward_max_SDU_size = MAX_LEN;
-	aal5.SSCS_type = T_ATM_NULL;
-	optlen = sizeof(aal5);
-	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_AAL5, (caddr_t)&aal5,
-			optlen) < 0) {
-		perror("setsockopt(aal5)");
-		exit(1);
-	}
-
-	traffic.forward.PCR_high_priority = T_ATM_ABSENT;
-	traffic.forward.PCR_all_traffic = 100000;
-	traffic.forward.SCR_high_priority = T_ATM_ABSENT;
-	traffic.forward.SCR_all_traffic = T_ATM_ABSENT;
-	traffic.forward.MBS_high_priority = T_ATM_ABSENT;
-	traffic.forward.MBS_all_traffic = T_ATM_ABSENT;
-	traffic.forward.tagging = T_NO;
-	traffic.backward.PCR_high_priority = T_ATM_ABSENT;
-	traffic.backward.PCR_all_traffic = 100000;
-	traffic.backward.SCR_high_priority = T_ATM_ABSENT;
-	traffic.backward.SCR_all_traffic = T_ATM_ABSENT;
-	traffic.backward.MBS_high_priority = T_ATM_ABSENT;
-	traffic.backward.MBS_all_traffic = T_ATM_ABSENT;
-	traffic.backward.tagging = T_NO;
-	traffic.best_effort = T_YES;
-	optlen = sizeof(traffic);
-	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_TRAFFIC, (caddr_t)&traffic,
-			optlen) < 0) {
-		perror("setsockopt(traffic)");
-		exit(1);
-	}
-
-	bearer.bearer_class = T_ATM_CLASS_X;
-	bearer.traffic_type = T_ATM_NULL;
-	bearer.timing_requirements = T_ATM_NULL;
-	bearer.clipping_susceptibility = T_NO;
-	bearer.connection_configuration = T_ATM_1_TO_1;
-	optlen = sizeof(bearer);
-	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_BEARER_CAP, (caddr_t)&bearer,
-			optlen) < 0) {
-		perror("setsockopt(bearer)");
-		exit(1);
-	}
-
-	qos.coding_standard = T_ATM_NETWORK_CODING;
-	qos.forward.qos_class = T_ATM_QOS_CLASS_0;
-	qos.backward.qos_class = T_ATM_QOS_CLASS_0;
-	optlen = sizeof(qos);
-	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_QOS, (caddr_t)&qos,
-			optlen) < 0) {
-		perror("setsockopt(qos)");
-		exit(1);
-	}
-
-	strncpy(appname.app_name, MY_APPL, T_ATM_APP_NAME_LEN);
-	optlen = sizeof(appname);
-	if (setsockopt(s, T_ATM_SIGNALING, T_ATM_APP_NAME, (caddr_t)&appname,
-			optlen) < 0) {
-		perror("setsockopt(app_name)");
-		exit(1);
-	}
-
-	/*
-	 * Now try to bind/listen
-	 */
-	if (bind(s, (struct sockaddr *) &satm, sizeof(satm)) < 0) {
-		perror("bind");
-		exit(1);
-	}
-	if (listen(s, 4) < 0) {
-		perror("listen");
-		exit(1);
-	}
-
-	for (; ; ) {
-		struct sockaddr_atm	claddr;
-		int	clsock, cllen;
-
-		/* Wait for incoming call */
-		cllen = sizeof(claddr);
-		clsock = accept(s, (struct sockaddr *) &claddr, &cllen);
-		if (clsock < 0) {
-			perror("accept");
-			exit(1);
-		}
-		printf("Server: new connection\n");
-		
-		/*
-		 * Exchange message with peer
-		 */
-		if (write(clsock, message, sizeof(message)) != sizeof(message)) {
-			perror("write");
-			exit(1);
-		}
-
-		if ((n = read(clsock, buffer, MAX_LEN)) < 0) {
-			perror("read");
-			exit(1);
-		}
-
-		buffer[n] = '\0';
-		printf("received %d bytes: <%s>\n", n, buffer);
-
-		sleep(1);
-
-		/*
-		 * Finish up
-		 */
-		if (close(clsock) < 0) {
-			perror("close");
-			exit(1);
-		}
-	}
-
-	close(s);
-	exit(0);
-}
-
-	@(#) $FreeBSD$
-
diff --git a/share/examples/atm/cpcs-design.txt b/share/examples/atm/cpcs-design.txt
deleted file mode 100644
index 94901f2..0000000
--- a/share/examples/atm/cpcs-design.txt
+++ /dev/null
@@ -1,84 +0,0 @@
-
-	CPCS Design
-	===========
-
-SAP_CPCS Interface
-------------------
-This is the stack SAP interface between an AAL CPCS provider and an AAL CPCS
-user.  The stack commands defined for this interface are modeled after the 
-AAL3/4 and AAL5 protocol specification primitives CPCS-xxx.  See the protocol 
-specification documents referenced below for full descriptions of the CPCS 
-interface.
-
-
-o The following stack commands are sent from a CPCS user to the CPCS provider:
-
-Stack Command:	CPCS_INIT
-Description:	Initialize a SAP instance.  This should be the first stack
-		command issued across the SAP instance after the service stack 
-		has been successfully instantiated.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	CPCS_TERM
-Description:	Terminate a SAP instance.  This must be the last stack command
-		issued across the SAP instance.  The stack instance will be
-		deleted upon completion of this command.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	CPCS_UNITDATA_INV
-Description:	Request that an SDU be sent to the remote AAL user.
-Argument 1:	Pointer to an mbuf chain containing the user SDU.
-		(struct mbuf *)
-Argument 2:	Not used.
-
-
-Stack Command:	CPCS_UABORT_INV
-Description:	Not supported.
-Argument 1:	N/A
-Argument 2:	N/A
-
-
-o The following stack commands are sent from the CPCS provider to a CPCS user:
-
-Stack Command:	CPCS_UNITDATA_SIG
-Description:	Indication that an SDU has been received from the remote AAL 
-		user.
-Argument 1:	Pointer to an mbuf chain containing the peer's SDU.
-		(struct mbuf *)
-Argument 2:	Not used.
-
-
-Stack Command:	CPCS_UABORT_SIG
-Description:	Not supported.
-Argument 1:	N/A
-Argument 2:	N/A
-
-
-Stack Command:	CPCS_PABORT_SIG
-Description:	Not supported.
-Argument 1:	N/A
-Argument 2:	N/A
-
-
-
-Protocol Specifications
------------------------
-See I.363.
-
-
-
-Implementation Limitations
---------------------------
-o The CPCS-LP, CPCS-CI and CPCS-UU parameters are not supported.
-
-o The Streaming Mode service is not supported.
-
-o The Abort service is not supported.
-
-
-	@(#) $FreeBSD$
-
diff --git a/share/examples/atm/fore-microcode.txt b/share/examples/atm/fore-microcode.txt
deleted file mode 100644
index 8abcaf2..0000000
--- a/share/examples/atm/fore-microcode.txt
+++ /dev/null
@@ -1,93 +0,0 @@
-
-HARP and FORE Systems Microcode
-===============================
-
-ATM adapters from FORE Systems use Intel i960 embedded processors and 
-require that application software (herein called "microcode") be downloaded
-and executed on the adapter. The interface between the microcode and the host
-device driver is specified in the FORE ATM Adaptation Layer Interface (AALI) 
-(available from ftp.fore.com:/pub/docs/port). HARP uses microcode supplied 
-by FORE Systems. The HARP device driver for the FORE adapter (hfa) conforms 
-to the AALI specification.
-
-As part of the HARP ATM initialization procedure, the HARP 'fore_dnld' utility
-must be invoked in order to load the microcode file into each FORE adapter.
-However, the microcode file is NOT included in the FreeBSD distribution. It is 
-the user's responsibility to obtain and install the FORE microcode file. Below 
-are notes to assist users in finding and installing microcode known to work
-with HARP. 
-
-FORE microcode files can be obtained from either FORE's web site
-(http://www.fore.com) or the CD distributed with new FORE adapters.
-When using FORE's web site, you must have a valid login to access the
-TACtics Online section of the site. The software download section is
-available via the 'Services & Support'->'TACtics Online'->Software links.
-
-If you are currently using HARP and already have a working microcode file, 
-that microcode will continue to work with this release of HARP.
-
-
-PCA200E
--------
-
-From the FORE web pages, the following PCA200E adapter distributions
-are known to have microcode which will work with HARP:
-
-	pc_adapter->OS/2->archive->os2_4.0.2_1.20.200.zip
-		unzip the file and execute the command:
-
-		cp -p <unzip_directory>/Drivers/PCA200E.BIN /etc/pca200e.bin
-
-	pc_adapter->'Windows NT'->archive->pca2e_12.zip
-		unzip the file and execute the command:
-
-		cp -p <unzip_directory>/NT/I386/PCA200E.BIN /etc/pca200e.bin
-
-
-The following distributions from the FORE web pages are known to have 
-microcode which will NOT work with HARP:
-
-	pc_adapter:
-		OS/2:
-			release:
-				os2_4.1.0_1.74.zip
-		Windows95:
-			archive:
-				pc-w95_5.0.0.16432.zip
-				win95_4.0.3_1.04.200.zip
-				win95_4.1.6_1.16.zip
-			release:
-				pc-w95_4.1.6_27.zip
-		Windows NT:
-			archive:
-				pc-nt_5.0.0_16342.zip
-				winnt_4.0.3_1.05.200.zip
-				winnt_4.1.2_1.27.zip
-				winnt_4.1.6_1.16.zip
-			release:
-				pc-nt_4.1.6_27.zip
-				pc-nt_i386_5.0.0_25096.zip
-
-
-From the "ForeRunner 200E for PC/Mac" distribution CD-ROM, the following 
-PCA200E adapter distributions are known to have microcode which will work 
-with HARP (assuming the CD-ROM is mounted on /cdrom):
-
-	/cdrom/rel4.0/os2/
-		execute the command:
-		
-		cp -p /cdrom/rel4.0/os2/drivers/pca200e.bin /etc/pca200e.bin
-
-
-Note: Windows-based files are supplied in a compressed form. If the
-'fore_dnld' command complains about an unrecognized header format, you should
-try to uncompress the microcode file. To do so, move the file in binary mode
-to a DOS/Windows machine and use the DOS command 'expand' to uncompress the
-file. The command syntax is:
-
-	expand <in-file> <out-file>
-
-Move the resulting <out-file> in binary mode back to the HARP machine as
-/etc/pca200e.bin and try to initialize the ATM system again.
-
-	@(#) $FreeBSD$
diff --git a/share/examples/atm/sscf-design.txt b/share/examples/atm/sscf-design.txt
deleted file mode 100644
index 5334d74..0000000
--- a/share/examples/atm/sscf-design.txt
+++ /dev/null
@@ -1,129 +0,0 @@
-
-	SSCF UNI Design
-	===============
-
-SAP_SSCF_UNI Interface
-----------------------
-This is the stack SAP interface between the UNI signalling layer (eg. Q.2931)
-and the SSCF module.  The stack commands defined for this interface are modeled
-after the SSCF protocol specification primitives AAL-xxx.  See the protocol
-specification documents referenced below for full descriptions of the SSCF UNI
-interface presented to the signalling user.
-
-
-o The following stack commands are sent from the signalling module to SSCF:
-
-Stack Command:	SSCF_UNI_INIT
-Description:	Initialize a SAP instance.  This should be the first stack
-		command issued across the SAP instance after the service stack
-		has been successfully instantiated.
-Argument 1:	Specifies the UNI version to be used for this stack instance.
-		(enum uni_vers)
-Argument 2:	Not used.
-
-
-Stack Command:	SSCF_UNI_TERM
-Description:	Terminate a SAP instance.  This must be the last stack command
-		issued across the SAP instance.  The stack instance will be
-		deleted upon completion of this command.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCF_UNI_ESTABLISH_REQ
-Description:	Request the establishment of an assured SAAL connection to the
-		SAAL peer entity.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCF_UNI_RELEASE_REQ
-Description:	Request the termination of an assured SAAL connection to the
-		SAAL peer entity.
-Argument 1:	Specifies whether future session establishment indications from
-		the SAAL peer should be processed.  Valid values are 
-		SSCF_UNI_ESTIND_YES or SSCF_UNI_ESTIND_NO. (int)
-		Note that this is a local implementation parameter only.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCF_UNI_DATA_REQ
-Description:	Request that an assured SDU be sent to the SAAL peer.
-Argument 1:	Pointer to an mbuf chain containing the user SDU.
-		(struct mbuf *)
-Argument 2:	Not used.
-
-
-Stack Command:	SSCF_UNI_UNITDATA_REQ
-Description:	Request that an unacknowledged SDU be sent to the SAAL peer.
-Argument 1:	Pointer to an mbuf chain containing the user SDU.
-		(struct mbuf *)
-Argument 2:	Not used.
-
-
-o The following stack commands are sent from SSCF to the signalling module:
-
-Stack Command:	SSCF_UNI_ESTABLISH_IND
-Description:	Indication that an assured SAAL connection has been established
-		by the SAAL peer entity.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCF_UNI_ESTABLISH_CNF
-Description:	Confirmation of an assured SAAL connection establishment,
-		previously requested via an SSCF_UNI_ESTABLISH_REQ command.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCF_UNI_RELEASE_IND
-Description:	Indication that an assured SAAL connection has been terminated
-		by the SAAL peer entity.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCF_UNI_RELEASE_CNF
-Description:	Confirmation of an assured SAAL connection termination,
-		previously requested via an SSCF_UNI_RELEASE_REQ command.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCF_UNI_DATA_IND
-Description:	Indication that an assured SDU has been received from the 
-		SAAL peer.
-Argument 1:	Pointer to an mbuf chain containing the peer's SDU.
-		(struct mbuf *)
-Argument 2:	Not used.
-
-
-Stack Command:	SSCF_UNI_UNITDATA_IND
-Description:	Indication that an unacknowledged SDU has been received from 
-		the SAAL peer.
-Argument 1:	Pointer to an mbuf chain containing the peer's SDU.
-		(struct mbuf *)
-Argument 2:	Not used.
-
-
-
-Protocol Specifications
------------------------
-For UNI_VERS_3_0, see Q.SAAL2.
-For UNI_VERS_3_1, see Q.2130.
-
-
-
-Implementation Limitations
---------------------------
-o The Parameter Data parameter is not supported for the following primitives:
-	AAL-ESTABLISH request
-	AAL-ESTABLISH indication
-	AAL-ESTABLISH confirm
-	AAL-RELEASE request
-	AAL-RELEASE indication
-
-
-	@(#) $FreeBSD$
-
diff --git a/share/examples/atm/sscop-design.txt b/share/examples/atm/sscop-design.txt
deleted file mode 100644
index 2b546bd..0000000
--- a/share/examples/atm/sscop-design.txt
+++ /dev/null
@@ -1,220 +0,0 @@
-
-	SSCOP Design
-	============
-
-SAP_SSCOP Interface
--------------------
-This is the stack SAP interface between the SSCOP module and an SSCOP user 
-module (eg. SSCF).  The stack commands defined for this interface are modeled 
-after the SSCOP protocol specification primitives AA-xxx.  See the protocol 
-specification documents referenced below for full descriptions of the SSCOP 
-interface presented to an SSCF.
-
-
-o The following stack commands are sent from an SSCF to SSCOP:
-
-Stack Command:	SSCOP_INIT
-Description:	Initialize a SAP instance.  This should be the first stack
-		command issued across the SAP instance after the service stack 
-		has been successfully instantiated.
-Argument 1:	Specifies the SSCOP version to be used for this stack instance.
-		(enum sscop_vers) 
-Argument 2:	Pointer to a structure containing the SSCOP protocol parameter
-		values to be used for this instance. (struct sscop_parms *)
-
-
-Stack Command:	SSCOP_TERM
-Description:	Terminate a SAP instance.  This must be the last stack command
-		issued across the SAP instance.  The stack instance will be
-		deleted upon completion of this command.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_ESTABLISH_REQ
-Description:	Request the establishment of an SSCOP connection for assured 
-		information transfer to the remote peer entity.
-Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
-		Information (SSCOP-UU / UUI) data to be sent to the peer.
-		Must be coded as SSCOP_UU_NULL.  (struct mbuf *)
-Argument 2:	Buffer Release (BR) parameter.  Must be coded as SSCOP_BR_YES.
-		(int)
-
-
-Stack Command:	SSCOP_ESTABLISH_RSP
-Description:	Response indicating that an SSCOP connection establishment 
-		request from the remote peer is acceptable.
-Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
-		Information (SSCOP-UU / UUI) data to be sent to the peer.
-		Must be coded as SSCOP_UU_NULL.  (struct mbuf *)
-Argument 2:	Buffer Release (BR) parameter.  Must be coded as SSCOP_BR_YES.
-		(int)
-
-
-Stack Command:	SSCOP_RELEASE_REQ
-Description:	Request the termination of an SSCOP connection with the 
-		remote peer entity.  
-Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
-		Information (SSCOP-UU / UUI) data to be sent to the peer.
-		Must be coded as SSCOP_UU_NULL.  (struct mbuf *)
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_DATA_REQ
-Description:	Request that an assured SDU be sent to the remote peer.
-Argument 1:	Pointer to an mbuf chain containing the user SDU.
-		(struct mbuf *)
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_RESYNC_REQ
-Description:	Request the resynchronization of an SSCOP connection.
-Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
-		Information (SSCOP-UU / UUI) data to be sent to the peer.
-		Must be coded as SSCOP_UU_NULL.  (struct mbuf *)
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_RESYNC_RSP
-Description:	Acknowledge the remote peer's resynchronization of an SSCOP 
-		connection.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_RECOVER_RSP (Q.2110 only)
-Description:	Acknowledge the indication that the SSCOP connection has 
-		recovered from SSCOP protocol errors.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_UNITDATA_REQ
-Description:	Request that an unacknowledged SDU be sent to the remote peer.
-Argument 1:	Pointer to an mbuf chain containing the user SDU.
-		(struct mbuf *)
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_RETRIEVE_REQ
-Description:	Not supported.
-Argument 1:	N/A
-Argument 2:	N/A
-
-
-o The following stack commands are sent from SSCOP to an SSCF:
-
-Stack Command:	SSCOP_ESTABLISH_IND
-Description:	Indication that a request to establish an SSCOP connection has 
-		been received from the remote peer entity.
-Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
-		Information (SSCOP-UU / UUI) data received from the peer.
-		(struct mbuf *)
-Argument 2:	Source of establish request (Q.SAAL1 only). Valid values are 
-		SSCOP_SOURCE_SSCOP or SSCOP_SOURCE_USER. (int)
-
-
-Stack Command:	SSCOP_ESTABLISH_CNF
-Description:	Confirmation from the remote peer of an SSCOP connection 
-		establishment, previously requested via an SSCOP_ESTABLISH_REQ
-		command.
-Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
-		Information (SSCOP-UU / UUI) data received from the peer.
-		(struct mbuf *)
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_RELEASE_IND
-Description:	Indication that an SSCOP connection has been terminated by 
-		the remote peer entity.
-Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
-		Information (SSCOP-UU / UUI) data received from the peer.
-		(struct mbuf *)
-Argument 2:	Source of release request. Valid values are SSCOP_SOURCE_SSCOP
-		or SSCOP_SOURCE_USER. (int)
-
-
-Stack Command:	SSCOP_RELEASE_CNF
-Description:	Confirmation from the remote peer of an SSCOP connection 
-		termination, previously requested via an SSCOP_RELEASE_REQ 
-		command.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_DATA_IND
-Description:	Indication that an assured SDU has been received from the 
-		remote peer.
-Argument 1:	Pointer to an mbuf chain containing the peer's SDU.
-		(struct mbuf *)
-Argument 2:	Sequence number of the received SDU. (sscop_seq)
-
-
-Stack Command:	SSCOP_RESYNC_IND
-Description:	Indication that the remote peer has requested the
-		resynchronization of the SSCOP connection.
-Argument 1:	Pointer to an mbuf chain containing any SSCOP User-to-User
-		Information (SSCOP-UU / UUI) data received from the peer.
-		(struct mbuf *)
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_RESYNC_CNF
-Description:	Confirmation from the remote peer that an SSCOP connection
-		has been resynchronized.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_RECOVER_IND (Q.2110 only)
-Description:	Indication that an SSCOP connection has recovered from SSCOP
-		protocol errors.
-Argument 1:	Not used.
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_UNITDATA_IND
-Description:	Indication that an unacknowledged SDU has been received from 
-		the remote peer.
-Argument 1:	Pointer to an mbuf chain containing the peer's SDU.
-		(struct mbuf *)
-Argument 2:	Not used.
-
-
-Stack Command:	SSCOP_RETRIEVE_IND
-Description:	Not supported.
-Argument 1:	N/A
-Argument 2:	N/A
-
-
-Stack Command:	SSCOP_RETRIEVECMP_IND
-Description:	Not supported.
-Argument 1:	N/A
-Argument 2:	N/A
-
-
-
-Protocol Specifications
------------------------
-For SSCOP_VERS_QSAAL, see Q.SAAL1.
-For SSCOP_VERS_Q2110, see Q.2110.
-
-
-
-Implementation Limitations
---------------------------
-o The following signals are not supported:
-	AA-RETRIEVE
-	AA-RETRIEVE COMPLETE
-	AA-RELEASEBUF (Q.SAAL1 only)
-	MAA-UNITDATA
-
-o Does not support sending the SSCOP-UU/UUI parameter, must be set to NULL
-
-o For the AA-ESTABLISH request and response signals, only BR=YES is supported 
-
-o For the AA-DATA request signal, only PR=NO is supported (Q.SAAL1 only)
-
-
-	@(#) $FreeBSD$
-