5.7. initializing the device handling layer: initialization of the net_dev_init device processing layer: net_dev_init

Directory: http://www.cnblogs.com/WuCountry/archive/2008/11/15/1333960.html
 
[Do not provide illustrations. You are advised to download the source book from the Internet]

5.7. initializing the device handling layer: net_dev_init
Device processing layer initialization: net_dev_init

An important part of initialization for the networking code, including traffic control and per-CPU ingress queues, is running med at boot time by net_dev_init, defined in net/CORE/dev. C:
NetworkCodeAn important part of initialization, including traffic control and the inbound queue of each CPU, is completed by net_dev_init at startup. They are in net/CORE/dev. defined in 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.
See Chapter 7th. The subsys_initcall macro ensures that net_dev_init runs before the NIC Device Driver registers themselves and why this is important. You can also see why net_dev_init uses the macro _ init.

Let's walk through the main parts of net_dev_init:
Let's take a look at the main part of 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.
The data structure of each CPU is used by two network software interruptions (soft interruptions) initialization. In chapter 2, we will see what soft breaks are and how network code uses them in detail.

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.
When the kernel is compiled into a/proc file system (this is a default configuration), some files will be added together with with_proc_init to/proc. For details, see the "adjust the kernel through/proc file system" section.

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 registers network classes through sysfs. This will create a directory of/sys/class/NET/. Under this directory, you can find subdirectories with each registered network device. This directory contains multiple files, some of which are used by/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 initializes the number of vector seeds for each CPU. This number is used together to generate a random number through the net_radnom routine. Net_random is used in different contexts, which will be described later in this section.

The protocol-independent destination cache (DST), described in chapter 33, is initialized with dst_init.
The protocol-related destination cache (DST) is initiated through dst_init, which will be described in Chapter 33rd.

The protocol handler vector ptype_base, used to demultiplex ingress traffic, is initialized. See chapter 13 for more details.
The processing protocol vector ptype_base is also initialized. It is used for multi-function queue traffic management. For details, see chapter 13th.

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.
when the offline_sample symbol is defined, the kernel sets a function to run between rules to collect statistics related to the device queue length. In this case, net_dev_init needs to create a timer for the rule to run this function. See "average queue length and congestion level calculation" in Chapter 10th ".

a callback handler is registered with the notification chain that issues communications 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.
a callback handle is registered. To the notification chain, so that the CPU will be notified of the Hot Plug event. This callback uses dev_cpu_callback. Currently, the only event processing is to pause the CPU. When this notification is received, the cache queue of the inbound queue in the CPU is cleared and sent to netif_rx. For more information, see the CPU entry queue in Chapter 9th.

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 implements 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 ca N also defend against a denial of service (DoS) attack by someone who tries to guess the organization of certain data structures.
the random number generator is an auxiliary function that allows the kernel to help them implement randomization activities. As you can see in this book, many network subsystems use a random number. For example, they often add a random component to the timer so that it does not allow the timer to run simultaneously and share the CPU in the background process. The random structure can also prevent some people from using DoS attacks to guess the organizational structure and data structure.

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 comp Ile time option that you can use to enable or disable the contribution to system entropy by role. search the Web using the keyword "sa_sample_net_random," and you will find the current version.
the degree of random numbers that can be truly trusted by kernel numbers is called system entropy ). This can increase the contribution of components whose behaviors have uncertain characteristics in the kernel, and some networks often fall into this topic. Currently, only a few Nic device drivers contribute entropy to the kernel (see sa_sample_random discussed earlier ). There is a patch for 2.4 that adds the compilation option. You can enable or disable these options to determine whether to enable Nic devices to contribute entropy to the kernel. Search for "sa_sample_net_random" from the Internet and you will find the latest version.

5.7.1. legacy code genetic 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 mechanic of a one-time flag.
As mentioned in the previous chapter, the subsys_initcall macro is used to ensure that net_dev_init is Any device registers it with the driver to be called. Before introducing this mechanism, the execution sequence is usually forced to be different, and a time sign is used in the old form.

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.
the global variable dev_boot_phase is used as a logical flag to remember whether net_dev_init has been executed. It is set to 1 during initialization (that is, net_dev_init has not been executed) and is cleared by net_dev_init. Every time register_netdevice is called by a device driver, it detects the value of dev_boot_phase and runs net_dev_init when the flag is set, indicating that this function has not been executed.

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 parameter, and register_netdevice uses the macro bug_on to make sure it is never called when dev_boot_phase is set. [*]
This mechanism is not needed now, because when the correct tag is applied to the device driverProgramRegister_netdevice cannot be called before net_dev_init. This will be discussed in chapter 7th. However, net_dev_init still clears the value of dev_boot_phase to detect incorrect labels or code bugs, and register_netdevice uses the macro bug_on to ensure that this will not be called when dev_boot_phase is set.

[*] 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.
The use of bug_on and bug_trap macros is a common mechanism used to ensure certain necessary conditions on some special code points, it is particularly useful when switching from a designer to another person.