summaryrefslogtreecommitdiffstats
path: root/networking
diff options
context:
space:
mode:
authorAmar Takhar <amar@rtems.org>2016-01-18 00:37:40 -0500
committerAmar Takhar <verm@darkbeer.org>2016-05-02 20:51:24 -0400
commitd389819eea3a84e388935153e3be847342809da3 (patch)
tree15cfe55f41281cead805ce87f66c5d7248caa9ce /networking
parent11e1a6f969dc0b255dd7aed12509484cf7c7ed60 (diff)
downloadrtems-docs-d389819eea3a84e388935153e3be847342809da3.tar.bz2
Convert all Unicode to ASCII(128)
Diffstat (limited to 'networking')
-rw-r--r--networking/dec_21140.rst4
-rw-r--r--networking/index.rst2
-rw-r--r--networking/network_servers.rst2
-rw-r--r--networking/network_task_structure.rst2
-rw-r--r--networking/networking_driver.rst18
-rw-r--r--networking/preface.rst2
-rw-r--r--networking/testing_the_driver.rst44
-rw-r--r--networking/using_networking_rtems_app.rst16
8 files changed, 45 insertions, 45 deletions
diff --git a/networking/dec_21140.rst b/networking/dec_21140.rst
index 8cc041c..9064508 100644
--- a/networking/dec_21140.rst
+++ b/networking/dec_21140.rst
@@ -46,7 +46,7 @@ DEC21140 PCI Board Generalities
This chapter describes rapidely the PCI interface of this Ethernet controller.
The board we have chosen for our PC386 implementation is a D-Link DFE-500TX.
This is a dual-speed 10/100Mbps Ethernet PCI adapter with a DEC21140AF chip.
-Like other PCI devices, this board has a PCI device’s header containing some
+Like other PCI devices, this board has a PCI device's header containing some
required configuration registers, as shown in the PCI Register Figure.
By reading
or writing these registers, a driver can obtain information about the type of
@@ -132,7 +132,7 @@ Receiver Thread
---------------
This thread is event driven. Each time a DEC PCI board interrupt occurs, the
-handler checks if this is a receive interrupt and send an event “reception”
+handler checks if this is a receive interrupt and send an event "reception"
to the receiver thread which looks into the entire buffer descriptors ring the
ones that contain a valid incoming frame (bit OWN=0 means descriptor belongs
to host processor). Each valid incoming ethernet frame is sent to the protocol
diff --git a/networking/index.rst b/networking/index.rst
index 0489422..db3b64c 100644
--- a/networking/index.rst
+++ b/networking/index.rst
@@ -1,7 +1,7 @@
========================
RTEMS Network Supplement
========================
-COPYRIGHT © 1988 - 2015.
+COPYRIGHT (c) 1988 - 2015.
On-Line Applications Research Corporation (OAR).
diff --git a/networking/network_servers.rst b/networking/network_servers.rst
index be8a033..cf3ec71 100644
--- a/networking/network_servers.rst
+++ b/networking/network_servers.rst
@@ -6,7 +6,7 @@ RTEMS FTP Daemon
The RTEMS FTPD is a complete file transfer protocol (FTP) daemon
which can store, retrieve, and manipulate files on the local
-filesystem. In addition, the RTEMS FTPD provides “hooks”
+filesystem. In addition, the RTEMS FTPD provides "hooks"
which are actions performed on received data. Hooks are useful
in situations where a destination file is not necessarily
appropriate or in cases when a formal device driver has not yet
diff --git a/networking/network_task_structure.rst b/networking/network_task_structure.rst
index 78609dd..7e1b269 100644
--- a/networking/network_task_structure.rst
+++ b/networking/network_task_structure.rst
@@ -23,7 +23,7 @@ The network task processes incoming packets and takes care of
timed operations such as handling TCP timeouts and
aging and removing routing table entries.
-The ‘Network code’ contains routines which may run in the context of
+The 'Network code' contains routines which may run in the context of
the user application tasks, the interface receive task or the network task.
A network semaphore ensures that
the data structures manipulated by the network code remain consistent.
diff --git a/networking/networking_driver.rst b/networking/networking_driver.rst
index 0f7238b..7be9dde 100644
--- a/networking/networking_driver.rst
+++ b/networking/networking_driver.rst
@@ -6,7 +6,7 @@ Introduction
This chapter is intended to provide an introduction to the
procedure for writing RTEMS network device drivers.
-The example code is taken from the ‘Generic 68360’ network device
+The example code is taken from the 'Generic 68360' network device
driver. The source code for this driver is located in the``c/src/lib/libbsp/m68k/gen68360/network`` directory in the RTEMS
source code distribution. Having a copy of this driver at
hand when reading the following notes will help significantly.
@@ -15,7 +15,7 @@ Learn about the network device
==============================
Before starting to write the network driver become completely
-familiar with the programmer’s view of the device.
+familiar with the programmer's view of the device.
The following points list some of the details of the
device that must be understood before a driver can be written.
@@ -70,7 +70,7 @@ data structures and resources. To ensure the consistency
of these structures the tasks
execute only when they hold the network semaphore (``rtems_bsdnet_semaphore``).
The transmit and receive tasks must abide by this protocol. Be very
-careful to avoid ‘deadly embraces’ with the other network tasks.
+careful to avoid 'deadly embraces' with the other network tasks.
A number of routines are provided to make it easier for the network
driver code to conform to the network task scheduling conventions.
@@ -160,9 +160,9 @@ in the device-dependent data structure supplied and maintained by the driver:
``ifp->if_unit``
The device number. The network stack uses this number and the
- device name for device name lookups. For example, if``ifp->if_name`` is ‘``scc``’ and ``ifp->if_unit`` is ‘``1``’,
- the full device name would be ‘``scc1``’. The unit number should be
- obtained from the ‘name’ entry in the configuration structure.
+ device name for device name lookups. For example, if``ifp->if_name`` is '``scc``' and ``ifp->if_unit`` is '``1``',
+ the full device name would be '``scc1``'. The unit number should be
+ obtained from the 'name' entry in the configuration structure.
``ifp->if_mtu``
The maximum transmission unit for the device. For Ethernet
@@ -211,7 +211,7 @@ Once the attach function has set up the above entries it must link the
driver data structure onto the list of devices by
calling ``if_attach``. Ethernet devices should then
call ``ether_ifattach``. Both functions take a pointer to the
-device’s ``ifnet`` structure as their only argument.
+device's ``ifnet`` structure as their only argument.
The attach function should return a non-zero value to indicate that
the driver has been successfully configured and attached.
@@ -221,8 +221,8 @@ Write the Driver Start Function.
This function is called each time the network stack wants to start the
transmitter. This occures whenever the network stack adds a packet
-to a device’s send queue and the ``IFF_OACTIVE`` bit in the
-device’s ``if_flags`` is not set.
+to a device's send queue and the ``IFF_OACTIVE`` bit in the
+device's ``if_flags`` is not set.
For many devices this function need only set the ``IFF_OACTIVE`` bit in the``if_flags`` and send an event to the transmit task
indicating that a packet is in the driver transmit queue.
diff --git a/networking/preface.rst b/networking/preface.rst
index 40be9c9..9c1649c 100644
--- a/networking/preface.rst
+++ b/networking/preface.rst
@@ -11,7 +11,7 @@ who also ported the FreeBSD TCP/IP stack to RTEMS.
The following is a list of resources which should be useful in trying
to understand Ethernet:
-- *Charles Spurgeon’s Ethernet Web Site*
+- *Charles Spurgeon's Ethernet Web Site*
"This site provides extensive information about Ethernet
(IEEE 802.3) local area network (LAN) technology. Including
the original 10 Megabit per second (Mbps) system, the 100 Mbps
diff --git a/networking/testing_the_driver.rst b/networking/testing_the_driver.rst
index d71747f..9a064e7 100644
--- a/networking/testing_the_driver.rst
+++ b/networking/testing_the_driver.rst
@@ -11,7 +11,7 @@ The network used to test the driver should include at least:
the operation of the target machine.
- An Ethernet network analyzer or a workstation with an
- ‘Ethernet snoop’ program such as ``ethersnoop`` or``tcpdump``.
+ 'Ethernet snoop' program such as ``ethersnoop`` or``tcpdump``.
- A workstation.
@@ -39,7 +39,7 @@ is a list of them:
- mbuf activity
There are commented out calls to ``printf`` in the file``sys/mbuf.h`` in the network stack code. Uncommenting
- these lines results in output when mbuf’s are allocated
+ these lines results in output when mbuf's are allocated
and freed. This is very useful for finding memory leaks.
- TX and RX queuing
@@ -91,29 +91,29 @@ is a list of them:
URL: (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-routing.html)
For a quick reference to the flags, see the table below:
- ‘``U``’
+ '``U``'
Up: The route is active.
- ‘``H``’
+ '``H``'
Host: The route destination is a single host.
- ‘``G``’
+ '``G``'
Gateway: Send anything for this destination on to this remote system, which
will figure out from there where to send it.
- ‘``S``’
+ '``S``'
Static: This route was configured manually, not automatically generated by the
system.
- ‘``C``’
+ '``C``'
Clone: Generates a new route based upon this route for machines we connect
to. This type of route is normally used for local networks.
- ‘``W``’
+ '``W``'
WasCloned: Indicated a route that was auto-configured based upon a local area
network (Clone) route.
- ‘``L``’
+ '``L``'
Link: Route involves references to Ethernet hardware.
- ``mbuf``
@@ -182,29 +182,29 @@ The network demonstration program ``netdemo`` may be used for these tests.
broadcast packets disabled:
Verify that the program continues to run once the driver has been attached.
-- Issue a ‘``u``’ command to send UDP
- packets to the ‘discard’ port.
+- Issue a '``u``' command to send UDP
+ packets to the 'discard' port.
Verify that the packets appear on the network.
-- Issue a ‘``s``’ command to print the network and driver statistics.
+- Issue a '``s``' command to print the network and driver statistics.
- On a workstation, add a static route to the target system.
-- On that same workstation try to ‘ping’ the target system.
+- On that same workstation try to 'ping' the target system.
Verify that the ICMP echo request and reply packets appear on the net.
- Remove the static route to the target system.
Modify ``networkconfig.h`` to attach the driver
with reception of broadcast packets enabled.
- Try to ‘ping’ the target system again.
+ Try to 'ping' the target system again.
Verify that ARP request/reply and ICMP echo request/reply packets appear
on the net.
-- Issue a ‘``t``’ command to send TCP
- packets to the ‘discard’ port.
+- Issue a '``t``' command to send TCP
+ packets to the 'discard' port.
Verify that the packets appear on the network.
-- Issue a ‘``s``’ command to print the network and driver statistics.
+- Issue a '``s``' command to print the network and driver statistics.
- Verify that you can telnet to ports 24742
and 24743 on the target system from one or more
@@ -232,7 +232,7 @@ Giant packets
- Recompile the driver with ``MAXIMUM_FRAME_SIZE`` set to
a smaller value, say 514.
-- ‘Ping’ the driver from another workstation and verify
+- 'Ping' the driver from another workstation and verify
that frames larger than 514 bytes are correctly rejected.
- Recompile the driver with ``MAXIMUM_FRAME_SIZE`` restored to 1518.
@@ -248,8 +248,8 @@ Resource Exhaustion
- Verify that the program operates properly and that you can
still telnet to both the ports.
-- Display the driver statistics (Console ‘``s``’ command or telnet
- ‘control-G’ character) and verify that:
+- Display the driver statistics (Console '``s``' command or telnet
+ 'control-G' character) and verify that:
# The number of transmit interrupts is non-zero.
This indicates that all transmit descriptors have been in use at some time.
@@ -262,7 +262,7 @@ Cable Faults
- Run the ``netdemo`` program.
-- Issue a ‘``u``’ console command to make the target machine transmit
+- Issue a '``u``' console command to make the target machine transmit
a bunch of UDP packets.
- While the packets are being transmitted, disconnect and reconnect the
@@ -277,7 +277,7 @@ Throughput
----------
Run the ``ttcp`` network benchmark program.
-Transfer large amounts of data (100’s of megabytes) to and from the target
+Transfer large amounts of data (100's of megabytes) to and from the target
system.
The procedure for testing throughput from a host to an RTEMS target
diff --git a/networking/using_networking_rtems_app.rst b/networking/using_networking_rtems_app.rst
index 0778385..bd6f9f5 100644
--- a/networking/using_networking_rtems_app.rst
+++ b/networking/using_networking_rtems_app.rst
@@ -126,7 +126,7 @@ below, you need to provide only the first two entries in this structure.
You can also use ``rtems_bsdnet_do_bootp_rootfs`` to have a set of
standard files created with the information return by the BOOTP/DHCP
protocol. The IP address is added to :file:`/etc/hosts` with the host
- name and domain returned. If no host name or domain is returned``me.mydomain`` is used. The BOOTP/DHCP server’s address is also
+ name and domain returned. If no host name or domain is returned``me.mydomain`` is used. The BOOTP/DHCP server's address is also
added to :file:`/etc/hosts`. The domain name server listed in the
BOOTP/DHCP information are added to :file:`/etc/resolv.conf`. A``search`` record is also added if a domain is returned. The files
are created if they do not exist.
@@ -162,7 +162,7 @@ below, you need to provide only the first two entries in this structure.
``char \*gateway``
The Internet host number of the network gateway machine,
- specified in ’dotted decimal’ (``129.128.4.1``) form.
+ specified in 'dotted decimal' (``129.128.4.1``) form.
``char \*log_host``
The Internet host number of the machine to which ``syslog`` messages
@@ -279,13 +279,13 @@ structure.
``char \*ip_address``
The Internet address of the device,
- specified in ‘dotted decimal’ (``129.128.4.2``) form, or ``NULL``
+ specified in 'dotted decimal' (``129.128.4.2``) form, or ``NULL``
if the device configuration information is being obtained from a
BOOTP/DHCP server.
``char \*ip_netmask``
The Internet inetwork mask of the device,
- specified in ‘dotted decimal’ (``255.255.255.0``) form, or ``NULL``
+ specified in 'dotted decimal' (``255.255.255.0``) form, or ``NULL``
if the device configuration information is being obtained from a
BOOTP/DHCP server.
@@ -496,8 +496,8 @@ you when more data has arrived. (Condition 1.a.)
For sending, when the socket is connected and the free space becomes at
or above the "low water mark" for the send buffer (default 4096 bytes)
-you will receive a writable callback. You don’t get continuous callbacks
-if you don’t write anything. Using a non-blocking write socket, you can
+you will receive a writable callback. You don't get continuous callbacks
+if you don't write anything. Using a non-blocking write socket, you can
then call write until it returns a value less than the amount of data
requested to be sent or it produces error EWOULDBLOCK (indicating buffer
full and no longer writable). When this happens you can
@@ -837,13 +837,13 @@ returns. The priority argument is ignored.
If the interval argument is greater than 0, the routine also starts an
RTEMS task at the specified priority and polls the NTP server every
-‘interval’ seconds. NOTE: This mode of operation has not yet been
+'interval' seconds. NOTE: This mode of operation has not yet been
implemented.
On successful synchronization of the RTEMS time-of-day clock the routine
returns 0. If an error occurs a message is printed and the routine returns -1
with an error code in errno.
-There is no timeout – if there is no response from an NTP server the
+There is no timeout - if there is no response from an NTP server the
routine will wait forever.
.. COMMENT: Written by Eric Norum