14. Monthly Assessment

 

2. File descriptors and struct files

Each process has its own PCB (Process Control block), when the process is created, the PCB is created, when the process terminates, the PCB also with the end. This PCB is maintained this file descriptor, when the open file, return a file descriptor, this file descriptor is the file descriptor index, that is, a file descriptor in the implementation of an open file (struct file).

When opening a file, the system will be created for each open file in the kernel's space associated with the struct file, which is opened by the kernel, and the struct file is passed to any underlying function that operates on the file. The struct is not released until all the operation instances have ended.

So, the file descriptor is the index of the file descriptor table, and one of the file descriptor tables points to the open struct file, further, the pointer to the file descriptor sheet, pointing to the file structure, that is, the FD is pointing to the struct file struct.

The struct file struct has a struct file_operations structure, which points to the function implementation of the underlying driver. So when the file descriptor fd do read, write operation, it will be through the struct file inside the File_operations function point, to execute.

3, kernel module re-learning

3.1. Driver compilation Process Analysis

To compile a driver:

Makefile:

Linux_root: =/home/carlos/3516c/linux-3.0.y

Obj-m: = gpio.o

Default
Make-c $ (linux_root) m=$ (PWD) modules
Clean
Make-c $ (linux_root) m=$ (PWD) Clean

3.1.1, compile steps:

Make-c/home/carlos/3516c/linux-3.0.y m=/home/carlos/3516c/driver/gpio_newblue modules
Make[1]: Entering Directory '/home/carlos/3516c/linux-3.0.y '              //Enter the kernel directory
  CC [m] /home/carlos/3516c/driver/gpio_newblue/gpio.o               //Generate GPIO.O
  Building modules, Stage 2.
  Modpost 1 modules
  cc     /home/carlos/3516c/driver/gpio_newblue/ gpio.mod.o       //Generate GPIO.MOD.O
  LD [m] /home/carlos/3516c/ driver/gpio_newblue/gpio.ko           //Will GPIO.O and GPIO.MOD.O connection, generating Gpio.ko
Make[1]: Leaving directory '/home/carlos/3516c/linux-3.0.y '

Compile the time, is the first into the kernel directory, generate GPIO.O, then generate GPIO.MOD.C, eradicate GPIO.MOD.C generate GPIO.MOD.O, finally GPIO.MOD.O and gpio.o two files connected together to generate the final Gpio.ko.

When the compilation is complete, the resulting files are:

Basic target file + gpio.mod.c + gpio.mod.o + module.symvers + modules.order several main target files.

(1) Modules.order

Modules.order:kernel//home/carlos/3516c/driver/gpio_newblue/gpio.ko

The target file, which documents the current drive target, eventually generates the target file Gpio.ko

(2) GPIO.MOD.C + GPIO.MOD.O

GPIO.MOD.C: Is the file generated during the compilation process. The contents are:

Module_info (Vermagic, vermagic_string); Vermagic_string

struct Module __this_module
__attribute__ (Section (". Gnu.linkonce.this_module")) = {
. Name = Kbuild_modname,
. init = Init_module,
#ifdef Config_module_unload
. Exit = Cleanup_module,
#endif
. Arch = Module_arch_init,
};

static const Char __module_depends[]
__used
__attribute__ (Section (". Modinfo")) =
"Depends="; No dependency

Vermagic_string is the kernel string information, which records the kernel version information, GCC version, SMP and other configuration information. When GPIO.MOD.C compiled to GPIO.MOD.O, you can go to the contents of the inside: there is a lot of garbled, but is not garbled part, it is very important information:

ELF depends=vermagic=3.0.8 mod_unload ARMv5 gpiogcc: (hisilicon_v100 (Gcc4.4-290+uclibc_0.9.32.1+eabi+linuxpthread)) 4.4.1a,aeabi "

Visible, the kernel can be obtained from the version of 3.0.8, the compiler version is hisilicon_v100, further said that the hisilicon_v100 compiler is composed of 4.4 gcc and uclibc_0.9.32.1 Library, Linuxpthread Library.

This information is available when we use modinfo Gpio.ko .

3.2, to the driver to pass the parameter

The driver supports the parameter, and when the Insmod, the parameters are passed in. So when the driver is written, it needs to include:

Module_param (parameter name, parameter type, parameter permission);

Such as:

char *name = "abc"; Specifying default parameters

Module_param (name, Charp, 0644);

When loaded, the insmod xx.ko parameter name = argument value,

Both:

Insmod Gpio.ko name= "AAA"

When there is no input parameter, the default parameter value is used. If the driver has already been compiled into the kernel, it is possible to make the parameter in Uboot's Bootargs format: module name. Parameter name = argument value.

When the module is loaded, it will have a file with the same name as the module name (GPIO) under/sys/modules/, and the contents of the parameters will be printed to log:

Cat/var/log/message

3.3. Export of module symbols

Modules can be used:

Export_symbol (symbol name)

EXPORT_SYMBOL_GPL (symbol name)

A function or other inside a module is carried out everywhere, and other modules can be called.

Like what:

int add_a_b (int a, int b)

{

return a + B;

}

Export_symbol (Add_a_b);

When this module is compiled, the module guides the symbol information into the Module.symvers file.

