留着

The netif Interface All other communication in the direction interface ! network
stack is done via the netif_*() calls. For example, on successful device opening,
the network stack has to be noti ed, that it can now pass frames to the interface.
This is done by calling netif_start_queue(). After this call, the hard_start_xmit()
callback can be called by the network stack. Furthermore a network driver usually
manages a frame transmission queue. If this gets lled up, the network stack has
to be told to stop passing further frames for a while. This happens with a call
to netif_stop_queue(). If some frames have been sent, and there is enough space
again to queue new frames, this can be noti ed with netif_wake_queue(). Another
important call is netif_receive_skb()1: It passes a frame to the network stack, that
was just received by the device. Frame data has to be included in a so-called \socket
bu er" for that (see below).
Socket Bu ers Socket bu ers are the basic data type for the whole network stack.
They serve as containers for network data and are able to quickly add data headers
and footers, or strip them o again. Therefore a socket bu er consists of an allocated
bu er and several pointers that mark beginning of the bu er (head), beginning of data
(data), end of data (tail) and end of bu er (end). In addition, a socket bu er holds
network header information and (in case of received data) a pointer to the net_device,
it was received on. There exist functions that create a socket bu er (dev_alloc_skb()),
add data either from front (skb_push()) or back (skb_put()), remove data from front
(skb_pull()) or back (skb_trim()), or delete the bu er (kfree_skb()). A socket bu er
is passed from layer to layer, and is freed by the layer that

 

Ethernet and EtherCAT Devices Another issue lies in the way Linux handles de-
vices of the same type. For example, a PCI driver scans the PCI bus for devices it can
handle. Then it registers itself as the responsible driver for all of the devices found.
The problem is, that an unmodi ed driver can not be told to ignore a device because
it will be used for EtherCAT later. There must be a way to handle multiple devices

 

of the same type, where one is reserved for EtherCAT, while the other is treated as
an ordinary Ethernet device.
For all this reasons, the author decided that the only acceptable solution is to modify
standard Ethernet drivers in a way that they keep their normal functionality, but gain
the ability to treat one or more of the devices as EtherCAT-capable.
Below are the advantages of this solution:
 No need to tell the standard drivers to ignore certain devices.
 One networking driver for EtherCAT and non-EtherCAT devices.
 No need to implement a network driver from scratch and running into issues,
the former developers already solved.
The chosen approach has the following disadvantages:
 The modi ed driver gets more complicated, as it must handle EtherCAT and
non-EtherCAT devices.
 Many additional case di erentiations in the driver code.
 Changes and bug xes on the standard drivers have to be ported to the Ether-
CAT-capable versions from time to time.