已经近两年没有在博客园上发表点什么了，一来是自己转向Linux和C了，对Windows下的C＃和VS.Net开发环境也很少使用了。但对.Net和C＃的热爱是一点也没有减少。相反，也一直在关注Linux下.Net应用程序开发的进展情况。在使用过几个版本的Linux以后，终于在前几天Suse11的网站上（http://en.opensuse.org/Download）看到Suse11支持.Net应用程序开发的特性说明。于是花了一天时间下载，2天时间专门用一台机器安装了它。今天，终于可以小试一了。

　　先看看开发环境，MonoDevelop:

Hello World:

命令行下执行：

再看看Linux下的.Net开发环境帮助：

　　非常不错的开发环境。简单的配置了一下，可以支持.Net1.1和2.0以及多种图形库。当然还有Web应用程序开发库。今天就先简单的写点，希望以后在博客园里看到更多的关于.Net在更多平台上开发的东西。

The following categories describe some of the types of things a process descriptor must keep track of during a process' lifespan:　进程运行中必须保存的一些信息类别

• Process attributes进程属性

• Process relationships进程间关系

• Process memory space进程内存空间

• File management文件管理

• Signal management信号管理

• Process credentials进程信任状态

• Resource limits资源限制

• Scheduling related fields调度相关的字段

current宏指向当前进程数据结构描述符！可以自己写一个小程序，将这些信息都打出来！

Building and Testing gcc/glibc cross toolchains

Contents

• Trouble in cross-compiler land
• Enhancing the community build script
• Results
• Downloads
• About the author

Trouble in crosscompiler land

At Ixia, I had been maintaining a toolchain by starting with a commercial free embedded linux toolchain, and overlaying it with newer versions compiled from scratch as needed to fix problems. This became harder to maintain as time went on.

Enhancing the community build script

• made darn sure it worked properly for ppc and gcc-2.95
• removed newlib support so I could focus on glibc more easily
• updated it to handle gcc-3.2.x, gcc-3.3.x, and gcc-3.4.x, since I wasn't sure which of those I would need
• enhanced it to automatically download the source tarballs and apply the minimal set of patches needed to successfully build
• enhanced it to support all CPU types supported by glibc, since that was easy and was a good test of the script
• added support for running the gcc and glibc regression test suites, since at Ixia we need regression tests for everything we ship
• documented how to run dejagnu regression tests remotely, since that's how to test gcc on a small embedded platform, and the dejanu documentation is misleading and incomplete
• documented how to set up a chroot jail that allows remote login, since a chroot jail is the easiest way to test alternate versions of glibc, and there weren't any good howto's on the subject
• added support for building userland (for now, just busybox, ncurses, libnet, and libpcap) with the new toolchain (see --builduserland option to all.sh) so you can test even if you don't have userland apps compatible with the new toolchain

Results

You can see from the build matrix included in the buildlogs directory of the crosstool tarball that many combinations of CPU, gcc, glibc, and Linux produce toolchains which can in fact compile user programs and the Linux kernel. You can also see which combinations don't work, and by clicking on their entries in the matrix, you can see the last 300 lines of the build log, including the error that stopped the toolchain or kernel build.