When the module is loaded, the exported symbols can be found inside the/proc/kallsyms and can go to cat, which records all the symbols that are everywhere.

3.3.1, how to use the exported symbols

If the A module is exported symbols, how to be used by the B module. Obviously B module to call A everywhere symbols, obviously should know the information about the symbols, such as address information. As you can see, after module A exports symbols, the information is stored in the module.symvers.

$ Cat Module.symvers
0x00000000 Gpio_ioctl/home/carlos/3516c/driver/gpio_newblue/gpio (unknown)

Module.symvers, specify the address, the path of the module, and information about the exported symbols.

Method One:

Copy the module A module.symvers to the directory of Module B, so that when module B is compiled, the exported symbol can be found through the exported symbol information in Module.symvers.

However, it is obviously very troublesome to refer to other people's exported symbols if they are copied every time, so it is generally a good practice to use method two.

Method Two:

In the kernel compile, and the same as the compiler driver module, will also generate Module.symvers directory, specialized recording system so the symbol information is everywhere, module.symvers directory is generally in the top level directory, and is visible. So we just need to redirect the symbols from module A around to the kernel's module.symvers file.

Makefile of Module A:

Linux_root: =/home/carlos/3516c/linux-3.0.y

Obj-m: = gpio.o

Default
Make-c $ (linux_root) m=$ (PWD) modules
ARM-HISIV100NPTL-LINUX-GCC Gpiotest.c-o Gpiotest

Cat module.symvers >>/home/carlos/3516c/linux-3.0.y/module.symvers//export symbols to the kernel's total export symbol file
Clean
Rm-f Gpiotest
Make-c $ (linux_root) m=$ (PWD) Clean

When module A completes the normal compilation, it redirects the information of the Module.symvers file generated by itself and redirects the total module.symvers file of the kernel.

Call for module B:

extern int Add_a_b (int a, int b);

Makefile of Module B:

According to the normal Makefile can be directly compiled through. Because the module B compiles, it will be based on –C, jump into the kernel to compile, you can get the kernel to provide interface, header files, but also get the kernel's module.symvers files.

3.4, the driver module dependence

A module-dependent relationship exists when the module uses Export_export symbols for other modules.

Depending on the driver module, you can use Depmod to analyze the dependency of the driver module. The Depmod command, which analyzes the dependency of the driver module and saves the new dependency to:

/LIB/MODULES/3.19.0-15-GENERIC/MODULES.DEP inside.

-A: Parses, displays all dependencies, and writes dependencies to/LIB/MODULES/3.19.0-15-GENERIC/MODULES.DEP inside.

-N: Analysis relies on information that will depend on the printed output interface without writing to/LIB/MODULES/3.19.0-15-GENERIC/MODULES.DEP inside.

(1) Order of dependent loading

A provides a symbol to B, then B depends on A. So when loading, it should be a first load, and then complete the loading of B.

(2) Order of uninstallation

B after the uninstallation is complete, uninstall is completed in a.

4. ls Directory file only

Ls–l | grep "" ^d "

Because the "header" of the catalog file begins with D.

5. Precise timing

The kernel provides a more precise timing (but its own implementation is inaccurate), Ndelay (nanosecond), Mdelay (MS), but these appear to be accurate delays that are not accurate in the actual situation. The reason is that the driver thread that calls Udelay or Mdelay is the same as the normal user thread and is also subject to process scheduling. When the driver process does not occupy the CPU, it is likely to affect the scheduling of the process, so that the CPU in the execution of other threads, when again dispatched back, time delay, is not accurate. Therefore, if you want to precise timing, it is usually the same hardware timing method implementation.

6. Get the maximum number of files the process can open

The maximum number of open files for a process is limited, try to get them.

6.1. ulimit directive

The ULIMIT directive can be used to obtain system-restricted resource limits:

$ ulimit-a
Core file size (blocks,-c) 0
Data seg Size (Kbytes,-D) unlimited//process maximum data segment sizes,
Scheduling Priority (-e) 0
File size (blocks,-f) unlimited//Create the size, in blocks
Pending signals (-i) 123569
Max locked Memory (Kbytes, L) 32//maximum lockable RAM
Max memory Size (Kbytes,-M) unlimited//MAX RAM
Open files (-N) 1024//opening the maximum number of file descriptors
Pipe Size (bytes,-P) 8//Pipe Size 518 * 8
POSIX message queues (bytes,-Q) 819200
Real-time priority (-R) 0
Stack size (Kbytes,-s) 10240//Stack sizes
CPU time (seconds,-T) unlimited//CPU times consumed
MAX User Processes (-u) 123569//Most available, users max thread
Virtual Memory (Kbytes,-V) unlimited//MAX.
File locks (-X) Unlimited

Therefore, when we need to obtain the restricted information, we can directly ulimit–n. Different system environment, the restrictions given are not the same, according to their own system to obtain.

Modifies the restricted content specified by the Ulimit.

Ulimit–n XXXXX

6.2, function both: sysconf to get

Sysconf-get configuration information at run time

Synopsis
#include <unistd.h>

Long sysconf (int name);

The parameter of name, according to the designation, Open_max-_sc_open_max, on the maximum number of files that a process can has OPEN at any time.

14. Monthly Assessment