目录：http://www.cnblogs.com/WuCountry/archive/2008/11/15/1333960.html
[不提供插图，读者最好从网上下载源书]
5.9. Virtual Devices 虚拟设备
A virtual device is an abstraction built on top of one or more real devices. The association between virtual devices and real devices can be many-to-many, as shown by the three models in Figure 5-4. It is also possible to build virtual devices on top of other virtual devices. However, not all combinations are meaningful or are supported by the kernel.
一个虚拟设备是建立在一个或者多个真实设备之上的抽象设备。在虚拟设备和真实设备之间的关联可以是多对多的，正如图5－4中所示的。它同样可能是建立在其它虚拟设备之上的。然而，并不是所有的组合都是有意义的，也并不是所有的都被内核所支持。
Figure 5-4. Possible relationship between virtual and real devices
5.9.1. Examples of Virtual Devices 虚拟设备的一个例子
Linux allows you to define different kinds of virtual devices. Here are a few examples:
内核充许你可以定义不同类型的虚拟设备。这有几个例子：
Bonding 绑定
With this feature, a virtual device bundles a group of physical devices and makes them behave as one.
和这一特性一起，一个虚拟设备处理一组物理设备，并让它们一起表现得你是一个设备一样。
802.1Q
This is an IEEE standard that extends the 802.3/Ethernet header with the so-called VLAN header, allowing for the creation of Virtual LANs.
这是IEEE 802.3/以太网报头也就是被称为VLAN头的报文，充许创建虚拟的LAN。
Bridging 桥接
A bridge interface is a virtual representation of a bridge. Details are in Part IV.
一个桥接接口是一个虚拟桥的表现。详细在第五部份讨论。
Aliasing interfaces 别名接口
Originally, the main purpose for this feature was to allow a single real Ethernet interface to span several virtual interfaces (eth0:0, eth0:1, etc.), each with its own IP configuration. Now, thanks to improvements to the networking code, there is no need to define a new virtual interface to configure multiple IP addresses on the same NIC. However, there may be cases (notably routing) where having different virtual NICs on the same NIC would make life easier, perhaps allowing simpler configuration. Details are in Chapter 30.
一开始，这个特性的主要目的是充许单个以太网接口去区分虚拟接口（eth0:0, eth0:1, 等），每个都有它自己的IP配置。现在，感谢那些对网络代码的实现，现在不必要去为在同一个NIC上配置多IP地址而定义一个新的虚拟配置。然而，有些情况下（很可能是路由），有不同的虚拟NIC在同一个NIC可能会让生活变得更简单，或许充许更简单的配置。在第30章有更详细的说明。
True equalizer (TEQL) 真实均衡
This is a queuing discipline that can be used with Traffic Control. Its implementation requires the creation of a special device. The idea behind TEQL is a bit similar to Bonding.
这里有一个队列原则，可以用于控制流量控制。这个实现需要创建一个特性的设备。这个主意是隐藏在TEQL之后的，与Bonding有点小同。
Tunnel interfaces 隧道接口
The implementation of IP-over-IP tunneling (IPIP) and the Generalized Routing Encapsulation (GRE) protocol is based on the creation of a virtual device.
IPIP的实现和通用路由封装协议是基于一个虚拟设备的创建。
This list is not complete. Also, given the speed with which new features are included into the Linux kernel, you can expect to see new virtual devices being added to the kernel.
这有一个没有完成的列表，同样，给出了添加一个新特性到Linux内核中的速度，你可以认为看到一个新虚拟设备已经添加到内核中。
Bonding, bridging, and 802.1Q devices are examples of the model in Figure 5-4(c). Aliasing interfaces are examples of the model in Figure 5-4(b). The model in Figure 5-4(a) can be seen as a special case of the other two.
绑定，桥接，和802.1Q设备就是图5－4（c）这个模型的例子。另名接口是图5－4（b）的一个例子，而图5－4（a）的情况可以看成是除了这两个之外的特殊情况。
5.9.2. Interaction with the Kernel Network Stack 与内核网络栈的交互
Virtual devices and real devices interact with the kernel in slightly different ways. For example, they differ with regard to the following points:
虚拟设备和真实设备接口通过内核使用一些细微不同的方式来交互。例如，关于下面这些不同的细节点：
Initialization 初始化
Most virtual devices are assigned a net_device data structure, as real devices are. Often, most of the virtual device's net_device's function pointers are initialized to routines implemented as wrappers, more or less complex, around the function pointers used by the associated real devices.
很多虚拟设备都被关联到一个net_device的数据结构，它就像是个真实的设备。通常，大多数虚拟设备的net_device的函数指针都使用已经实现的函数进行初始化，或多或少有些复杂，这些函数指针被相关的真实设备所使用。
However, not all virtual devices are assigned a net_device instance. Aliasing devices are an example; they are implemented as simple labels on the associated real device (see the section "Old-generation configuration: aliasing interfaces" in Chapter 30).
然而，不是所有的虚拟设备都指定了一个net_device的实例。关联的设备是一个例子，它们以一个简单的标签关联到一个真实的设备来实现（参见第30章中的“旧方式的配置：别名接口”一节）。
Configuration 配置
It is common to provide ad hoc user-space tools to configure virtual devices, especially for the high-level fields that apply only to those devices and which could not be configured using standard tools such as ifconfig.
有一个常用的方法来提供hoc用户空间的工具来配置虚拟设备，特别是为配置上层应用的字段，这些字段不能用普通的，类似ifconfig这样的工具来配置。
External interface 外部接口
Each virtual device usually exports a file, or a directory with a few files, to the /proc filesystem. How complex and detailed the information exported with those files is depends on the kind of virtual device and on the design. You will see the ones used by each virtual device listed in the section "Virtual Devices" in their associated chapters (for those devices covered in this book). Files associated with virtual devices are extra files; they do not replace the ones associated with the physical devices. Aliasing devices, which do not have their own net_device instances, are again an exception.
每一个虚拟设备通常暴露一个文件，或者一个目录带少数几个文件，到/proc文件系统中。这些暴露出来的信息的详细情况的复杂程度取决与不同虚拟设备和它的设计。在虚拟设备一节中与此相关的章节中，你会看到每个虚拟设备所使用的就是一个例子。与虚拟设备相关的文件是一些额外的文件，它们不会替换与真实设备相关的文件。别名设备，这些是没有它们自己的net_device实例的，又是一个特例。
Transmission 传输
When the relationship of virtual device to real device is not one-to-one, the routine used to transmit may need to include, among other tasks, the selection of the real device to use.[*] Because QoS is enforced on a per-device basis, the multiple relationships between virtual devices and associated real devices have implications for the Traffic Control configuration.
当虚拟设备与真实设备的关联关不是一对一的，根据任务和真实设备的使用，那些传输的程序须要包含进去。因为QoS强制为每个设备的基础，在虚拟设备的真实设备之间的多关联对流量控制的配置是隐式的。
[*] See Chapter 11 for more details on packet transmission in general, and dev_queue_xmit in particular.
Reception 接收
Because virtual devices are software objects, they do not need to engage in interactions with real resources on the system, such as registering an IRQ handler or allocating I/O ports and I/O memory. Their traffic comes secondhand from the physical devices that perform those tasks. Packet reception happens differently for different types of virtual devices. For instance, 802.1Q interfaces register an Ethertype and are passed only those packets received by the associated real devices that carry the right protocol ID.[] In contrast, bridge interfaces receive any packet that arrives from the associated devices (see Chapter 16).
因为虚拟设备是软件对象，它们不必要与系统的真实资源相互交互而忙碌，例如，类似IRQ句柄的注册或者分配IO端口和IO内存。他们的流量间接来自现实这些功能的物理设备。包的接收根据不同的虚拟设备而有所不同。例如，802.1Q接口注册一个以太类型，并且它们只让那些从物理设备上来，带有正确的协议报文通过。相应的，桥接接口则是接收所有从相关设备上来的报文。
[] Chapter 13 discusses the demultiplexing of ingress traffic based on the protocol identifier.
External notifications 外部通知
Notifications from other kernel components about specific events taking place in the kernel[] are of interest as much to virtual devices as to real ones. Because virtual devices' logic is implemented on top of real devices, the latter have no knowledge about that logic and therefore are not able to pass on those notifications. For this reason, notifications need to go directly to the virtual devices. Let's use Bonding as an example: if one device in the bundle goes down, the algorithms used to distribute traffic among the bundle's members have to be made aware of that so that they do not select the devices that are no longer available.
从其它内核组件上报上来的在内核发生的关于特殊事件的通知，对于真实设备来说，虚拟设备更有兴趣关注。因为虑设备的逻辑是由顶层的设备所实现，而后者并不知道这些逻辑，并因此不能传送这些通知。因这这个原因，需要直接通知虚拟设备。让我们以绑定类型为例，如果一个在一梱中的设备的流量开始下降，用于分发在梱中的成员的算法，应该关注这些，以便它们不用去选择那些已经无效的设备。
[] Chapter 4 defines notification chains and explains what kind of notifications they can be used for.
Unlike these software-triggered notifications, hardware-triggered notifications (e.g., PCI power management) cannot reach virtual devices directly because there is no hardware associated with virtual devices.
与那些软件触发的通知，硬件触发（例如，PCI电源管理）的通知不能直接到达虚拟设备，因为没有硬件关联到虚拟设备。