Implementing Kernel driver Modules

Examples are from the "Android system source code scenario analysis," the second chapter copied, in the course of learning still encountered a lot of problems.

Personal experience: Before learning the second chapter should be the "Linux device Driver" book at least the first four chapters to read, understand some basic concepts and background knowledge, but this book is slightly old, such as Sysfs there is no explanation, more Google bar.

The second chapter of this book should be understood and further down, as this simple example runs from the bottom up through the layers of the Android system and is the basis for understanding the following chapters.

Here is a list of the issues and workarounds that I have encountered.

• What are the relationships and roles of the three types of file system interfaces?

It implements the proc file system interface, the traditional device file system interface and the Devfs file system interface.

Unix-like systems have a basic philosophy of design: almost all data entities are abstracted into a unified interface-a file to look at. PROCFS, DEVFS and Sysfs are the embodiment of this design.

Each file in the/dev directory corresponds to a device that can interact with the kernel by manipulating these files, but Devfs has some drawbacks, such as the inflexible naming, the inability to specify the file name, and all the files in the/dev/root directory. Then the birth of SYSFS, it is actually connected to the system of equipment organized into a hierarchical file system, more clear and easier to manage than DEVFS, Sysfs mounted under the/sys.

/proc file system mainly contains three kinds of content: Process related parts, System Information part and system self-information part. Obviously in this example, the interfaces of the PROCFS and SYSFS sections are not necessary as a first example of getting started.

So I'm going to implement only the parts of the traditional device filesystem interface, SYSFS and PROCFS are temporarily not implemented. I think it can still work in full.

• Compilation issues

• In the __freg_setup_dev function, the call to the function Init_mutex was compiled with an error because the function was enabled and changed to the following:

1);

• Modify the kernel Kconfig file. I compiled the kernel is 3.4, need to add in Drivers/kconfig

" Drivers/freg/kconfig "

Rather than in the arch/arm/kconfig.

• Configuration
• In Mac OSX, when calling make Menuconfig error, the solution has been updated to the "Android source code, kernel compilation" In this blog post.
• After entering the make Menuconfig configuration interface, if you want to set enable Loadable module support, this block of interaction is a bit of a pit dad. The initial entry interface is such that the Enable loadable module support is not selected:

If you enter the submenu directly, you will find that the front is---and cannot be modified:

I thought it was my kernel version of the problem, Daoteng a half-day to understand: should be in the first level interface to enable Loadable module support Press Y, so that it selected:

Then enter in order to see and modify the child contents:

10,000 Grass mud Ma Yi Teng, harm Lao Tzu study half a day ...

• Debugging
• View Kernel log

I compiled the module into the kernel, but at first I couldn't find the Freg file under/dev, and I had to debug the code to see which step went wrong. FREG.C source more Call printk function Write log, I in each log string head added [Freg], as follows:

PRINTK (Kern_alert"[freg]initializing freg device.\n");

To filter out the log of Freg in the vast kernel log.

• Method One: You can use DMESG to view the kernel printing information, and then with grep as follows:

grep " \[freg\] " [freg]initializing freg device. [Freg] Succeeded to initialize Freg device.

• Method Two: You can add-show-kernel parameters when running emulator:

$ Emulator-kernel Arch/arm/boot/zimage-show-kernel &

Implementing Kernel driver Modules