Differences between Linux 2.4 and kernel drivers

Differences between Linux 2.4 and kernel drivers-general Linux technology-Linux programming and kernel information. For more information, see the following. To thoroughly prevent incorrect operations on the kernel module being used, the Linux 2.4 kernel has been improved compared with the kernel in terms of loading and exporting the kernel module, this avoids system crashes (for example, forcible deletion of modules ). At the same time, when the driver needs to include header files in multiple files, you do not need to define a macro to check the kernel version. Compared with the 2.4 kernel, the 2.6 kernel greatly improves scalability and throughput. Its new features mainly include the use of new scheduler algorithms; the kernel preemption function significantly reduces the latency of interactive applications, multimedia applications and other similar applications, improves the thread model and NPTL support, it significantly improves the performance under a certain degree of load in the virtual environment, supports more file systems, introduces the memory pool technology, and supports more system devices, there are limits on large systems in the 2.4 kernel. the maximum number of devices in each category is 256, while the 2.6 kernel completely breaks these limits, supports 4095 main device types, each of which can support more than 1 million sub-devices, and reverse mapping ), the memory manager creates a linked list for each physical page, containing a pointer to the page table entries of each process on the current ing page. The linked list is called the PTE chain, which greatly improves the speed of finding processes mapped to a page.

The device driver of the Linux operating system runs in the kernel space, which involves many kernel operations. With the upgrade of the Linux kernel version, the driver development must also be modified accordingly, in short, when writing a device driver on the Linux kernel, pay attention to the following aspects:

1) The Linux2.6 kernel driver must be defined by the MODULE_LICENSE ("Dual BSD/GPL") Statement, instead of the 2.4 kernel MODULE_LICENSE ("GPL "). Otherwise, a warning is prompted during compilation.

2) the Linux kernel driver can use int try_module_get (& module) to load the module and use the module_put () function to uninstall the module, the macros MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT used by the 2.4 kernel are not required.

3) the definition of the struct file_operations in the driver model of the drivers for devices described above should be in the following format. This is because the definition form of struct has changed in the Linux kernel and does not support the original definition form.

4) For devices of the optimized type, the call function register_chrdev () in the test_open () function to register devices with the kernel can be upgraded to int register_chrdev_region (dev_t from, unsigned count, char * name ), if you want to dynamically apply for the master device number, you can use the int alloc_chrdev_region (dev_t * dev, unsigned baseminor, unsigned count, char * name) function to complete it. The original registration function can also be used, you cannot register a device whose device number is greater than 256. Similarly, the registration function for Block devices and network devices also has a corresponding substitution function.

5) There are significant changes in declaring whether the driver needs to export the symbol table. After the driver module is loaded into the kernel, any symbols it exports will become part of the public compliance table. These newly added symbols can be seen in/proc/ksyms. Generally, a module only needs to implement its own functions and does not need to export any symbols. However, if other modules need to use the symbols exported by the module, the module must export the symbols, only the displayed export symbols can be used by other modules. All symbols are not exported by default in the Linux2.6 kernel and do not need to be defined using the EXPORT_NO_SYMBOLS macro. In the 2.4 kernel, the opposite is true, it exports all symbols by default, unless EXPORT_NO_SYMBOLS is used, so this definition statement can be omitted in the example given above.

6) The Linx kernel unifies many device types and supports larger systems and more devices. The variable kdev_t in the Linux2.4 kernel has been abolished and replaced by dev_t. It expands to 32 bits, including 12-bit master device numbers and 20-bit device numbers. The called functions are unsigned int iminor (struct inode * inode) and unsigned int imajor (struct inode * inode), instead of int MAJOR (kdev_t dev) in Linux2.4) and int MINOR (kdev_t dev ).

7) All the memory allocation functions are not included in the header file, but are included in the file. The original memory allocation function does not exist. Therefore, when you need to use the memory allocation functions such as kmalloc () or kfree () in the driver, you must define the header file instead. At the same time, the specific parameters for applying for memory and releasing memory functions mentioned above have also changed, including the allocation mark GFP_BUFFER is canceled and replaced by GFP_NOIO and GFP_NOFS; the addition of _ GFP_REPEAT, _ GFP_NOFAIL, and _ GFP_NORETRY allocation flag makes memory operations more convenient.

8) because the memory allocation in some parts of the kernel is not allowed to fail, in order to ensure successful allocation in this case, the kernel of linux2.6 has developed an abstraction called "Memory Pool. The memory pool is actually equivalent to the backup cache for use in an emergency. To use the processing function of the memory pool, the header file must be included. Memory Pool processing functions include: mempool_t * mempool_create (), void * mempool_alloc (), void mempool_free (), int mempool_resize ();

In addition, it is worth mentioning that the 2.6 kernel is used for the difference. o is a common object file with the extension, and the kernel module extension is changed. ko, so the driver is finally compiled into a loaded module with the ko suffix. Pay attention when loading the driver module in the application.