diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/ABI/testing/debugfs-kmemtrace | 71 | ||||
| -rw-r--r-- | Documentation/DocBook/kgdb.tmpl | 108 | ||||
| -rw-r--r-- | Documentation/DocBook/stylesheet.xsl | 1 | ||||
| -rw-r--r-- | Documentation/coccinelle.txt | 258 | ||||
| -rw-r--r-- | Documentation/hwmon/pkgtemp | 36 | ||||
| -rw-r--r-- | Documentation/kbuild/kbuild.txt | 34 | ||||
| -rw-r--r-- | Documentation/kbuild/kconfig.txt | 2 | ||||
| -rw-r--r-- | Documentation/kbuild/makefiles.txt | 127 | ||||
| -rw-r--r-- | Documentation/kernel-parameters.txt | 22 | ||||
| -rw-r--r-- | Documentation/trace/ftrace-design.txt | 153 | ||||
| -rw-r--r-- | Documentation/trace/kmemtrace.txt | 126 | ||||
| -rw-r--r-- | Documentation/trace/kprobetrace.txt | 2 | ||||
| -rw-r--r-- | Documentation/vm/page-types.c | 2 |
13 files changed, 664 insertions, 278 deletions
diff --git a/Documentation/ABI/testing/debugfs-kmemtrace b/Documentation/ABI/testing/debugfs-kmemtrace deleted file mode 100644 index 5e6a92a..0000000 --- a/Documentation/ABI/testing/debugfs-kmemtrace +++ /dev/null @@ -1,71 +0,0 @@ -What: /sys/kernel/debug/kmemtrace/ -Date: July 2008 -Contact: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> -Description: - -In kmemtrace-enabled kernels, the following files are created: - -/sys/kernel/debug/kmemtrace/ - cpu<n> (0400) Per-CPU tracing data, see below. (binary) - total_overruns (0400) Total number of bytes which were dropped from - cpu<n> files because of full buffer condition, - non-binary. (text) - abi_version (0400) Kernel's kmemtrace ABI version. (text) - -Each per-CPU file should be read according to the relay interface. That is, -the reader should set affinity to that specific CPU and, as currently done by -the userspace application (though there are other methods), use poll() with -an infinite timeout before every read(). Otherwise, erroneous data may be -read. The binary data has the following _core_ format: - - Event ID (1 byte) Unsigned integer, one of: - 0 - represents an allocation (KMEMTRACE_EVENT_ALLOC) - 1 - represents a freeing of previously allocated memory - (KMEMTRACE_EVENT_FREE) - Type ID (1 byte) Unsigned integer, one of: - 0 - this is a kmalloc() / kfree() - 1 - this is a kmem_cache_alloc() / kmem_cache_free() - 2 - this is a __get_free_pages() et al. - Event size (2 bytes) Unsigned integer representing the - size of this event. Used to extend - kmemtrace. Discard the bytes you - don't know about. - Sequence number (4 bytes) Signed integer used to reorder data - logged on SMP machines. Wraparound - must be taken into account, although - it is unlikely. - Caller address (8 bytes) Return address to the caller. - Pointer to mem (8 bytes) Pointer to target memory area. Can be - NULL, but not all such calls might be - recorded. - -In case of KMEMTRACE_EVENT_ALLOC events, the next fields follow: - - Requested bytes (8 bytes) Total number of requested bytes, - unsigned, must not be zero. - Allocated bytes (8 bytes) Total number of actually allocated - bytes, unsigned, must not be lower - than requested bytes. - Requested flags (4 bytes) GFP flags supplied by the caller. - Target CPU (4 bytes) Signed integer, valid for event id 1. - If equal to -1, target CPU is the same - as origin CPU, but the reverse might - not be true. - -The data is made available in the same endianness the machine has. - -Other event ids and type ids may be defined and added. Other fields may be -added by increasing event size, but see below for details. -Every modification to the ABI, including new id definitions, are followed -by bumping the ABI version by one. - -Adding new data to the packet (features) is done at the end of the mandatory -data: - Feature size (2 byte) - Feature ID (1 byte) - Feature data (Feature size - 3 bytes) - - -Users: - kmemtrace-user - git://repo.or.cz/kmemtrace-user.git - diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl index 55f12ac..490d862 100644 --- a/Documentation/DocBook/kgdb.tmpl +++ b/Documentation/DocBook/kgdb.tmpl @@ -199,10 +199,33 @@ may be configured as a kernel built-in or a kernel loadable module. You can only make use of <constant>kgdbwait</constant> and early debugging if you build kgdboc into the kernel as a built-in. + <para>Optionally you can elect to activate kms (Kernel Mode + Setting) integration. When you use kms with kgdboc and you have a + video driver that has atomic mode setting hooks, it is possible to + enter the debugger on the graphics console. When the kernel + execution is resumed, the previous graphics mode will be restored. + This integration can serve as a useful tool to aid in diagnosing + crashes or doing analysis of memory with kdb while allowing the + full graphics console applications to run. + </para> </para> <sect2 id="kgdbocArgs"> <title>kgdboc arguments</title> - <para>Usage: <constant>kgdboc=[kbd][[,]serial_device][,baud]</constant></para> + <para>Usage: <constant>kgdboc=[kms][[,]kbd][[,]serial_device][,baud]</constant></para> + <para>The order listed above must be observed if you use any of the + optional configurations together. + </para> + <para>Abbreviations: + <itemizedlist> + <listitem><para>kms = Kernel Mode Setting</para></listitem> + <listitem><para>kbd = Keyboard</para></listitem> + </itemizedlist> + </para> + <para>You can configure kgdboc to use the keyboard, and or a serial + device depending on if you are using kdb and or kgdb, in one of the + following scenarios. The order listed above must be observed if + you use any of the optional configurations together. Using kms + + only gdb is generally not a useful combination.</para> <sect3 id="kgdbocArgs1"> <title>Using loadable module or built-in</title> <para> @@ -212,7 +235,7 @@ <listitem> <para>As a kernel loadable module:</para> <para>Use the command: <constant>modprobe kgdboc kgdboc=<tty-device>,[baud]</constant></para> - <para>Here are two examples of how you might formate the kgdboc + <para>Here are two examples of how you might format the kgdboc string. The first is for an x86 target using the first serial port. The second example is for the ARM Versatile AB using the second serial port. @@ -240,6 +263,9 @@ </sect3> <sect3 id="kgdbocArgs3"> <title>More examples</title> + <para>You can configure kgdboc to use the keyboard, and or a serial + device depending on if you are using kdb and or kgdb, in one of the + following scenarios.</para> <para>You can configure kgdboc to use the keyboard, and or a serial device depending on if you are using kdb and or kgdb, in one of the following scenarios. @@ -255,6 +281,12 @@ <listitem><para>kdb with a keyboard</para> <para><constant>kgdboc=kbd</constant></para> </listitem> + <listitem><para>kdb with kernel mode setting</para> + <para><constant>kgdboc=kms,kbd</constant></para> + </listitem> + <listitem><para>kdb with kernel mode setting and kgdb over a serial port</para> + <para><constant>kgdboc=kms,kbd,ttyS0,115200</constant></para> + </listitem> </orderedlist> </para> </sect3> @@ -637,6 +669,8 @@ Task Addr Pid Parent [*] cpu State Thread Command <listitem><para>The logic to perform safe memory reads and writes to memory while using the debugger</para></listitem> <listitem><para>A full implementation for software breakpoints unless overridden by the arch</para></listitem> <listitem><para>The API to invoke either the kdb or kgdb frontend to the debug core.</para></listitem> + <listitem><para>The structures and callback API for atomic kernel mode setting.</para> + <para>NOTE: kgdboc is where the kms callbacks are invoked.</para></listitem> </itemizedlist> </para> </listitem> @@ -747,6 +781,8 @@ Task Addr Pid Parent [*] cpu State Thread Command </sect1> <sect1 id="kgdbocDesign"> <title>kgdboc internals</title> + <sect2> + <title>kgdboc and uarts</title> <para> The kgdboc driver is actually a very thin driver that relies on the underlying low level to the hardware driver having "polling hooks" @@ -754,11 +790,8 @@ Task Addr Pid Parent [*] cpu State Thread Command implementation of kgdboc it the serial_core was changed to expose a low level UART hook for doing polled mode reading and writing of a single character while in an atomic context. When kgdb makes an I/O - request to the debugger, kgdboc invokes a call back in the serial - core which in turn uses the call back in the UART driver. It is - certainly possible to extend kgdboc to work with non-UART based - consoles in the future. - </para> + request to the debugger, kgdboc invokes a callback in the serial + core which in turn uses the callback in the UART driver.</para> <para> When using kgdboc with a UART, the UART driver must implement two callbacks in the <constant>struct uart_ops</constant>. Example from drivers/8250.c:<programlisting> #ifdef CONFIG_CONSOLE_POLL @@ -772,9 +805,68 @@ Task Addr Pid Parent [*] cpu State Thread Command that they can be called from an atomic context and have to restore the state of the UART chip on return such that the system can return to normal when the debugger detaches. You need to be very careful - with any kind of lock you consider, because failing here is most + with any kind of lock you consider, because failing here is most likely going to mean pressing the reset button. </para> + </sect2> + <sect2 id="kgdbocKbd"> + <title>kgdboc and keyboards</title> + <para>The kgdboc driver contains logic to configure communications + with an attached keyboard. The keyboard infrastructure is only + compiled into the kernel when CONFIG_KDB_KEYBOARD=y is set in the + kernel configuration.</para> + <para>The core polled keyboard driver driver for PS/2 type keyboards + is in drivers/char/kdb_keyboard.c. This driver is hooked into the + debug core when kgdboc populates the callback in the array + called <constant>kdb_poll_funcs[]</constant>. The + kdb_get_kbd_char() is the top-level function which polls hardware + for single character input. + </para> + </sect2> + <sect2 id="kgdbocKms"> + <title>kgdboc and kms</title> + <para>The kgdboc driver contains logic to request the graphics + display to switch to a text context when you are using + "kgdboc=kms,kbd", provided that you have a video driver which has a + frame buffer console and atomic kernel mode setting support.</para> + <para> + Every time the kernel + debugger is entered it calls kgdboc_pre_exp_handler() which in turn + calls con_debug_enter() in the virtual console layer. On resuming kernel + execution, the kernel debugger calls kgdboc_post_exp_handler() which + in turn calls con_debug_leave().</para> + <para>Any video driver that wants to be compatible with the kernel + debugger and the atomic kms callbacks must implement the + mode_set_base_atomic, fb_debug_enter and fb_debug_leave operations. + For the fb_debug_enter and fb_debug_leave the option exists to use + the generic drm fb helper functions or implement something custom for + the hardware. The following example shows the initialization of the + .mode_set_base_atomic operation in + drivers/gpu/drm/i915/intel_display.c: + <informalexample> + <programlisting> +static const struct drm_crtc_helper_funcs intel_helper_funcs = { +[...] + .mode_set_base_atomic = intel_pipe_set_base_atomic, +[...] +}; + </programlisting> + </informalexample> + </para> + <para>Here is an example of how the i915 driver initializes the fb_debug_enter and fb_debug_leave functions to use the generic drm helpers in + drivers/gpu/drm/i915/intel_fb.c: + <informalexample> + <programlisting> +static struct fb_ops intelfb_ops = { +[...] + .fb_debug_enter = drm_fb_helper_debug_enter, + .fb_debug_leave = drm_fb_helper_debug_leave, +[...] +}; + </programlisting> + </informalexample> + </para> + </sect2> </sect1> </chapter> <chapter id="credits"> diff --git a/Documentation/DocBook/stylesheet.xsl b/Documentation/DocBook/stylesheet.xsl index 254c1d5..85b2527 100644 --- a/Documentation/DocBook/stylesheet.xsl +++ b/Documentation/DocBook/stylesheet.xsl @@ -6,4 +6,5 @@ <param name="callout.graphics">0</param> <!-- <param name="paper.type">A4</param> --> <param name="generate.section.toc.level">2</param> +<param name="use.id.as.filename">1</param> </stylesheet> diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt new file mode 100644 index 0000000..cd2b028 --- /dev/null +++ b/Documentation/coccinelle.txt @@ -0,0 +1,258 @@ +Copyright 2010 Nicolas Palix <npalix@diku.dk> +Copyright 2010 Julia Lawall <julia@diku.dk> +Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr> + + + Getting Coccinelle +~~~~~~~~~~~~~~~~~~~~ + +The semantic patches included in the kernel use the 'virtual rule' +feature which was introduced in Coccinelle version 0.1.11. + +Coccinelle (>=0.2.0) is available through the package manager +of many distributions, e.g. : + + - Debian (>=squeeze) + - Fedora (>=13) + - Ubuntu (>=10.04 Lucid Lynx) + - OpenSUSE + - Arch Linux + - NetBSD + - FreeBSD + + +You can get the latest version released from the Coccinelle homepage at +http://coccinelle.lip6.fr/ + +Once you have it, run the following command: + + ./configure + make + +as a regular user, and install it with + + sudo make install + + + Using Coccinelle on the Linux kernel +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A Coccinelle-specific target is defined in the top level +Makefile. This target is named 'coccicheck' and calls the 'coccicheck' +front-end in the 'scripts' directory. + +Four modes are defined: report, patch, context, and org. The mode to +use is specified by setting the MODE variable with 'MODE=<mode>'. + +'report' generates a list in the following format: + file:line:column-column: message + +'patch' proposes a fix, when possible. + +'context' highlights lines of interest and their context in a +diff-like style.Lines of interest are indicated with '-'. + +'org' generates a report in the Org mode format of Emacs. + +Note that not all semantic patches implement all modes. + +To make a report for every semantic patch, run the following command: + + make coccicheck MODE=report + +NB: The 'report' mode is the default one. + +To produce patches, run: + + make coccicheck MODE=patch + + +The coccicheck target applies every semantic patch available in the +subdirectories of 'scripts/coccinelle' to the entire Linux kernel. + +For each semantic patch, a changelog message is proposed. It gives a +description of the problem being checked by the semantic patch, and +includes a reference to Coccinelle. + +As any static code analyzer, Coccinelle produces false +positives. Thus, reports must be carefully checked, and patches +reviewed. + + + Using Coccinelle with a single semantic patch +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The optional make variable COCCI can be used to check a single +semantic patch. In that case, the variable must be initialized with +the name of the semantic patch to apply. + +For instance: + + make coccicheck COCCI=<my_SP.cocci> MODE=patch +or + make coccicheck COCCI=<my_SP.cocci> MODE=report + + + Proposing new semantic patches +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New semantic patches can be proposed and submitted by kernel +developers. For sake of clarity, they should be organized in the +subdirectories of 'scripts/coccinelle/'. + + + Detailed description of the 'report' mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +'report' generates a list in the following format: + file:line:column-column: message + +Example: + +Running + + make coccicheck MODE=report COCCI=scripts/coccinelle/err_cast.cocci + +will execute the following part of the SmPL script. + +<smpl> +@r depends on !context && !patch && (org || report)@ +expression x; +position p; +@@ + + ERR_PTR@p(PTR_ERR(x)) + +@script:python depends on report@ +p << r.p; +x << r.x; +@@ + +msg="ERR_CAST can be used with %s" % (x) +coccilib.report.print_report(p[0], msg) +</smpl> + +This SmPL excerpt generates entries on the standard output, as +illustrated below: + +/home/user/linux/crypto/ctr.c:188:9-16: ERR_CAST can be used with alg +/home/user/linux/crypto/authenc.c:619:9-16: ERR_CAST can be used with auth +/home/user/linux/crypto/xts.c:227:9-16: ERR_CAST can be used with alg + + + Detailed description of the 'patch' mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When the 'patch' mode is available, it proposes a fix for each problem +identified. + +Example: + +Running + make coccicheck MODE=patch COCCI=scripts/coccinelle/err_cast.cocci + +will execute the following part of the SmPL script. + +<smpl> +@ depends on !context && patch && !org && !report @ +expression x; +@@ + +- ERR_PTR(PTR_ERR(x)) ++ ERR_CAST(x) +</smpl> + +This SmPL excerpt generates patch hunks on the standard output, as +illustrated below: + +diff -u -p a/crypto/ctr.c b/crypto/ctr.c +--- a/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200 ++++ b/crypto/ctr.c 2010-06-03 23:44:49.000000000 +0200 +@@ -185,7 +185,7 @@ static struct crypto_instance *crypto_ct + alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER, + CRYPTO_ALG_TYPE_MASK); + if (IS_ERR(alg)) +- return ERR_PTR(PTR_ERR(alg)); ++ return ERR_CAST(alg); + + /* Block size must be >= 4 bytes. */ + err = -EINVAL; + + Detailed description of the 'context' mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +'context' highlights lines of interest and their context +in a diff-like style. + +NOTE: The diff-like output generated is NOT an applicable patch. The + intent of the 'context' mode is to highlight the important lines + (annotated with minus, '-') and gives some surrounding context + lines around. This output can be used with the diff mode of + Emacs to review the code. + +Example: + +Running + make coccicheck MODE=context COCCI=scripts/coccinelle/err_cast.cocci + +will execute the following part of the SmPL script. + +<smpl> +@ depends on context && !patch && !org && !report@ +expression x; +@@ + +* ERR_PTR(PTR_ERR(x)) +</smpl> + +This SmPL excerpt generates diff hunks on the standard output, as +illustrated below: + +diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing +--- /home/user/linux/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200 ++++ /tmp/nothing +@@ -185,7 +185,6 @@ static struct crypto_instance *crypto_ct + alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER, + CRYPTO_ALG_TYPE_MASK); + if (IS_ERR(alg)) +- return ERR_PTR(PTR_ERR(alg)); + + /* Block size must be >= 4 bytes. */ + err = -EINVAL; + + Detailed description of the 'org' mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +'org' generates a report in the Org mode format of Emacs. + +Example: + +Running + make coccicheck MODE=org COCCI=scripts/coccinelle/err_cast.cocci + +will execute the following part of the SmPL script. + +<smpl> +@r depends on !context && !patch && (org || report)@ +expression x; +position p; +@@ + + ERR_PTR@p(PTR_ERR(x)) + +@script:python depends on org@ +p << r.p; +x << r.x; +@@ + +msg="ERR_CAST can be used with %s" % (x) +msg_safe=msg.replace("[","@(").replace("]",")") +coccilib.org.print_todo(p[0], msg_safe) +</smpl> + +This SmPL excerpt generates Org entries on the standard output, as +illustrated below: + +* TODO [[view:/home/user/linux/crypto/ctr.c::face=ovl-face1::linb=188::colb=9::cole=16][ERR_CAST can be used with alg]] +* TODO [[view:/home/user/linux/crypto/authenc.c::face=ovl-face1::linb=619::colb=9::cole=16][ERR_CAST can be used with auth]] +* TODO [[view:/home/user/linux/crypto/xts.c::face=ovl-face1::linb=227::colb=9::cole=16][ERR_CAST can be used with alg]] diff --git a/Documentation/hwmon/pkgtemp b/Documentation/hwmon/pkgtemp new file mode 100644 index 0000000..c8e1fb0 --- /dev/null +++ b/Documentation/hwmon/pkgtemp @@ -0,0 +1,36 @@ +Kernel driver pkgtemp +====================== + +Supported chips: + * Intel family + Prefix: 'pkgtemp' + CPUID: + Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual + Volume 3A: System Programming Guide + +Author: Fenghua Yu + +Description +----------- + +This driver permits reading package level temperature sensor embedded inside +Intel CPU package. The sensors can be in core, uncore, memory controller, or +other components in a package. The feature is first implemented in Intel Sandy +Bridge platform. + +Temperature is measured in degrees Celsius and measurement resolution is +1 degree C. Valid temperatures are from 0 to TjMax degrees C, because the actual +value of temperature register is in fact a delta from TjMax. + +Temperature known as TjMax is the maximum junction temperature of package. +We get this from MSR_IA32_TEMPERATURE_TARGET. If the MSR is not accessible, +we define TjMax as 100 degrees Celsius. At this temperature, protection +mechanism will perform actions to forcibly cool down the package. Alarm +may be raised, if the temperature grows enough (more than TjMax) to trigger +the Out-Of-Spec bit. Following table summarizes the exported sysfs files: + +temp1_input - Package temperature (in millidegrees Celsius). +temp1_max - All cooling devices should be turned on. +temp1_crit - Maximum junction temperature (in millidegrees Celsius). +temp1_crit_alarm - Set when Out-of-spec bit is set, never clears. + Correct CPU operation is no longer guaranteed. diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index 634c625..1e5165a 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt @@ -22,11 +22,33 @@ building C files and assembler files. KAFLAGS -------------------------------------------------- -Additional options to the assembler. +Additional options to the assembler (for built-in and modules). + +AFLAGS_MODULE +-------------------------------------------------- +Addtional module specific options to use for $(AS). + +AFLAGS_KERNEL +-------------------------------------------------- +Addtional options for $(AS) when used for assembler +code for code that is compiled as built-in. KCFLAGS -------------------------------------------------- -Additional options to the C compiler. +Additional options to the C compiler (for built-in and modules). + +CFLAGS_KERNEL +-------------------------------------------------- +Addtional options for $(CC) when used to compile +code that is compiled as built-in. + +CFLAGS_MODULE +-------------------------------------------------- +Addtional module specific options to use for $(CC). + +LDFLAGS_MODULE +-------------------------------------------------- +Additional options used for $(LD) when linking modules. KBUILD_VERBOSE -------------------------------------------------- @@ -40,15 +62,15 @@ Set the directory to look for the kernel source when building external modules. The directory can be specified in several ways: 1) Use "M=..." on the command line -2) Environmnet variable KBUILD_EXTMOD -3) Environmnet variable SUBDIRS +2) Environment variable KBUILD_EXTMOD +3) Environment variable SUBDIRS The possibilities are listed in the order they take precedence. Using "M=..." will always override the others. KBUILD_OUTPUT -------------------------------------------------- Specify the output directory when building the kernel. -The output directory can also be specificed using "O=...". +The output directory can also be specified using "O=...". Setting "O=..." takes precedence over KBUILD_OUTPUT. ARCH @@ -90,7 +112,7 @@ The script will be called with the following arguments: $3 - kernel map file $4 - default install path (use root directory if blank) -The implmentation of "make install" is architecture specific +The implementation of "make install" is architecture specific and it may differ from the above. INSTALLKERNEL is provided to enable the possibility to diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt index b2cb16e..cca46b1 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt @@ -65,7 +65,7 @@ also use the environment variable KCONFIG_ALLCONFIG as a flag or a filename that contains config symbols that the user requires to be set to a specific value. If KCONFIG_ALLCONFIG is used without a filename, "make *config" checks for a file named -"all{yes/mod/no/random}.config" (corresponding to the *config command +"all{yes/mod/no/def/random}.config" (corresponding to the *config command that was used) for symbol values that are to be forced. If this file is not found, it checks for a file named "all.config" to contain forced values. diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 71c602d..c375313 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -168,7 +168,7 @@ more details, with real examples. #drivers/isdn/i4l/Makefile # Makefile for the kernel ISDN subsystem and device drivers. # Each configuration option enables a list of files. - obj-$(CONFIG_ISDN) += isdn.o + obj-$(CONFIG_ISDN_I4L) += isdn.o obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o --- 3.3 Loadable module goals - obj-m @@ -187,34 +187,35 @@ more details, with real examples. Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm' If a kernel module is built from several source files, you specify - that you want to build a module in the same way as above. - - Kbuild needs to know which the parts that you want to build your - module from, so you have to tell it by setting an - $(<module_name>-objs) variable. + that you want to build a module in the same way as above; however, + kbuild needs to know which object files you want to build your + module from, so you have to tell it by setting a $(<module_name>-y) + variable. Example: #drivers/isdn/i4l/Makefile - obj-$(CONFIG_ISDN) += isdn.o - isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o + obj-$(CONFIG_ISDN_I4L) += isdn.o + isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o In this example, the module name will be isdn.o. Kbuild will - compile the objects listed in $(isdn-objs) and then run + compile the objects listed in $(isdn-y) and then run "$(LD) -r" on the list of these files to generate isdn.o. - Kbuild recognises objects used for composite objects by the suffix - -objs, and the suffix -y. This allows the Makefiles to use - the value of a CONFIG_ symbol to determine if an object is part - of a composite object. + Due to kbuild recognizing $(<module_name>-y) for composite objects, + you can use the value of a CONFIG_ symbol to optionally include an + object file as part of a composite object. Example: #fs/ext2/Makefile - obj-$(CONFIG_EXT2_FS) += ext2.o - ext2-y := balloc.o bitmap.o - ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o + obj-$(CONFIG_EXT2_FS) += ext2.o + ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \ + namei.o super.o symlink.o + ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \ + xattr_trusted.o - In this example, xattr.o is only part of the composite object - ext2.o if $(CONFIG_EXT2_FS_XATTR) evaluates to 'y'. + In this example, xattr.o, xattr_user.o and xattr_trusted.o are only + part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR) + evaluates to 'y'. Note: Of course, when you are building objects into the kernel, the syntax above will also work. So, if you have CONFIG_EXT2_FS=y, @@ -244,12 +245,12 @@ more details, with real examples. may contain both a built-in.o and a lib.a file. Example: - #arch/i386/lib/Makefile - lib-y := checksum.o delay.o + #arch/x86/lib/Makefile + lib-y := delay.o - This will create a library lib.a based on checksum.o and delay.o. - For kbuild to actually recognize that there is a lib.a being built, - the directory shall be listed in libs-y. + This will create a library lib.a based on delay.o. For kbuild to + actually recognize that there is a lib.a being built, the directory + shall be listed in libs-y. See also "6.3 List directories to visit when descending". Use of lib-y is normally restricted to lib/ and arch/*/lib. @@ -284,43 +285,40 @@ more details, with real examples. --- 3.7 Compilation flags ccflags-y, asflags-y and ldflags-y - The three flags listed above applies only to the kbuild makefile - where they are assigned. They are used for all the normal - cc, as and ld invocation happenign during a recursive build. + These three flags apply only to the kbuild makefile in which they + are assigned. They are used for all the normal cc, as and ld + invocations happening during a recursive build. Note: Flags with the same behaviour were previously named: EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. - They are yet supported but their use are deprecated. + They are still supported but their usage is deprecated. - ccflags-y specifies options for compiling C files with $(CC). + ccflags-y specifies options for compiling with $(CC). Example: - # drivers/sound/emu10k1/Makefile - ccflags-y += -I$(obj) - ccflags-$(DEBUG) += -DEMU10K1_DEBUG - + # drivers/acpi/Makefile + ccflags-y := -Os + ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT This variable is necessary because the top Makefile owns the variable $(KBUILD_CFLAGS) and uses it for compilation flags for the entire tree. - asflags-y is a similar string for per-directory options - when compiling assembly language source. + asflags-y specifies options for assembling with $(AS). Example: - #arch/x86_64/kernel/Makefile - asflags-y := -traditional - + #arch/sparc/kernel/Makefile + asflags-y := -ansi - ldflags-y is a string for per-directory options to $(LD). + ldflags-y specifies options for linking with $(LD). Example: - #arch/m68k/fpsp040/Makefile - ldflags-y := -x + #arch/cris/boot/compressed/Makefile + ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds subdir-ccflags-y, subdir-asflags-y - The two flags listed above are similar to ccflags-y and as-falgs-y. - The difference is that the subdir- variants has effect for the kbuild - file where tey are present and all subdirectories. + The two flags listed above are similar to ccflags-y and asflags-y. + The difference is that the subdir- variants have effect for the kbuild + file where they are present and all subdirectories. Options specified using subdir-* are added to the commandline before the options specified using the non-subdir variants. @@ -340,18 +338,18 @@ more details, with real examples. CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF CFLAGS_gdth.o = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \ -DGDTH_STATISTICS - CFLAGS_seagate.o = -DARBITRATE -DPARITY -DSEAGATE_USE_ASM - These three lines specify compilation flags for aha152x.o, - gdth.o, and seagate.o + These two lines specify compilation flags for aha152x.o and gdth.o. $(AFLAGS_$@) is a similar feature for source files in assembly languages. Example: # arch/arm/kernel/Makefile - AFLAGS_head-armv.o := -DTEXTADDR=$(TEXTADDR) -traditional - AFLAGS_head-armo.o := -DTEXTADDR=$(TEXTADDR) -traditional + AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET) + AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312 + AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt + --- 3.9 Dependency tracking @@ -923,16 +921,33 @@ When kbuild executes, the following steps are followed (roughly): The first example utilises the trick that a config option expands to 'y' when selected. - CFLAGS_KERNEL $(CC) options specific for built-in + KBUILD_AFLAGS_KERNEL $(AS) options specific for built-in + + $(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile + resident kernel code. + + KBUILD_AFLAGS_MODULE Options for $(AS) when building modules + + $(KBUILD_AFLAGS_MODULE) is used to add arch specific options that + are used for $(AS). + From commandline AFLAGS_MODULE shall be used (see kbuild.txt). - $(CFLAGS_KERNEL) contains extra C compiler flags used to compile + KBUILD_CFLAGS_KERNEL $(CC) options specific for built-in + + $(KBUILD_CFLAGS_KERNEL) contains extra C compiler flags used to compile resident kernel code. - CFLAGS_MODULE $(CC) options specific for modules + KBUILD_CFLAGS_MODULE Options for $(CC) when building modules + + $(KBUILD_CFLAGS_MODULE) is used to add arch specific options that + are used for $(CC). + From commandline CFLAGS_MODULE shall be used (see kbuild.txt). - $(CFLAGS_MODULE) contains extra C compiler flags used to compile code - for loadable kernel modules. + KBUILD_LDFLAGS_MODULE Options for $(LD) when linking modules + $(KBUILD_LDFLAGS_MODULE) is used to add arch specific options + used when linking modules. This is often a linker script. + From commandline LDFLAGS_MODULE shall be used (see kbuild.txt). --- 6.2 Add prerequisites to archprepare: @@ -1176,14 +1191,14 @@ When kbuild executes, the following steps are followed (roughly): === 7 Kbuild syntax for exported headers The kernel include a set of headers that is exported to userspace. -Many headers can be exported as-is but other headers requires a +Many headers can be exported as-is but other headers require a minimal pre-processing before they are ready for user-space. The pre-processing does: - drop kernel specific annotations - drop include of compiler.h -- drop all sections that is kernel internat (guarded by ifdef __KERNEL__) +- drop all sections that are kernel internal (guarded by ifdef __KERNEL__) -Each relevant directory contain a file name "Kbuild" which specify the +Each relevant directory contains a file name "Kbuild" which specifies the headers to be exported. See subsequent chapter for the syntax of the Kbuild file. diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d9239d5..f20c7ab 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -116,6 +116,7 @@ parameter is applicable: More X86-64 boot options can be found in Documentation/x86/x86_64/boot-options.txt . X86 Either 32bit or 64bit x86 (same as X86-32+X86-64) + XEN Xen support is enabled In addition, the following text indicates that the option: @@ -1144,9 +1145,12 @@ and is between 256 and 4096 characters. It is defined in the file kgdboc= [KGDB,HW] kgdb over consoles. Requires a tty driver that supports console polling, or a supported polling keyboard driver (non-usb). - Serial only format: <serial_device>[,baud] - keyboard only format: kbd - keyboard and serial format: kbd,<serial_device>[,baud] + Serial only format: <serial_device>[,baud] + keyboard only format: kbd + keyboard and serial format: kbd,<serial_device>[,baud] + Optional Kernel mode setting: + kms, kbd format: kms,kbd + kms, kbd and serial format: kms,kbd,<ser_dev>[,baud] kgdbwait [KGDB] Stop kernel execution and enter the kernel debugger at the earliest opportunity. @@ -1812,6 +1816,8 @@ and is between 256 and 4096 characters. It is defined in the file nousb [USB] Disable the USB subsystem + nowatchdog [KNL] Disable the lockup detector. + nowb [ARM] nox2apic [X86-64,APIC] Do not enable x2APIC mode. @@ -2886,6 +2892,16 @@ and is between 256 and 4096 characters. It is defined in the file xd= [HW,XT] Original XT pre-IDE (RLL encoded) disks. xd_geo= See header of drivers/block/xd.c. + xen_emul_unplug= [HW,X86,XEN] + Unplug Xen emulated devices + Format: [unplug0,][unplug1] + ide-disks -- unplug primary master IDE devices + aux-ide-disks -- unplug non-primary-master IDE devices + nics -- unplug network devices + all -- unplug all emulated devices (NICs and IDE disks) + ignore -- continue loading the Xen platform PCI driver even + if the version check failed + xirc2ps_cs= [NET,PCMCIA] Format: <irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]] diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt index f1f81af..dc52bd4 100644 --- a/Documentation/trace/ftrace-design.txt +++ b/Documentation/trace/ftrace-design.txt @@ -13,6 +13,9 @@ Note that this focuses on architecture implementation details only. If you want more explanation of a feature in terms of common code, review the common ftrace.txt file. +Ideally, everyone who wishes to retain performance while supporting tracing in +their kernel should make it all the way to dynamic ftrace support. + Prerequisites ------------- @@ -215,7 +218,7 @@ An arch may pass in a unique value (frame pointer) to both the entering and exiting of a function. On exit, the value is compared and if it does not match, then it will panic the kernel. This is largely a sanity check for bad code generation with gcc. If gcc for your port sanely updates the frame -pointer under different opitmization levels, then ignore this option. +pointer under different optimization levels, then ignore this option. However, adding support for it isn't terribly difficult. In your assembly code that calls prepare_ftrace_return(), pass the frame pointer as the 3rd argument. @@ -234,7 +237,7 @@ If you can't trace NMI functions, then skip this option. HAVE_SYSCALL_TRACEPOINTS ---------------------- +------------------------ You need very few things to get the syscalls tracing in an arch. @@ -250,12 +253,152 @@ You need very few things to get the syscalls tracing in an arch. HAVE_FTRACE_MCOUNT_RECORD ------------------------- -See scripts/recordmcount.pl for more info. +See scripts/recordmcount.pl for more info. Just fill in the arch-specific +details for how to locate the addresses of mcount call sites via objdump. +This option doesn't make much sense without also implementing dynamic ftrace. + +HAVE_DYNAMIC_FTRACE +------------------- + +You will first need HAVE_FTRACE_MCOUNT_RECORD and HAVE_FUNCTION_TRACER, so +scroll your reader back up if you got over eager. + +Once those are out of the way, you will need to implement: + - asm/ftrace.h: + - MCOUNT_ADDR + - ftrace_call_adjust() + - struct dyn_arch_ftrace{} + - asm code: + - mcount() (new stub) + - ftrace_caller() + - ftrace_call() + - ftrace_stub() + - C code: + - ftrace_dyn_arch_init() + - ftrace_make_nop() + - ftrace_make_call() + - ftrace_update_ftrace_func() + +First you will need to fill out some arch details in your asm/ftrace.h. + +Define MCOUNT_ADDR as the address of your mcount symbol similar to: + #define MCOUNT_ADDR ((unsigned long)mcount) +Since no one else will have a decl for that function, you will need to: + extern void mcount(void); + +You will also need the helper function ftrace_call_adjust(). Most people +will be able to stub it out like so: + static inline unsigned long ftrace_call_adjust(unsigned long addr) + { + return addr; + } <details to be filled> +Lastly you will need the custom dyn_arch_ftrace structure. If you need +some extra state when runtime patching arbitrary call sites, this is the +place. For now though, create an empty struct: + struct dyn_arch_ftrace { + /* No extra data needed */ + }; + +With the header out of the way, we can fill out the assembly code. While we +did already create a mcount() function earlier, dynamic ftrace only wants a +stub function. This is because the mcount() will only be used during boot +and then all references to it will be patched out never to return. Instead, +the guts of the old mcount() will be used to create a new ftrace_caller() +function. Because the two are hard to merge, it will most likely be a lot +easier to have two separate definitions split up by #ifdefs. Same goes for +the ftrace_stub() as that will now be inlined in ftrace_caller(). + +Before we get confused anymore, let's check out some pseudo code so you can +implement your own stuff in assembly: -HAVE_DYNAMIC_FTRACE ---------------------- +void mcount(void) +{ + return; +} + +void ftrace_caller(void) +{ + /* implement HAVE_FUNCTION_TRACE_MCOUNT_TEST if you desire */ + + /* save all state needed by the ABI (see paragraph above) */ + + unsigned long frompc = ...; + unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; + +ftrace_call: + ftrace_stub(frompc, selfpc); + + /* restore all state needed by the ABI */ + +ftrace_stub: + return; +} + +This might look a little odd at first, but keep in mind that we will be runtime +patching multiple things. First, only functions that we actually want to trace +will be patched to call ftrace_caller(). Second, since we only have one tracer +active at a time, we will patch the ftrace_caller() function itself to call the +specific tracer in question. That is the point of the ftrace_call label. + +With that in mind, let's move on to the C code that will actually be doing the +runtime patching. You'll need a little knowledge of your arch's opcodes in +order to make it through the next section. + +Every arch has an init callback function. If you need to do something early on +to initialize some state, this is the time to do that. Otherwise, this simple +function below should be sufficient for most people: + +int __init ftrace_dyn_arch_init(void *data) +{ + /* return value is done indirectly via data */ + *(unsigned long *)data = 0; + + return 0; +} + +There are two functions that are used to do runtime patching of arbitrary +functions. The first is used to turn the mcount call site into a nop (which +is what helps us retain runtime performance when not tracing). The second is +used to turn the mcount call site into a call to an arbitrary location (but +typically that is ftracer_caller()). See the general function definition in +linux/ftrace.h for the functions: + ftrace_make_nop() + ftrace_make_call() +The rec->ip value is the address of the mcount call site that was collected +by the scripts/recordmcount.pl during build time. + +The last function is used to do runtime patching of the active tracer. This +will be modifying the assembly code at the location of the ftrace_call symbol +inside of the ftrace_caller() function. So you should have sufficient padding +at that location to support the new function calls you'll be inserting. Some +people will be using a "call" type instruction while others will be using a +"branch" type instruction. Specifically, the function is: + ftrace_update_ftrace_func() + + +HAVE_DYNAMIC_FTRACE + HAVE_FUNCTION_GRAPH_TRACER +------------------------------------------------ + +The function grapher needs a few tweaks in order to work with dynamic ftrace. +Basically, you will need to: + - update: + - ftrace_caller() + - ftrace_graph_call() + - ftrace_graph_caller() + - implement: + - ftrace_enable_ftrace_graph_caller() + - ftrace_disable_ftrace_graph_caller() <details to be filled> +Quick notes: + - add a nop stub after the ftrace_call location named ftrace_graph_call; + stub needs to be large enough to support a call to ftrace_graph_caller() + - update ftrace_graph_caller() to work with being called by the new + ftrace_caller() since some semantics may have changed + - ftrace_enable_ftrace_graph_caller() will runtime patch the + ftrace_graph_call location with a call to ftrace_graph_caller() + - ftrace_disable_ftrace_graph_caller() will runtime patch the + ftrace_graph_call location with nops diff --git a/Documentation/trace/kmemtrace.txt b/Documentation/trace/kmemtrace.txt deleted file mode 100644 index 6308735..0000000 --- a/Documentation/trace/kmemtrace.txt +++ /dev/null @@ -1,126 +0,0 @@ - kmemtrace - Kernel Memory Tracer - - by Eduard - Gabriel Munteanu - <eduard.munteanu@linux360.ro> - -I. Introduction -=============== - -kmemtrace helps kernel developers figure out two things: -1) how different allocators (SLAB, SLUB etc.) perform -2) how kernel code allocates memory and how much - -To do this, we trace every allocation and export information to the userspace -through the relay interface. We export things such as the number of requested -bytes, the number of bytes actually allocated (i.e. including internal -fragmentation), whether this is a slab allocation or a plain kmalloc() and so -on. - -The actual analysis is performed by a userspace tool (see section III for -details on where to get it from). It logs the data exported by the kernel, -processes it and (as of writing this) can provide the following information: -- the total amount of memory allocated and fragmentation per call-site -- the amount of memory allocated and fragmentation per allocation -- total memory allocated and fragmentation in the collected dataset -- number of cross-CPU allocation and frees (makes sense in NUMA environments) - -Moreover, it can potentially find inconsistent and erroneous behavior in -kernel code, such as using slab free functions on kmalloc'ed memory or -allocating less memory than requested (but not truly failed allocations). - -kmemtrace also makes provisions for tracing on some arch and analysing the -data on another. - -II. Design and goals -==================== - -kmemtrace was designed to handle rather large amounts of data. Thus, it uses -the relay interface to export whatever is logged to userspace, which then -stores it. Analysis and reporting is done asynchronously, that is, after the -data is collected and stored. By design, it allows one to log and analyse -on different machines and different arches. - -As of writing this, the ABI is not considered stable, though it might not -change much. However, no guarantees are made about compatibility yet. When -deemed stable, the ABI should still allow easy extension while maintaining -backward compatibility. This is described further in Documentation/ABI. - -Summary of design goals: - - allow logging and analysis to be done across different machines - - be fast and anticipate usage in high-load environments (*) - - be reasonably extensible - - make it possible for GNU/Linux distributions to have kmemtrace - included in their repositories - -(*) - one of the reasons Pekka Enberg's original userspace data analysis - tool's code was rewritten from Perl to C (although this is more than a - simple conversion) - - -III. Quick usage guide -====================== - -1) Get a kernel that supports kmemtrace and build it accordingly (i.e. enable -CONFIG_KMEMTRACE). - -2) Get the userspace tool and build it: -$ git clone git://repo.or.cz/kmemtrace-user.git # current repository -$ cd kmemtrace-user/ -$ ./autogen.sh -$ ./configure -$ make - -3) Boot the kmemtrace-enabled kernel if you haven't, preferably in the -'single' runlevel (so that relay buffers don't fill up easily), and run -kmemtrace: -# '$' does not mean user, but root here. -$ mount -t debugfs none /sys/kernel/debug -$ mount -t proc none /proc -$ cd path/to/kmemtrace-user/ -$ ./kmemtraced -Wait a bit, then stop it with CTRL+C. -$ cat /sys/kernel/debug/kmemtrace/total_overruns # Check if we didn't - # overrun, should - # be zero. -$ (Optionally) [Run kmemtrace_check separately on each cpu[0-9]*.out file to - check its correctness] -$ ./kmemtrace-report - -Now you should have a nice and short summary of how the allocator performs. - -IV. FAQ and known issues -======================== - -Q: 'cat /sys/kernel/debug/kmemtrace/total_overruns' is non-zero, how do I fix -this? Should I worry? -A: If it's non-zero, this affects kmemtrace's accuracy, depending on how -large the number is. You can fix it by supplying a higher -'kmemtrace.subbufs=N' kernel parameter. ---- - -Q: kmemtrace_check reports errors, how do I fix this? Should I worry? -A: This is a bug and should be reported. It can occur for a variety of -reasons: - - possible bugs in relay code - - possible misuse of relay by kmemtrace - - timestamps being collected unorderly -Or you may fix it yourself and send us a patch. ---- - -Q: kmemtrace_report shows many errors, how do I fix this? Should I worry? -A: This is a known issue and I'm working on it. These might be true errors -in kernel code, which may have inconsistent behavior (e.g. allocating memory -with kmem_cache_alloc() and freeing it with kfree()). Pekka Enberg pointed -out this behavior may work with SLAB, but may fail with other allocators. - -It may also be due to lack of tracing in some unusual allocator functions. - -We don't want bug reports regarding this issue yet. ---- - -V. See also -=========== - -Documentation/kernel-parameters.txt -Documentation/ABI/testing/debugfs-kmemtrace - diff --git a/Documentation/trace/kprobetrace.txt b/Documentation/trace/kprobetrace.txt index ec94748..5f77d94 100644 --- a/Documentation/trace/kprobetrace.txt +++ b/Documentation/trace/kprobetrace.txt @@ -42,7 +42,7 @@ Synopsis of kprobe_events +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**) NAME=FETCHARG : Set NAME as the argument name of FETCHARG. FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types - (u8/u16/u32/u64/s8/s16/s32/s64) are supported. + (u8/u16/u32/u64/s8/s16/s32/s64) and string are supported. (*) only for return probe. (**) this is useful for fetching a field of data structures. diff --git a/Documentation/vm/page-types.c b/Documentation/vm/page-types.c index 66e9358..ccd951f 100644 --- a/Documentation/vm/page-types.c +++ b/Documentation/vm/page-types.c @@ -694,7 +694,7 @@ static void usage(void) #endif " -l|--list Show page details in ranges\n" " -L|--list-each Show page details one by one\n" -" -N|--no-summary Don't show summay info\n" +" -N|--no-summary Don't show summary info\n" " -X|--hwpoison hwpoison pages\n" " -x|--unpoison unpoison pages\n" " -h|--help Show this usage message\n" |
