Linux Kernel Lecture Hall (1) cornerstone Driver Model for device drivers (3)

For more information, see http://blog.csdn.net/z2007b. do not use this document for commercial purposes. The copyright is owned by the Wuwei monk.

 

It is a long time for everyone to wait. Due to the recent resignation, there are many complicated things. Today, I finally completed the resignation procedures, but there are still a bunch of things not done. If the update is slow, please forgive me. Let's get down to the truth.
As the saying goes: do not exercise fake tricks. Obviously, this handsome guy is not fake. In order to give everyone an intuitive understanding of the driver model, the younger brother spent a little time writing several small examples (currently only one ). This is to let everyone understand the most mysterious driver model. With these small examples, I can tell you with my previous articles on source code analysis, you have the basic kernel analysis capabilities.

First, let's talk about my environment: My Linux is installed on a virtual machine, and the Linux release is centos5.4. Later, we upgraded the kernel to 2.6.32.3. Why is this version selected? Because there is a corresponding kernel Upgrade tutorial on the Internet, this saves me a lot of text that is not very important to me (brother is very lazy ). Some may say that simply installing a release version of Linux is not enough. Why should we upgrade our own kernel? I think it is necessary to explain this. If you install only a bunch of kernel header files from the next online release (I like centos5 and rhel5 ), it is inconvenient to add debugging information to the kernel source code that is not self-written. If you download the source code to compile the kernel, you can directly add debugging information to the kernel source code, compile again and then OK. Besides, if a comrade who has never played a game spends a day doing a good job of this thing, it will also increase his confidence. OK. The game started:
First, provide the source code:
# Include <Linux/module. h>
# Include <Linux/device. h>
# Include <Linux/kernel. h>
# Include <Linux/init. h>

# Define wwhs_dbg (dbgbuf) printk (kern_err "wwhs: % s/n", dbgbuf );

Static struct kobject * wwhs_kobj;

Static int _ init wwhs_drvmode_init ()
{
Wwhs_dbg ("drvmode_init ");
Wwhs_kobj = kobject_create_and_add ("wwhs_drvmode", null );
If (! Wwhs_kobj)
Wwhs_dbg ("out of memory ");
Return 0;
}

Static void _ exit wwhs_drvmode_exit ()
{
Wwhs_dbg ("drvmode_exit ");
Kobject_del (wwhs_kobj );
}

Module_init (wwhs_drvmode_init );
Module_exit (wwhs_drvmode_exit );
Module_author ("wwhs ");
Module_description ("wwhs_drvmode ");
Module_license ("GPL ");
Makefile is provided below. make proper adjustments to makefile based on your development environment.

OBJ-M + = wwhs_drvmode.o
Kerneldir =/opt/linux-2.6.32.3
PWD: = $ (shell PWD)
ALL:
Make-C $ (kerneldir) M = $ (PWD) Modules
Clean:
Rm-RF *. O **. Ko **. Mod. C *. CMD *. symvers. tmp_versions. *. cmd

Put the two files in the same directory and enter the root mode.
Make.
In case of any exceptions, a kernel module such as wwhs_drvmode.ko can be generated.
Run: insmod wwhs_drvmode.ko
Run: dmesg
You can see the printed information.
Okay. Let's go to the/sys directory.
It was time to witness the miracle. We were excited to see a directory named wwhs_drvmode under the/sys directory.
Run rmmod wwhs_drvmode.
Run: dmesg
You can see that exit printing is available.
In the/sys directory, the directory wwhs_drvmode is missing.
Amazing!
This corresponds to our previous source code analysis. It's amazing.
If you are not interested in source code analysis, you should be interested now. If you do not understand it, go back to the first and second sections and read it carefully. Later games will become more and more fun. Smoke a cigarette first. See you later.

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/z2007b/archive/2011/05/06/6400561.aspx