summaryrefslogtreecommitdiffstats
path: root/networking/networking_driver.rst
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/networking_driver.rst
parent11e1a6f969dc0b255dd7aed12509484cf7c7ed60 (diff)
downloadrtems-docs-d389819eea3a84e388935153e3be847342809da3.tar.bz2
Convert all Unicode to ASCII(128)
Diffstat (limited to 'networking/networking_driver.rst')
-rw-r--r--networking/networking_driver.rst18
1 files changed, 9 insertions, 9 deletions
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.