[Midnightbsd-cvs] src: share/examples: Atm isn't connected to the build anymore (mpsafe
laffer1 at midnightbsd.org
laffer1 at midnightbsd.org
Sun Jan 4 17:59:17 EST 2009
Log Message:
-----------
Atm isn't connected to the build anymore (mpsafe issues)
Modified Files:
--------------
src/share/examples:
Makefile (r1.4 -> r1.5)
Removed Files:
-------------
src/share/examples/atm:
NOTES
README
Startup
atm-config.sh
atm-sockets.txt
cpcs-design.txt
fore-microcode.txt
sscf-design.txt
sscop-design.txt
-------------- next part --------------
Index: Makefile
===================================================================
RCS file: /home/cvs/src/share/examples/Makefile,v
retrieving revision 1.4
retrieving revision 1.5
diff -L share/examples/Makefile -L share/examples/Makefile -u -r1.4 -r1.5
--- share/examples/Makefile
+++ share/examples/Makefile
@@ -5,7 +5,6 @@
LDIRS= IPv6 \
MidnightBSD_version \
- atm \
bootforth \
cvsup \
diskless \
--- 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: src/share/examples/atm/Startup,v 1.2 1999/08/28 00:19:07 peter Exp $
-
--- 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: src/share/examples/atm/sscop-design.txt,v 1.2 1999/08/28 00:19:08 peter Exp $
-
--- 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: src/share/examples/atm/atm-sockets.txt,v 1.3 1999/08/28 00:19:07 peter Exp $
-
--- 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: src/share/examples/atm/sscf-design.txt,v 1.2 1999/08/28 00:19:08 peter Exp $
-
--- 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: src/share/examples/atm/cpcs-design.txt,v 1.2 1999/08/28 00:19:07 peter Exp $
-
--- 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: src/share/examples/atm/atm-config.sh,v 1.2 1999/08/28 00:19:07 peter Exp $
-#
-#
-
-#
-# 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
-
--- 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: src/share/examples/atm/fore-microcode.txt,v 1.2 2004/06/20 13:07:25 mpp Exp $
--- 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 at 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: src/share/examples/atm/NOTES,v 1.2 1999/08/28 00:19:06 peter Exp $
-
--- 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 at 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 at magic.net. To be added
-to the list, send email to harp-request at 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: src/share/examples/atm/README,v 1.2 1999/08/28 00:19:06 peter Exp $
-
More information about the Midnightbsd-cvs
mailing list