10 days to learn the Linux kernel Day---Summary (kconfig and Makefile & not Say Goodbye)

Original: 10 days to learn the Linux kernel Day---Summary (kconfig and Makefile & not Say Goodbye)

　　Very happy to share these with you, let me benefit, gratitude is also palpable,, code monkey words less, no way sensational,,,,,, Winter wind, blowing sad, flashback past, fade into blank ~ School of people less and more, like that year after we go home after the scene, Everywhere is barren, but our passion does not fade, still manic in the laboratory two o'clock in the morning half of the sky, perhaps today will be such a year, not the same is the people around to become learning younger sister, and we a few junior old guys are still in, for their favorite things, for their dreams, for our mutual companionship and continuous efforts, This is worthy of our youth, worthy of these unforgettable years ~ ~

Here are our two photos, last year before and this year before leaving,, paste out everyone to share, quack ~ and then share a picture of my Goddess (hey,,,, Thank you to your company.)

　　　　　　　　

Since it is a summary, then the last day I will share with you the method of learning the Linux kernel and the key points, I hope that the great gods to add more and discuss , learn from each other.

It is no exaggeration to say thatKconfig and makefile are the two files we rely on when we browse the kernel code, and the Kconfig distributed in each directory constitutes a distributed kernel configuration database. Each kconfig describes the kernel configuration menu associated with the owning directory source file, respectively. Basically, there is a kconfig file and a makefile file underneath each directory in the Linux kernel. Kconfig and Makefile are maps of the Linux kernel maze. Maps lead us to know a city, while Kconfig and makefile let us understand the structure under a kernel directory. Every time we browse kernel to find the piece of code that belongs to us, we should look at the two files in the directory first.

Here is a brief introduction to Kconfig　　

Each menu item has a keyword identifier, and the most common is the CONFIG.

Grammar:
Config symbol

Options
<!--[If!supportlinebreaknewline]-->
<!--[endif]-->

Symbol is the new menu item, the options are the properties and choices under this new menu item

The options section includes:

1. Type definition:
Each config menu item must have a type definition, bool: Boolean type, TriState: Built-in, module, remove, String: String, Hex: 16, Integer: Integer

2, dependent type definition depends on or requires
Refers to whether the appearance of this menu depends on another definition

3, the definition of help
Just add help with the keyword or assist------
<!--[If!supportlinebreaknewline]-->
<!--[endif]-->

Basic elements of the Kconfig file:

1.config Entries (Entry)

Config is the keyword that represents the beginning of a configuration option, followed by the Tmpfs_posix_acl is the name of the configuration option, omitting the prefix "Config_"

BOOL represents a variable type, the type of "Config_ Tmpfs_posix_acl", with 5 types: bool, tristate, String, hex, and int, where tristate and string are the basic types

Values for bool variables: Y and N

Value of the tristate variable: y, N, and M

Value of string variable: string

The string after bool "Tmpfs POSIX Access Control Lists" is a hint message, when you move the cursor up or down in the configuration interface to select it, you can set it by pressing the space or the ENTER key

Config_ Value of Tmpfs_posix_acl

Depends on: Indicates a dependency on xxx, and "depends on TMPFS" means that the current configuration option will only appear if the TMPFS configuration option is selected, in order to set current configurations options

2.menu entries

The menu entry is used to generate menus in the following format:

Menu "Floating poing emulation"

Config FPE_NWFPE

..............

Config FPE_NWFPE_XP

.............

Endmenu

Floating poing emulation is the menu name after menu, there are many config entries between menu and Endmenu, as shown in the Configuration interface:

Floating poing Emulation--->

[] Fpe_nwfpe

[] Fpe_nwfpe_xp

3.choice entries

The choice entry combines several similar configuration options for user-selectable or multi-select

Choice

Prompt "ARM system type"

Default Arch_versatile

Config arch_aaec2000

.........

Config Arch_realview

.........

Endchoice

Prompt "arm system type" gives the message "arm system type", the cursor is selected and entered to see the configuration options defined by multiple config entries choice the variables defined in the entry are only bool and tristate

4.comment entries

The comment entry is used to define some help information that appears in the first line of the interface, such as the following code in ARCH/ARM/KCONIFG:

" floating point emulation " "At least one emulation must is selected"config fpe_nwfpe .....                                                                                                                                                                         config Fpe_nwfpe_xp

5.source entries

The source entry is used to read another Kconfig file, such as:

SOURCE "NET/KCONIFG"

　　Introduce makefile

　　Makefile is much shorter than kconfig, the makefile of the kernel is divided into 5 components:

• Makefile the topmost Makefile
• The current configuration document of the. config kernel, which becomes part of the top-level makefile at compile time
• arch/$ (ARCH)/makefile and architecture-related Makefile
• makefile.* some specific Makefile rules
• The kbuild level makefile about 500 documents at all levels of the directory, compiling the source code into modules or into the kernel based on the macro definitions and other compilation rules passed down from the upper makefile. The top-level makefile document reads the contents of the. config document and is generally responsible for the build kernel and modules. Arch Makefile provides additional information about the architecture. The content of the. config is the result of the Kconfig document configuration at the time of make menuconfig.

For the Makefile function, we start with the initialization function, and for a subsystem or a driver, the kernel uses a subsys_initcall or Module_init macro to specify the initialization function. in the drivers/usb/core/usb.c file , we can find the following code:

940　　Subsys_initcall (Usb_init);　　Tell us Usb_init is the real initialization function of the USB subsystem,941 module_exit (usb_exit); will be the cleanup function at the end of the entire USB subsystem

In order to study the implementation of the USB subsystem in the kernel, we need to start from the usb_init function to look at,,, the following code to ask the great God, do not understand AH