(I used to have test results here for some embedded processors, but they're a bit out of date.)

Here are a few success reports from other users:

• Leif Huhn said he used crosstool to generate a gcc3.2.3-glibc2.2.5 / arm-unknown-linux-gnu toolchain which successfully compiles static binaries for the Zaurus 5600.
• Several people (batbox.org, seattlewireless.net's wiki) say they've used crosstool to generate a gcc3.2.3-glibc2.2.5 / mipsel-linux toolchain for the BCM4710 processor that powers the Linksys WRT54 Wireless Router.
• Dave Hylands had to add some patches, but reported success using crosstool to generate a gcc-2.95.3-glibc-2.2.2 / armv4b-linux big endian ARM toolchain.

• "Thanks for crosstool, it's a big time saver. I used demo-ppc405.sh on Red Hat Enterprise Linux 3 ... With this compiler I'm able to compile and boot a 2.4.19-rc3-based kernel on a PowerPPC 440 board."
• "Thanks for crosstool! It's been some time since I had to build a cross-compiler, but I remember it being a pain. Your tool makes it almost effortless."
• "Dan, your tool is full of Ass Kicking Goodness!(tm)!"
• "Thank you!! If I were female, at this point I would offer to have your baby."
• "Thanks again for crosstool. It has been a wonderful oasis in the turbulent sea of cross tool bits."
• "You have my utmost respect and awe. Your very careful work saved me untold hours of work and search & read time."
• "Thank you so much for writing crosstool. Years ago, I spent ages setting up a gcc cross-compiler, and was looking at doing so again with dread (especially an unusual cygwin->Linux cross-compiler). With crosstool, I was up and running after a single, automated, overnight build -- I really didn't think it would work, as it seemed too good to be true. You are an absolute angel. Thank you."

Downloads

• crosstool-howto.html -- read this first; this is the real doc
• http://kegel.com/crosstool/crosstool-0.43.tar.gz (tarball)
• http://kegel.com/crosstool/crosstool-0.43 (individual files)
• buildlogs (cool handy-dandy matrix showing whether various tool/cpu combinations can build a Linux kernel, and linking to the build logs)
• ChangeLog
• README
• crosstool patch repository -- patches I apply to the tools before building. Each patch starts off with links to the appropriate discussions and/or bug reports, and shows the error it fixes. (Well, most of them do.)

About the author

Last Change 7 Dec 2006
The latest copy of this document can be found at kegel.com/crosstool
Portions Copyright by Ixia, 2003
Portions Copyright by Google, 2003-2006
Crosstool is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

[Return to www.kegel.com]

6.1. Data Structures Featured in This Chapter 本章涉及到的数据结构
Here are a few key data structure types used by the PCI layer. There are many others, but the following ones are all we need to know for our overview in this book. The first one is defined in include/linux/mod_devicetable.h, and the other two are defined in include/linux/pci.h.
这里有一些PCI层会使用到的关键数据结构类型。有很多其它的数据类型，但下面的这些是本书中一直提及到的。第一个是定义在include/linux/mod_devicetable.h中，其它的两个定义在include/linux/pci.h中。

pci_device_id

Device identifier. This is not a local ID used by Linux, but an ID defined accordingly to the PCI standard. The later section "Registering a PCI NIC Device Driver" shows the ID's definition, and the later section "Example of PCI NIC Driver Registration" presents an example.
设备标识。这不是一个本地的由Linux所使用的ID，而是一个根据PCI标准定义的ID。在后面的一节“注册PCI　NIC设备驱动”中会展示这个ID的定义，其后的“一个PCI　NIC设备注册的例子”一节是会有一个例子。

pci_dev

Each PCI device is assigned a pci_dev instance, just as network devices are assigned net_device instances. This is the structure used by the kernel to refer to a PCI device.
每一个PCI设备就是一个指定的pci_dev实例，只有网络设备才会指定为net_device实例。这个数据结构就是内核用于引用到一个PCI设备。

pci_driver

Defines the interface between the PCI layer and the device drivers. This structure consists mostly of function pointers. All PCI devices use it. See the later section "Example of PCI NIC Driver Registration" for its definition and an example of its initialization.
用于在PCI层和设备驱动之间定义接口。这个结构包括了大多数函数指针。所有的CPI设备都使用它。在后面的一节中有一个它的定义和初始化的示例。

PCI device drivers are defined by an instance of a pci_driver structure. Here is a description of its main fields, with special attention paid to the case of NIC devices. The function pointers are initialized by the device driver to point to appropriate functions within that driver.
PCI设备驱动由一个pci_driver结构的实例所定义。这里对于它的主要成员有些说明，重点关注的是NIC设备这种情况。它的函数指针由设备驱动指向相关驱动的适当函数。

char *name

Name of the driver.
设备名。

const struct pci_device_id *id_table

Vector of IDs the kernel will use to associate devices to this driver. The section "Example of PCI NIC Driver Registration" shows an example.
一个内核会用于关联到设备驱动的向量ID。

int (*probe)(struct pci_dev *dev, const struct pci_device_id *id)

Function invoked by the PCI layer when it finds a match between a device ID for which it is seeking a driver and the id_table mentioned previously. This function should enable the hardware, allocate the net_device structure, and initialize and register the new device.[*] In this function, the driver also allocates any additional data structures (e.g., buffer rings used during transmission or reception) that it may need to work properly.
当PCI设备在设备ID中查找一个匹配的设备时，就调由PCI层调用这个函数。这个ID用于查找前面提到过的驱动和id_table。这个函数应该让硬件使能，分配net_device结构，并初始化和注册新的设备。在这个函数中，驱动同样会分配一些让它正常工作的额外的数据结构（例如，用于数据传输和接收的缓存区）。

[*] NIC registration is covered in Chapter 8.

void (*remove)(struct pci_dev *dev)

Function invoked by the PCI layer when the driver is unregistered from the kernel or when a hot-pluggable device is removed. It is the counterpart of probe and is used to clean up any data structure and state.
当驱动从内核中移出，或者热插拨设备从系统中移走时，PCI层会调用这个函数。它是与探测器相对的功能，用于清除数据结构和状态。

Network devices use this function to release the allocated I/O ports and I/O memory, to unregister the device, and to free the net_device data structure and any other auxiliary data structure that could have been allocated by the device driver, usually in its probe function.
网络设备用这个函数来释放已经分配的IO端口和IO内存，反注册设备，并释放net_device数据结构和其它的可能已经分配给设备驱动的辅助数据结构，通常是它的探测函数。

int (*suspend)(struct pci_dev *dev, pm_message_t state)

int (*resume)(struct pci_dev *dev)

Functions invoked by the PCI layer when the system goes into suspend mode and when it is resumed, respectively. See the later section "Power Management and Wake-on-LAN."
这两个函数是系统进入挂起模式和从该模式中恢复时由PCI层调用的。

int (*enable_wake)(struct pci_dev *dev, u32 state, int enable)

With this function, a driver can enable or disable the capability of the device to wake the system up by generating specific Power Management Event signals. See the later section "Power Management and Wake-on-LAN."
利用这两个函数，一个驱动可以使能或者去使能设备生成特殊的电源管理事件来唤醒系统的能力。

struct pci_dynids dynids

Dynamic IDs. See the following section.
动态ID。

See the later section "Example of PCI NIC Driver Registration" for an example of initialization of a pci_driver instance.

The PCI subsystem (also known as the PCI layer ) in the kernel provides all the generic functions that are used in common by various PCI device drivers. This subsystem takes a lot of work off the shoulders of the programmer for each individual device, lets drivers be written in a clean manner, and makes it easier for the kernel to collect and maintain information about the devices, such as accounting information and statistics.
在内核中的PCI子系统，也就是众所周知的PCI层，提供了所有可以用于大多数PCI设备驱动的通用功能。这个子系统包括了很多帮助程序员开发每个独立设备的工作，让驱动的编写方式很清楚，并且让它可以更加容易的在内核中收集和维护。例如，信息统计。

In this chapter, we will see the meaning of a few key data structures used by the PCI layer and how these structures are initialized by one common NIC device driver. I'll conclude with a few words on the PCI power management and Wake-on-LAN features.
在这一章，我们会看到几个用于PCI层的关键数据结构的含义，以及这些数据结构是如何被通用的NIC设备驱动所化初始化的。我们会包括一些PCI电源管理的词汇以及局域网唤醒特性！ 

5.11. Functions and Variables Featured in This Chapter 本章的函数，变量和特性
Table 5-1 summarizes the functions, macros, variables, and data structures introduced in this chapter.
表5－1是本章所涉及到的一些函数，宏，变量以及数据结构。

Table 5-1. Functions, macros, variables, and data structures related to system

Functions and macros

initialization Name  
request_irq   
free_irq

Description    
Registers and releases, respectively, a callback handler for an IRQ line. The registration can be exclusive or shared.
分别用于注册和释放在IRQ线路上的回调句柄！
 
request_region

release_region
 Allocates and releases I/O ports and I/O memory.
分配和释放IO端口和IO内存
 
call_usermodehelper
 Invokes a user-space helper application.
调用用户空间的帮助应用程序。
 
module_param
 Macro used to define configuration parameters for modules.
模块参数
 
net_dev_init
 Initializes a piece of the networking code at boot time.
在启动时初始化
 
Global variables
 
dev_boot_phase
 Boolean flag used by legacy code to enforce the execution of net_dev_init before NIC device drivers register themselves.
逻辑标志位，在老的代码中用于强迫NIC设备驱动在注册net_dev_init之前来执行。

irq_desc
 Pointer to the vector of IRQ descriptors.
打印IRQ向量的描述信息。
 
Data structure
  
struct irq_action
 Each IRQ line is defined by an instance of this structure. Among other fields, it includes a callback function.
每一个IRQ线路都定义了一个这个数据结构的实例。和其它字段一起，还包括一个回调函数　。
 
net_device
 Describes a network device.
 一个网络设备的描述。

5.10. Tuning via /procs Filesystem 通过/proc文件系统来调整内核模块
Figure 5-5 shows the files that can be used either to tune or to view the status of configuration parameters related to the topics covered in this chapter.
图5－5显示了这些可以用于调整和查看配置状态的文件。这些配置状态参数都会在本章涉及到。

In /proc/sys/kernel are the files modprobe and hotplug that can change the pathnames of the two programs introduced earlier in the section "User-Space Helpers."
在proc/sys/kernle中是一些模块探测文件和可以修改路径名的热插拨设备。这两个程序都已经在前面一节“用户空间助手”讲过了。

A few files in /proc export the values within internal data structures and configuration parameters, which are useful to track what resources were allocated by device drivers, shown earlier in the section "Basic Goals of NIC Initialization." For some of these data structures, a user-space command is provided to print their contents in a more user-friendly format. For example, lsmod lists the modules currently loaded, using /proc/modules as its source of information.
在/proc中有一些文件展示了内部数据结构的值和配置参数，这些信息可以跟踪设备驱动的资源分配情况，这些在前面的章节“NIC初始化的基础全局变量”已经讲过。有些数据结构，有一个用户空间的命令提供了可以友好方式打印它们内容。例如，lsmod列出当前加载的模块，这是使用/proc/modules作为它的资源信息。

In /proc/net, you can find the files created by net_dev_init, via dev_proc_init and dev_mcast_init (see the earlier section "Initializing the Device Handling Layer: net_dev_init"):
在proc/net/中，你要以发现一些由net_dev_init通过dev_proc_init和dev_mcast_init创建的文件，（参见。。。）

dev

Displays, for each network device registered with the kernel, a few statistics about reception and transmission, such as bytes received or transmitted, number of packets, errors, etc.
对于每一个注册到内核中的设备，用dev显示一些关于接收和传输的统计信息，例如接收和传输的字节数，包数，错误等。

dev_mcast

Displays, for each network device registered with the kernel, the values of a few parameters used by IP multicast.
显示一些用于IP多播的参数。

wireless

Similarly to dev, for each wireless device, prints the values of a few parameters from the wireless block returned by the dev->get_wireless_stats virtual function. Note that dev->get_wireless_stats returns something only for wireless devices, because those allocate a data structure to keep those statistics (and so /proc/net/wireless will include only wireless devices).
与dev很类似，对于每一个无线设备，用于打印无线设备块的一些参数，这些数据是通过dev->get_wrieless_stats虚函数返回的。注意到，dev->get_wrieless_stats只为无线设备的一些数据，因为分配的这些数据结构保留这些统计。

softnet_stat

Exports statistics about the software interrupts used by the networking code. See Chapter 12.
用于暴露一些用于网络代码的软中断。参见第12章。

Figure 5-5. /proc files related to the routing subsystem

There are other interesting directories, including /proc/drivers, /proc/bus, and /proc/irq, for which I refer you to Linux Device Drivers. In addition, kernel parameters are gradually being moved out of /proc and into a directory called /sys, but I won't describe the new system for lack of space.
这还有其它一些有趣的目录，包括/proc/drivers，/proc/bus，以及/poc/irq，对于每一个，都推荐去看看Linux设备驱动开发一书。另外，内核参数已经慢慢的从proc中移出，并添加在一个sys目录中，因为篇愊有限，这里不就详细说明了。

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电源管理）的通知不能直接到达虚拟设备，因为没有硬件关联到虚拟设备。

5.8. User-Space Helpers 用户空间的助手
There are cases where it makes sense for the kernel to invoke a user-space application to handle events. Two such helpers are particularly important:
我们关心，它是怎样让内核关注并调用用户空间里的应用程序来处理事件的。这有两个特别重要的助手：

/sbin/modprobe

Invoked when the kernel needs to load a module. This helper is part of the module-init-tools package.
在内核要加载模块时调用。它个助手是module-init-tools工具包的一部份。

/sbin/hotplug

Invoked when the kernel detects that a new device has been plugged or unplugged from the system. Its main job is to load the correct device driver (module) based on the device identifier. Devices are identified by the bus they are plugged into (e.g., PCI) and the associated ID defined by the bus specification.[] This helper is part of the hotplug package.
这个会在内核检测到有新设备被插入到系统中时来被调用。它的主要工作就是根据设备的标识来加载正确的设备驱动（模块）。设备的标识是通过它插入的总线和它所关联的总线规格来标识的。这个助手也是热插拨工具包的一部份。

[] See the section "Registering a PCI NIC Device Driver" in Chapter 6 for an example involving PCI.
参见第6章中“注册一个PCI类型的NIC设备驱动”一节的一个调用实例！

The kernel provides a function named call_usermodehelper to execute such user-space helpers. The function allows the caller to pass the application a variable number of both arguments in arg[] and environment variables in env[]. For example, the first argument arg[0] tells call_usermodehelper what user-space helper to launch, and arg[1] can be used to tell the helper itself what configuration script to use (often called the user-space agent). We will see an example in the later section "/sbin/hotplug."
内核提供了一个名为call_usermodehelper函数用于执行这样的用户空间的助手程序。这个函数充许调用者通过arg[]参数和env[]环境变量来向应用程序传递很多数据。例如，第一个参数arg[0]就告诉call_usermodehelper要启动用户空间中的哪个助手程序，而arg[1]可以用于告诉助手程序它自己，应该使用怎样的配置脚本（通常也叫作用户空间代理）。我们会在后面的“/sbin/hotplug”一节中看到一个例子。

Figure 5-3 shows how two kernel routines, request_module and kobject_hotplug, invoke call_usermodehelper to invoke /sbin/modprobe and /sbin/hotplug, respectively. It also shows examples of how arg[] and envp[] are initialized in the two cases. The following subsections go into a little more detail on each of those two user-space helpers.
图5－3显示了两个内核程序，request_module 和kobject_hotplug, 是如何分别调用/sbin/modprobe 和/sbin/hotplug的。它同时也显示了在这两种情况下arg[]和evn[]是如何初始化的。下面的子章节会详细的讨论这两种情况下的用户空间的助手程序。

Figure 5-3. Event propagation from kernel to user space

5.8.1. kmod　
kmod is the kernel module loader that allows kernel components to request the loading of a module. The kernel provides more than one routine, but here we'll look only at request_module. This function initializes arg[1] with the name of the module to load. /sbin/modprobe uses the configuration file /etc/modprobe.conf to do various things, one of which is to see whether the module name received from the kernel is actually an alias to something else (see Figure 5-3).
kmod是内核模块的加载器，它充许内核组件请求加载一个模块。内核提供了不只一个程序，但我们只会看一下request_module。这个函数初用要加载的模块名来始化arg[1]。/sbin/modprobe使用/ect/modprobe.conf这个配置文件来做一些其它的事，其中之一就是看从内核收到的要加载的模块名是否实际上与某些事关联在一起（参见图5－3）。

Here are two examples of events that would lead the kernel to ask /sbin/modprobe to load a module:
这里有两个事件的例子，这些事件引导内核要求/sbin/modprob去加载一个模块：

When the administrator uses ifconfig to configure a network card whose device driver has not been loaded yetsay, for device eth0[*]the kernel sends a request to /sbin/modprobe to load the module whose name is the string "eth0". If /etc/prorobe.conf contains the entry "alias eth0 3c59x", /sbin/modprobe tries loading the module 3c59x.ko.
当管理员使用ifconfig来配置一个还没有加载驱动程序的网卡时，例如eth0设备，内核发送一个请求到/sbin/modprobe来加载名为“eth0”的设备。如果/ect/prorobe.conf里包含了条“alias eth0 3c59x”的信息，/sbin/modprobe就试着加载3c59x.ko这个模块。

[*] Note that because the device driver has not been loaded yet, eth0 does not exist yet either.
注意，因为这里设备的驱动还没有被加载，所以eth0还不存在！

When the administrator configures Traffic Control on a device with the IPROUTE2 package's tc command, it may refer to a queuing discipline or a classifier that is not in the kernel. In this case, the kernel sends /sbin/modprobe a request to load the relevant module.
当管理员在一个设备上使用IPROUTER2软件包里的tc命令来配置网络流量控制时，这可能会涉及到队列原则和一个不在内核里的分类器。在这种情况下，内核发送一个请求给/sbin/modprobe去加载相关的模块。

For more details on modules and kmod, refer to Linux Device Drivers.
关于kmod和模块的细节，可以参考Linux Device Drivers.

5.8.2. Hotplug 热插拨
Hotplug was introduced into the Linux kernel to implement the popular consumer feature known as Plug and Play (PnP) . This feature allows the kernel to detect the insertion or removal of hot-pluggable devices and to notify a user-space application, giving the latter enough details to make it able to load the associated driver if needed, and to apply the associated configuration if one is present.
热插拨被引入到Linux内核中去实现众所周知的流行PnP(即插即用)的用户特性。这一特性充许内核检测插入和移走的支持热插拨的设备，并且会告知用户空间的应用程序，如果有一个出现时就应用相关的配置。后面会足够详细的介绍是如何在需要时加载相关的驱动。

Hotplug can actually be used to take care of non-hot-pluggable devices as well, at boot time. The idea is that it does not matter whether a device was hot-plugged on a running system or if it was already plugged in at boot time; the user-space helper is notified in both cases. The user-space application decides whether the event requires any action on its part.
热插拨技术实际上可以在启动时，很好的应用在非热插拨设备中。这样使用是因为它并不关注在启动时，已经插在系统中的设备是不是热插拨的；用户空间的助手程序在两种情况下都会被通知。用户空间的应用程序来决定是否要在事件上对自己的设备做出响应。

Linux systems, like most Unix systems, execute a set of scripts at boot time to initialize peripherals, including network devices. The syntax, names, and locations of these scripts change with different Linux distributions. (For example, distributions using the System V init model have a directory per run level in /etc/rc.d/, each one with its own configuration file indicating what to start. Other distributions are either based on the BSD model, or follow the BSD model in compatibility mode with System V.) Therefore, notifications for devices already present at boot time may be ignored because the scripts will eventually configure the associated devices.
Linux系统，或者是类Unix系统，在系统启动时要执行大量的脚本来初始化外围设备，包括网络设备。这些脚本的语法，名字，以及存放的位置都会根据不同的发生版有所变化。（例如，使用System V来初始化模型的发行版，/etc/rc.d/对每个运行级上都有一个目录，每个人在启动时都有自己的配置文件来决定启动什么。其它的发行版，有基于BSD模型的，也有根据BSD模型而兼容System V的模型。）因此，发给在启动时已经出现的设备的通知可能会被忽略，因为脚本最终会配置这相关的设备。

When you compile the kernel modules, the object files are placed by default in the directory /lib/modules/kernel_version/, where kernel_version is, for instance, 2.6.12. In the same directory you can find two interesting files: modules.pcimap and modules.usbmap. These files contain, respectively, the PCI IDs[*] and USB IDs of the devices supported by the kernel. The same files include, for each device ID, a reference to the associated kernel module. When the user-space helper receives a notification about a hot-pluggable device being plugged, it uses these files to find out the correct device driver.
当你编译内核模块时，目录文件已经放在默认的目录/lib/modules/ker_version/中，当kernel_version给定版本，例如2.6.12。在同样的目录下，你可发现两个有趣的文件：modules.pcimap和modules.usbmap。这些文件分别包括内核所支持的所有设备的PCI的ID，和USB的ID。同样的文件还包括每个设备的ID，以及它所关联到内核的模块。当用户空间的助手程序收到一个热插拨的设备被插入的通知时，它使用这些文件去查找出正确的设备驱动。

[*] The section "Example of PCI NIC Driver Registration" in Chapter 6 gives a brief description of a PCI device identifier.

The modules.xxxmap files are populated from ID vectors provided by device drivers. For example, you will see in the section "Example of PCI NIC Driver Registration" in Chapter 6 how the Vortex driver initializes its instance of pci_device_id. Because that driver is written for a PCI device, the contents of that table go into the modules.pcimap file.
这个modules.xxxmap文件是板上组装的由设备驱动提供的ID向量。例如，你会在第6章中的“一个PCN　NIC设备驱动注册实例”这一节中看到，Vortex驱动是如何初始化它的一个pci_device_id实例。因这这个驱动被写成支持一个PCI设备，所以它的内容表存放在modules.pcimap文件中。

If you are interested in the latest code, you can find more information at http://linux-hotplug.sourceforge.net.
如果你已经对最后的代码吸引住，你可以在http://linux-hotplug.sourceforge.net上找到更多的信息。

5.8.2.1. /sbin/hotplug
The default user-space helper for Hotplug is the script[] /sbin/hotplug, part of the Hotplug package. This package can be configured with the files located in the default directories /etc/hotplug/ and /etc/hotplug.d/.
默认的用户空间支持热插拨的助手程序在/sbin/hotplug脚本中，是热插拨软件包中的一部份。这个包可以通过在默认目录/etc/hotplug/ and /etc/hotplug.d中配置。

[] The administrator can write his own scripts or use the ones provided by the most common Linux distributions.

The kobject_hotplug function is invoked by the kernel to respond to the insertion and removal of a device, among other events. kobject_hotplug initializes arg[0] to /sbin/hotplug and arg[1] to the agent to be used: /sbin/hotplug is a simple script that delegates the processing of the event to another script (the agent) based on arg[1].
内核调用kobject_hotplug函数在其它事件中来报告一个设备的插入和移除。kobject_hotplug用/sbin/hotplug来初始arg[0]，同时arg[1]以这样的方式来做代理：/sbin/hotplug是一个简单的脚本，用于代理另一个基于arg[1]脚本（代理）的进程事件。（不明白说的啥）

The user-space helper agents can be more or less complex based on how fancy you want the auto-configuration to be. The scripts provided with the Hotplug package try to recognize the Linux distribution and adapt the actions to their configuration file's syntax and location.
用户空间的助手代码可以有更多或者更少的复杂性。这要基于你的想象力，你想自动到什么程度。这个软件包提供的脚本试着识别Linux的发行版，并适配它的配置文件的语法和位置。

Let's take networking, the subject of this book, as an example of hotplugging. When an NIC is added to or removed from the system, kobject_hotplug initializes arg[1] to net, leading /sbin/hotplug to execute the net.agent agent.
让我们来看看网络，这也是本书的主题，做为一个热插拨的例子。当一个NIC添加到系统或者从系统中移除时，kobject_hotplug 给网络初始化arg[1]，让/sbin/hotplug去执行这个net.agent代理。

Unlike the other agents shown in Figure 5-3, net.agent does not represent a medium or bus type. While the net agent is used to configure a device, other agents are used to load the correct modules (device drivers) based on the device identifiers.
与图5－3中所显示的其它代理不同，net.agent并不会响应一个媒体或者总线类型。当net代理被用于配置一个设备时，另一个代理就被用于根据模块的设备ID来锁定上下文。

net.agent is supposed to apply any configuration associated with the new device, so it needs the kernel to provide at least the device identifier. In the example shown in Figure 5-3, the device identifier is passed by the kernel through the INTERFACE environment variable.
net.agent是假设可以支持任何关于新设备的配置的，所以它需要内核最少提供设备标识。在图5－3的例子中，这个设备标识是内核通过INTERFACE环境变量为传递的。

To be able to configure a device, it must first be created and registered with the kernel. This task is normally driven by the associated device driver, which must therefore be loaded first. For instance, adding a PCMCIA Ethernet card causes several calls to /sbin/hotplug; among them:
为了可以配置一个设备，它开始必须被创建和注册到内核。这个任务通常是由相关的设备驱动来完成的，也就是说，这（设备驱动）必须是要先加载的。

One leading to the execution of /sbin/modprobe,[*] which will take care of loading the right module device driver. In the case of PCMCIA, the driver is loaded by the pci.agent agent (using the action ADD).
可执行文件/sbin/modprobe，用于关注加载正确的设备驱动模块。在PCMCIA情况下，驱动会由pci.agent这个代理来加载（使用ADD动作）。

[*] Unlike /sbin/hotplug, which is a shell script, /sbin/modprobe is a binary executable file. If you want to give it a look, download the source code of the modutil package.
与/sbin/hotplug不一样，这只是一个脚本，/sbin/modprob是一个二进制的可执行文件。如果你想看看它，可以下载modutil软件包。

One configuring the new device. This is done by the net.agent agent (again using the action ADD).
一个配置新设备，这是由net.ageng代理来完成的（再次使用ADD动作）。

5.7. Initializing the Device Handling Layer: net_dev_init
设备处理层的初始化：net_dev_init

An important part of initialization for the networking code, including Traffic Control and per-CPU ingress queues, is performed at boot time by net_dev_init, defined in net/core/dev.c:
网络代码初始化的一个很重要的部份，包括流量控制和每个CPU的入队列，都是在启动时候，由net_dev_init来完成的，它们在net/core/dev.c中定义：

static int _ _init net_dev_init(void)
{
    ...
}
subsys_initcall(net_dev_init);

See Chapter 7 for how the subsys_initcall macros ensure that net_dev_init runs before any NIC device drivers register themselves, and why this is important. You also will see why net_dev_init is tagged with the _ _init macro.
参见第7章，subsys_initcall这个宏确保net_dev_init在NIC设备驱动注册他们自己之前运行，以及为什么这个很重要。你同样可以看到，为什么net_dev_init要用__init这个宏标记。

Let's walk through the main parts of net_dev_init:
让我们看看net_dev_init的主要部份：

The per-CPU data structures used by the two networking software interrupts (softirqs) are initialized. In Chapter 9, we will see what a softirq is and go into detail on how the networking code uses softirqs.
每个CPU的数据结构是由两个网络软件中断（软中断）初始化所使用。在第9章中，我们会看到什么是软中断以及网络代码是如何使用它们详细情况。

When the kernel is compiled with support for the /proc filesystem (which is the default configuration), a few files are added to /proc with dev_proc_init and dev_mcast_init. See the later section "Tuning via /proc Filesystem" for more details.
当内核编译成支持/proc文件系统时（这是一个默认配置），会有一些文件和with_proc_init一起添加到/proc中。详细情况参见后面的“通过/proc文件系统调整（内核）”章节。

netdev_sysfs_init registers the net class with sysfs. This creates the directory /sys/class/net, under which you will find a subdirectory for each registered network device. These directories include lots of files, some of which used to be in /proc.
netdev_sysfs_init通过sysfs注册网络类。这会创建一个/sys/class/net/的目录，在这个目录下，你可以发现与每一个注册的网络设备的子目录。这个目录包括话多文件，其中有一些就/proc所使用。

net_random_init initializes a per-CPU vector of seeds that will be used when generating random numbers with the net_random routine. net_random is used in different contexts, described later in this section.
net_random_init初始化每个CPU的向量种子数，这个数会通过net_radnom例程一起用于生成随机数。net_random在不同的上下文中使用，在这一节的后面会说明。

The protocol-independent destination cache (DST), described in Chapter 33, is initialized with dst_init.
与协议相关的目的缓存（DST）是通过dst_init初始的，这个会在第33章中说明。

The protocol handler vector ptype_base, used to demultiplex ingress traffic, is initialized. See Chapter 13 for more details.
处理协议的向量ptype_base也被初始化，它用于多功能的入队流量管理，详细的参见第13章。

When the OFFLINE_SAMPLE symbol is defined, the kernel sets up a function to run at regular intervals to collect statistics about the devices' queue lengths. In this case, net_dev_init needs to create the timer that runs the function regularly. See the section "Average Queue Length and Congestion-Level Computation" in Chapter 10.
当OFFLINE_SAMPLE符号被定义时，内核设置了一个函数在规则的间隙运行，用于收集与设备队列长度相关的统计。在这种情况下，net_dev_init需要创建一个计时器，用于规则的运行这个函数。参见第10章的“平均队列长度和拥塞等级运算”。

A callback handler is registered with the notification chain that issues notifications about CPU hotplug events. The callback used is dev_cpu_callback. Currently, the only event processed is the halting of a CPU. When this notification is received, the buffers in the CPU's ingress queue are dequeued and are passed to netif_rx. See Chapter 9 for more detail on per-CPU ingress queues.
一个回调句柄被注册到通知链中，这样可以确保CPU会通知热插事件。这个回调使用的是dev_cpu_callback。目前，唯一的事件处理就是暂停CPU。当收到这个通知时，CPU里的入队列缓存队列就被清出，然后传给netif_rx。详细的参见第9章的每CPU入队列。

Random number generation is a support function that the kernel performs to help randomize some of its own activity. You will see in this book that many networking subsystems use randomly generated values. For instance, they often add a random component to the delay of timers, making it less likely for timers to run simultaneously and load down the CPU with background processing. Randomization can also defend against a Denial of Service (DoS) attack by someone who tries to guess the organization of certain data structures.
随机数生成器是一个辅助功能，可以让内核帮助它们实现一些随机化的活动。你会从本书中看到，有很多网络子系统使用了随机生成数。例如，他们经常添加一个随机的组件到计时器中，使它不至于让计时器同时地运行，并在后台进程中分担CPU。随机还可以防止一些人使用DOS攻击来猜测组织结构和数据结构。

The degree to which the kernel's numbers can be considered truly random is called system entropy . It is improved through contributions by kernel components whose activity has a nondeterministic aspect, and networking often falls in this category. Currently, only a few NIC device drivers contribute to system entropy (see earlier discussion on SA_SAMPLE_RANDOM). A patch for kernel 2.4 adds a compile time option that you can use to enable or disable the contribution to system entropy by NICs. Search the Web using the keyword "SA_SAMPLE_NET_RANDOM," and you will find the current version.
可以被内核数所真实信任的随机数的度，被称为系统熵（译：看原文，不知道什么意思）。这可以增加内核中那些行为有不确定特性的组件的贡献，并且一些网络经常落到这一话题中。目前，只有少数的NIC设备驱动给内核贡献了熵（参见前面所讨论的SA_SAMPLE_RANDOM）。有一个给2.4的补丁，添加了编译选项。你可以通过这些选项打开或者关闭，是否让NIC设备给内核贡献熵。从网络上搜索“SA_SAMPLE_NET_RANDOM”，你会发现最新的版本内容。

5.7.1. Legacy Code　遗传代码
I mentioned in the previous section that the subsys_initcall macros ensure that net_dev_init is executed before any device driver has a chance to register its devices. Before the introduction of this mechanism, the order of execution used to be enforced differently, using the old-fashioned mechanism of a one-time flag.
我在前面的章节中已经提到过，subsys_initcall宏用于确保net_dev_init在任何设备注册它的驱动之间被调用。在介绍这个机制之前，执行的顺序通常是强制要求不同的，在老的形式中是使用一个时间标志。

The global variable dev_boot_phase was used as a Boolean flag to remember whether net_dev_init had to be executed. It was initialized to 1 (i.e., net_dev_init had not been executed yet) and was cleared by net_dev_init. Each time register_netdevice was invoked by a device driver, it checked the value of dev_boot_phase and executed net_dev_init if the flag was set, indicating the function had not yet been executed.
全局变量dev_boot_phase当成一个逻辑标志位，用于记住net_dev_init是否已经被执行过。它在初始化时设置为1（就是说net_dev_init还没有被执行），并由net_dev_init清零。每次register_netdevice被设备驱动调用时，它就检测dev_boot_phase这个值，关在标志被设置的时候执行net_dev_init，即指示这个函数还没有被执行过。

This mechanism is not needed anymore, because register_netdevice cannot be called before net_dev_init if the correct tagging is applied to key device drivers' routines, as described in Chapter 7. However, to detect wrong tagging or buggy code, net_dev_init still clears the value of dev_boot_phase, and register_netdevice uses the macro BUG_ON to make sure it is never called when dev_boot_phase is set.[*]
这种机制现在并不需要了，因为当正确的标签被应用到设备驱动程序的关键字上时，register_netdevice不能在net_dev_init之前被调用，这会在第7章中讨论。然而，为了检测错误的标签，或者是代码bug，net_dev_init还是会清除dev_boot_phase的值，并register_netdevice用宏BUG_ON来确保当dev_boot_phase被设置时，这决对不会调用。

[*] The use of the macros BUG_ON and BUG_TRAP is a common mechanism to make sure necessary conditions are met at specific code points, and is useful when transitioning from one design to another.
BUG_ON和BUG_TRAP宏的使用是一种常用的机制，用于在一些特殊的代码点上，保证一些必须的条件，而且在从一个设计人转到另一个人那里的时候特别有用。