Shulou(Shulou.com)06/02 Report--

How to register Linux driver development, I believe that many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Module registration

One thing you must keep in mind is that registration may fail when registering kernel devices, even if the simplest actions often require memory allocation, and the allocated memory may not be available, so the module code must always check the return value. and confirm that the required operation has actually been successful.

If it is confirmed that your module cannot be loaded at all after a particular type of failure, you must cancel any actions that register before the failure.

Error recovery is sometimes best handled with goto statements. We usually don't want to use goto, but in our opinion, this is a useful place for it. Careful use of goto in error situations can remove a lot of complex, over-aligned "structurally" logic, so goto is often used to handle errors in the kernel.

The module cleanup function must unregister any registration made by the initialization function, and the convention (but often not required) is to unregister the facility in the reverse order in which it was registered.

To minimize code repetition and streamline everything, what you should do is to call the cleanup function from initialization whenever an error occurs, and the cleanup function must then check the status of each item before unregistering it.

Note that the cleanup function cannot be marked _ _ exit when called by non-exit code.

Do not register any device until all your internal initialization that needs to support that device has been completed. As soon as cdev_add returns, your device is "alive" and the kernel can call its operations. You should not call cdev_add unless your driver is fully ready to handle operations on the device.

Registration of character devices, the kernel internally uses structures of type struct cdev to represent character devices, and you write to allocate and register one or more of these structures before the kernel invokes your device operation.

Allocation and initialization: cdev_init (...)

Notify the kernel: cdev_add (...)

Remove: cdev_del (...)

Module parameters

For details of using them, see moduleparam.h, where all module parameters should be given a default value; insmod only changes these values when the user explicitly tells it. The module can check for obvious parameters by corresponding to their default values.

The final module_param field is a permission value, and you should use the value defined in, which controls who can access the representation of these module parameters in sysfs. If perm is set to 0, there is no sysfs entry at all. Otherwise it appears under / sys/module with the given permissions. Using S_IRUGO as a parameter can be read by everyone, but cannot be changed; S_IRUGO | S_IWUSR allows root to change the parameter. Note that if a parameter is modified by sysfs, the parameter values seen by your module also change, but your module does not have any other notifications. You should not make the module parameters writable unless you are ready to detect the change and react accordingly.

After reading the above, have you mastered the method of how to register Linux driver development? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.