865 Static int__init Usb_init (void)866 {867 intretval;868 if(NOUSB) {869Pr_info ("%S:USB Support disabled\n", usbcore_name);870 return 0;871 }872873retval =ksuspend_usb_init ();874 if(retval)875 Goto  out;876retval = Bus_register (&usb_bus_type);877 if(retval)878 Gotobus_register_failed;879retval =usb_host_init ();880 if(retval)881 Gotohost_init_failed;882retval =usb_major_init ();883 if(retval)884 Gotomajor_init_failed;885retval = Usb_register (&usbfs_driver);886 if(retval)887 Gotodriver_register_failed;888retval =usb_devio_init ();889 if(retval)890 Gotousb_devio_init_failed;891retval =usbfs_init ();892 if(retval)893 Gotofs_init_failed;894retval =usb_hub_init ();895 if(retval)896 Gotohub_init_failed;897retval = Usb_register_device_driver (&Usb_generic_driver, this_module);898 if(!retval)899 Goto  out; the901Usb_hub_cleanup ();902hub_init_failed:903Usbfs_cleanup ();904fs_init_failed:905Usb_devio_cleanup ();906usb_devio_init_failed:907Usb_deregister (&usbfs_driver);908driver_register_failed:909Usb_major_cleanup ();910major_init_failed:911Usb_host_cleanup ();912host_init_failed:913Bus_unregister (&usb_bus_type);914bus_register_failed:915Ksuspend_usb_cleanup ();916  out:917 returnretval;918}

API　　 Feelings (I do not understand here, the concept of API I have not built up in my mind, posted out to share the attention of everyone)

"It is not important to be an expert in a particular field than to know the importance of the technology you are using. Knowing that a particular API call is not a good thing, when you need him, just query it. "It's from a translated blog that I've seen," he said. What I want to emphasize is that this is the right thing to do with application-oriented programming, but the kernel API is not exactly the same.

The kernel is quite complex and difficult to learn, but when you learn to some extent, you will find that if you intend to write kernel code, the last concern is still API interface, but these APIs are mostly cross-platform, to meet portability. Kernel hackers have basically standardized and documented these interfaces, all you have to do is call. Of course, when using, it is best to use the topic of portability in the kernel coding conventions in the heart, so that the portability of the code will be written. Just like an application, you can use the dynamic library API provided by the developer, or use the open source API. The same is called API, and the difference is that using kernel APIs is a lot more than using the app API to understand things.

When you understand the implementation of the operating system---these implementations are fundamental to the application of the support AH---when you write the application, the application of multi-threading, timers, synchronization lock mechanism and so on, using the shared library API, contact the operating system, This allows you to consider the document description of the API in conjunction with the corresponding support implementations in the kernel that you have learned, which will guide you in choosing which API interface to use to choose the most efficient implementation. If you have a good understanding of system programming, it is not only beneficial to application programming, it can even be said to be of great benefit.

　　Kernel documentation

Finally, the relevant kernel documents, the kernel code contains a large number of documents, these documents for learning to understand the core is invaluable, remember, at any time, they should be in our minds should be higher than the various core reference books, It's all in English. But fortunately, Gaga, a freshman when the English level six, or a little confidence, but the past two years did not know that their English has not forgotten, the following are some of our core new people should read the document.

Readme This file first briefly introduces the background of the Linux kernel, then describes how to configure and compile the kernel, and finally tells us what to do if there is a problem.

Documentation/changes This file gives a list of the minimum packages needed to compile and use the kernel.

Documentation/codingstyle This file describes the kernel's preferred coding style, and all code should follow the specifications defined inside it.

Documentation/submittingpatches

Documentation/submittingdrivers

Documentation/submitchecklist//These three files describe how to commit the code, where submittingpatches gives the process of creating and submitting patches,

Submittingdrivers describes how to submit device drivers to different versions of the kernel tree, such as 2.4, 2.6, and Submitchecklist describes some of the things that you need to check your code for before committing your code.

Documentation/stable_api_nonsense.txt This file explains why the kernel does not have a stable internal API (the interface to the user space-the system call-is stable), which is critical to understanding the Linux development philosophy, It is also important for developers who move the development platform from other operating systems to Linux.

Documentation/stable_kernel_rules.txt explains the rules published by the stable kernel (stable releases) and how patches are submitted to these versions.

Documentation/securitybugs kernel developers are very concerned about security issues, if you think you have found such a problem, you can based on the contact information given in this file to submit the bug, so as to solve the problem as soon as possible.

Documentation/kernel-docs.txt This file lists many of the kernel-related documents and books, and there is no shortage of classics.

Documentation/applying-patches.txt This file answers how to patch the kernel.

Documentation/bug-hunting This file is about finding, submitting, and correcting bugs.

Documentation/howto This file will guide you through how to become a kernel developer and learn how to work with the kernel development community. It does not include any technical details about kernel programming as much as possible, but it will guide you to the right way to get that knowledge.

　　Summary

The last day did not mention some specific knowledge about the kernel, just want to focus on sharing kconfig and makefile, which is essential for learning the kernel, of course, the above mentioned is also read a lot of Daniel's articles and consult some relevant knowledge, we can refer to an article, Specifically, I attach the link below: http://blog.chinaunix.net/uid-26258259-id-3783679.html unconsciously this series of articles is about to end, oneself also want to tidy up these days lack of,, Thank you very much during the support of some readers, very happy to share these with you, and then to start a new life,, but our study will continue, our passion will not fade, our dream Our youth Forever ~ ~

All rights reserved, reprint please specify reprint address: http://www.cnblogs.com/lihuidashen/p/4257007.html

10 days to learn the Linux kernel Day---Summary (kconfig and Makefile & not Say Goodbye)