diff options
Diffstat (limited to 'Documentation')
82 files changed, 2065 insertions, 1381 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 8d556707bb68..e8fb24671967 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -109,6 +109,8 @@ cpu-hotplug.txt - document describing CPU hotplug support in the Linux kernel. cpu-load.txt - document describing how CPU load statistics are collected. +cpuidle/ + - info on CPU_IDLE, CPU idle state management subsystem. cpusets.txt - documents the cpusets feature; assign CPUs and Mem to a set of tasks. cputopology.txt @@ -181,8 +183,6 @@ i386/ - directory with info about Linux on Intel 32 bit architecture. ia64/ - directory with info about Linux on Intel 64 bit architecture. -ide.txt - - important info for users of ATA devices (IDE/EIDE disks and CD-ROMS). infiniband/ - directory with documents concerning Linux InfiniBand support. initrd.txt @@ -225,8 +225,6 @@ kprobes.txt - documents the kernel probes debugging feature. kref.txt - docs on adding reference counters (krefs) to kernel objects. -laptop-mode.txt - - how to conserve battery power using laptop-mode. laptops/ - directory with laptop related info and laptop driver documentation. ldm.txt @@ -273,8 +271,6 @@ netlabel/ - directory with information on the NetLabel subsystem. networking/ - directory with info on various aspects of networking with Linux. -nfsroot.txt - - short guide on setting up a diskless box with NFS root filesystem. nmi_watchdog.txt - info on NMI watchdog for SMP systems. nommu-mmap.txt @@ -301,12 +297,8 @@ pcmcia/ - info on the Linux PCMCIA driver. pi-futex.txt - documentation on lightweight PI-futexes. -pm.txt - - info on Linux power management support. pnp.txt - Linux Plug and Play documentation. -power_supply_class.txt - - Tells userspace about battery, UPS, AC or DC power supply properties power/ - directory with info on Linux PCI power management. powerpc/ @@ -327,8 +319,6 @@ robust-futexes.txt - a description of what robust futexes are. rocket.txt - info on the Comtrol RocketPort multiport serial driver. -rpc-cache.txt - - introduction to the caching mechanisms in the sunrpc layer. rt-mutex-design.txt - description of the RealTime mutex implementation design. rt-mutex.txt diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 6a0ad4715e9f..e471bc466a7e 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -8,8 +8,8 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ - procfs-guide.xml writing_usb_driver.xml \ - kernel-api.xml filesystems.xml lsm.xml usb.xml \ + procfs-guide.xml writing_usb_driver.xml networking.xml \ + kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml diff --git a/Documentation/DocBook/filesystems.tmpl b/Documentation/DocBook/filesystems.tmpl index 5eaef87e8f1b..5e87ad58c0b5 100644 --- a/Documentation/DocBook/filesystems.tmpl +++ b/Documentation/DocBook/filesystems.tmpl @@ -398,4 +398,24 @@ an example. </chapter> + <chapter id="splice"> + <title>splice API</title> + <para> + splice is a method for moving blocks of data around inside the + kernel, without continually transferring them between the kernel + and user space. + </para> +!Ffs/splice.c + </chapter> + + <chapter id="pipes"> + <title>pipes API</title> + <para> + Pipe interfaces are all for in-kernel (builtin image) use. + They are not exported for use by modules. + </para> +!Iinclude/linux/pipe_fs_i.h +!Ffs/pipe.c + </chapter> + </book> diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 059aaf20951a..dc0f30c3e571 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -204,65 +204,6 @@ X!Ilib/string.c </sect1> </chapter> - <chapter id="netcore"> - <title>Linux Networking</title> - <sect1><title>Networking Base Types</title> -!Iinclude/linux/net.h - </sect1> - <sect1><title>Socket Buffer Functions</title> -!Iinclude/linux/skbuff.h -!Iinclude/net/sock.h -!Enet/socket.c -!Enet/core/skbuff.c -!Enet/core/sock.c -!Enet/core/datagram.c -!Enet/core/stream.c - </sect1> - <sect1><title>Socket Filter</title> -!Enet/core/filter.c - </sect1> - <sect1><title>Generic Network Statistics</title> -!Iinclude/linux/gen_stats.h -!Enet/core/gen_stats.c -!Enet/core/gen_estimator.c - </sect1> - <sect1><title>SUN RPC subsystem</title> -<!-- The !D functionality is not perfect, garbage has to be protected by comments -!Dnet/sunrpc/sunrpc_syms.c ---> -!Enet/sunrpc/xdr.c -!Enet/sunrpc/svcsock.c -!Enet/sunrpc/sched.c - </sect1> - </chapter> - - <chapter id="netdev"> - <title>Network device support</title> - <sect1><title>Driver Support</title> -!Enet/core/dev.c -!Enet/ethernet/eth.c -!Enet/sched/sch_generic.c -!Iinclude/linux/etherdevice.h -!Iinclude/linux/netdevice.h - </sect1> - <sect1><title>PHY Support</title> -!Edrivers/net/phy/phy.c -!Idrivers/net/phy/phy.c -!Edrivers/net/phy/phy_device.c -!Idrivers/net/phy/phy_device.c -!Edrivers/net/phy/mdio_bus.c -!Idrivers/net/phy/mdio_bus.c - </sect1> -<!-- FIXME: Removed for now since no structured comments in source - <sect1><title>Wireless</title> -X!Enet/core/wireless.c - </sect1> ---> - <sect1><title>Synchronous PPP</title> -!Edrivers/net/wan/syncppp.c - </sect1> - </chapter> - <chapter id="modload"> <title>Module Support</title> <sect1><title>Module Loading</title> @@ -420,12 +361,14 @@ X!Edrivers/pnp/system.c <chapter id="blkdev"> <title>Block Devices</title> !Eblock/blk-core.c +!Iblock/blk-core.c !Eblock/blk-map.c !Iblock/blk-sysfs.c !Eblock/blk-settings.c !Eblock/blk-exec.c !Eblock/blk-barrier.c !Eblock/blk-tag.c +!Iblock/blk-tag.c </chapter> <chapter id="chrdev"> @@ -508,11 +451,6 @@ X!Isound/sound_firmware.c !Edrivers/serial/8250.c </chapter> - <chapter id="z85230"> - <title>Z85230 Support Library</title> -!Edrivers/net/wan/z85230.c - </chapter> - <chapter id="fbdev"> <title>Frame Buffer Library</title> @@ -712,24 +650,4 @@ X!Idrivers/video/console/fonts.c !Edrivers/i2c/i2c-core.c </chapter> - <chapter id="splice"> - <title>splice API</title> - <para> - splice is a method for moving blocks of data around inside the - kernel, without continually transferring them between the kernel - and user space. - </para> -!Ffs/splice.c - </chapter> - - <chapter id="pipes"> - <title>pipes API</title> - <para> - Pipe interfaces are all for in-kernel (builtin image) use. - They are not exported for use by modules. - </para> -!Iinclude/linux/pipe_fs_i.h -!Ffs/pipe.c - </chapter> - </book> diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl new file mode 100644 index 000000000000..97618bed4d65 --- /dev/null +++ b/Documentation/DocBook/kgdb.tmpl @@ -0,0 +1,447 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" + "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> + +<book id="kgdbOnLinux"> + <bookinfo> + <title>Using kgdb and the kgdb Internals</title> + + <authorgroup> + <author> + <firstname>Jason</firstname> + <surname>Wessel</surname> + <affiliation> + <address> + <email>jason.wessel@windriver.com</email> + </address> + </affiliation> + </author> + </authorgroup> + + <authorgroup> + <author> + <firstname>Tom</firstname> + <surname>Rini</surname> + <affiliation> + <address> + <email>trini@kernel.crashing.org</email> + </address> + </affiliation> + </author> + </authorgroup> + + <authorgroup> + <author> + <firstname>Amit S.</firstname> + <surname>Kale</surname> + <affiliation> + <address> + <email>amitkale@linsyssoft.com</email> + </address> + </affiliation> + </author> + </authorgroup> + + <copyright> + <year>2008</year> + <holder>Wind River Systems, Inc.</holder> + </copyright> + <copyright> + <year>2004-2005</year> + <holder>MontaVista Software, Inc.</holder> + </copyright> + <copyright> + <year>2004</year> + <holder>Amit S. Kale</holder> + </copyright> + + <legalnotice> + <para> + This file is licensed under the terms of the GNU General Public License + version 2. This program is licensed "as is" without any warranty of any + kind, whether express or implied. + </para> + + </legalnotice> + </bookinfo> + +<toc></toc> + <chapter id="Introduction"> + <title>Introduction</title> + <para> + kgdb is a source level debugger for linux kernel. It is used along + with gdb to debug a linux kernel. The expectation is that gdb can + be used to "break in" to the kernel to inspect memory, variables + and look through a cal stack information similar to what an + application developer would use gdb for. It is possible to place + breakpoints in kernel code and perform some limited execution + stepping. + </para> + <para> + Two machines are required for using kgdb. One of these machines is a + development machine and the other is a test machine. The kernel + to be debugged runs on the test machine. The development machine + runs an instance of gdb against the vmlinux file which contains + the symbols (not boot image such as bzImage, zImage, uImage...). + In gdb the developer specifies the connection parameters and + connects to kgdb. Depending on which kgdb I/O modules exist in + the kernel for a given architecture, it may be possible to debug + the test machine's kernel with the development machine using a + rs232 or ethernet connection. + </para> + </chapter> + <chapter id="CompilingAKernel"> + <title>Compiling a kernel</title> + <para> + To enable <symbol>CONFIG_KGDB</symbol>, look under the "Kernel debugging" + and then select "KGDB: kernel debugging with remote gdb". + </para> + <para> + Next you should choose one of more I/O drivers to interconnect debugging + host and debugged target. Early boot debugging requires a KGDB + I/O driver that supports early debugging and the driver must be + built into the kernel directly. Kgdb I/O driver configuration + takes place via kernel or module parameters, see following + chapter. + </para> + <para> + The kgdb test compile options are described in the kgdb test suite chapter. + </para> + + </chapter> + <chapter id="EnableKGDB"> + <title>Enable kgdb for debugging</title> + <para> + In order to use kgdb you must activate it by passing configuration + information to one of the kgdb I/O drivers. If you do not pass any + configuration information kgdb will not do anything at all. Kgdb + will only actively hook up to the kernel trap hooks if a kgdb I/O + driver is loaded and configured. If you unconfigure a kgdb I/O + driver, kgdb will unregister all the kernel hook points. + </para> + <para> + All drivers can be reconfigured at run time, if + <symbol>CONFIG_SYSFS</symbol> and <symbol>CONFIG_MODULES</symbol> + are enabled, by echo'ing a new config string to + <constant>/sys/module/<driver>/parameter/<option></constant>. + The driver can be unconfigured by passing an empty string. You cannot + change the configuration while the debugger is attached. Make sure + to detach the debugger with the <constant>detach</constant> command + prior to trying unconfigure a kgdb I/O driver. + </para> + <sect1 id="kgdbwait"> + <title>Kernel parameter: kgdbwait</title> + <para> + The Kernel command line option <constant>kgdbwait</constant> makes + kgdb wait for a debugger connection during booting of a kernel. You + can only use this option you compiled a kgdb I/O driver into the + kernel and you specified the I/O driver configuration as a kernel + command line option. The kgdbwait parameter should always follow the + configuration parameter for the kgdb I/O driver in the kernel + command line else the I/O driver will not be configured prior to + asking the kernel to use it to wait. + </para> + <para> + The kernel will stop and wait as early as the I/O driver and + architecture will allow when you use this option. If you build the + kgdb I/O driver as a kernel module kgdbwait will not do anything. + </para> + </sect1> + <sect1 id="kgdboc"> + <title>Kernel parameter: kgdboc</title> + <para> + The kgdboc driver was originally an abbreviation meant to stand for + "kgdb over console". Kgdboc is designed to work with a single + serial port. It was meant to cover the circumstance + where you wanted to use a serial console as your primary console as + well as using it to perform kernel debugging. Of course you can + also use kgdboc without assigning a console to the same port. + </para> + <sect2 id="UsingKgdboc"> + <title>Using kgdboc</title> + <para> + You can configure kgdboc via sysfs or a module or kernel boot line + parameter depending on if you build with CONFIG_KGDBOC as a module + or built-in. + <orderedlist> + <listitem><para>From the module load or build-in</para> + <para><constant>kgdboc=<tty-device>,[baud]</constant></para> + <para> + The example here would be if your console port was typically ttyS0, you would use something like <constant>kgdboc=ttyS0,115200</constant> or on the ARM Versatile AB you would likely use <constant>kgdboc=ttyAMA0,115200</constant> + </para> + </listitem> + <listitem><para>From sysfs</para> + <para><constant>echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc</constant></para> + </listitem> + </orderedlist> + </para> + <para> + NOTE: Kgdboc does not support interrupting the target via the + gdb remote protocol. You must manually send a sysrq-g unless you + have a proxy that splits console output to a terminal problem and + has a separate port for the debugger to connect to that sends the + sysrq-g for you. + </para> + <para>When using kgdboc with no debugger proxy, you can end up + connecting the debugger for one of two entry points. If an + exception occurs after you have loaded kgdboc a message should print + on the console stating it is waiting for the debugger. In case you + disconnect your terminal program and then connect the debugger in + its place. If you want to interrupt the target system and forcibly + enter a debug session you have to issue a Sysrq sequence and then + type the letter <constant>g</constant>. Then you disconnect the + terminal session and connect gdb. Your options if you don't like + this are to hack gdb to send the sysrq-g for you as well as on the + initial connect, or to use a debugger proxy that allows an + unmodified gdb to do the debugging. + </para> + </sect2> + </sect1> + <sect1 id="kgdbcon"> + <title>Kernel parameter: kgdbcon</title> + <para> + Kgdb supports using the gdb serial protocol to send console messages + to the debugger when the debugger is connected and running. There + are two ways to activate this feature. + <orderedlist> + <listitem><para>Activate with the kernel command line option:</para> + <para><constant>kgdbcon</constant></para> + </listitem> + <listitem><para>Use sysfs before configuring an io driver</para> + <para> + <constant>echo 1 > /sys/module/kgdb/parameters/kgdb_use_con</constant> + </para> + <para> + NOTE: If you do this after you configure the kgdb I/O driver, the + setting will not take effect until the next point the I/O is + reconfigured. + </para> + </listitem> + </orderedlist> + </para> + <para> + IMPORTANT NOTE: Using this option with kgdb over the console + (kgdboc) or kgdb over ethernet (kgdboe) is not supported. + </para> + </sect1> + </chapter> + <chapter id="ConnectingGDB"> + <title>Connecting gdb</title> + <para> + If you are using kgdboc, you need to have used kgdbwait as a boot + argument, issued a sysrq-g, or the system you are going to debug + has already taken an exception and is waiting for the debugger to + attach before you can connect gdb. + </para> + <para> + If you are not using different kgdb I/O driver other than kgdboc, + you should be able to connect and the target will automatically + respond. + </para> + <para> + Example (using a serial port): + </para> + <programlisting> + % gdb ./vmlinux + (gdb) set remotebaud 115200 + (gdb) target remote /dev/ttyS0 + </programlisting> + <para> + Example (kgdb to a terminal server): + </para> + <programlisting> + % gdb ./vmlinux + (gdb) target remote udp:192.168.2.2:6443 + </programlisting> + <para> + Example (kgdb over ethernet): + </para> + <programlisting> + % gdb ./vmlinux + (gdb) target remote udp:192.168.2.2:6443 + </programlisting> + <para> + Once connected, you can debug a kernel the way you would debug an + application program. + </para> + <para> + If you are having problems connecting or something is going + seriously wrong while debugging, it will most often be the case + that you want to enable gdb to be verbose about its target + communications. You do this prior to issuing the <constant>target + remote</constant> command by typing in: <constant>set remote debug 1</constant> + </para> + </chapter> + <chapter id="KGDBTestSuite"> + <title>kgdb Test Suite</title> + <para> + When kgdb is enabled in the kernel config you can also elect to + enable the config parameter KGDB_TESTS. Turning this on will + enable a special kgdb I/O module which is designed to test the + kgdb internal functions. + </para> + <para> + The kgdb tests are mainly intended for developers to test the kgdb + internals as well as a tool for developing a new kgdb architecture + specific implementation. These tests are not really for end users + of the Linux kernel. The primary source of documentation would be + to look in the drivers/misc/kgdbts.c file. + </para> + <para> + The kgdb test suite can also be configured at compile time to run + the core set of tests by setting the kernel config parameter + KGDB_TESTS_ON_BOOT. This particular option is aimed at automated + regression testing and does not require modifying the kernel boot + config arguments. If this is turned on, the kgdb test suite can + be disabled by specifying "kgdbts=" as a kernel boot argument. + </para> + </chapter> + <chapter id="CommonBackEndReq"> + <title>KGDB Internals</title> + <sect1 id="kgdbArchitecture"> + <title>Architecture Specifics</title> + <para> + Kgdb is organized into three basic components: + <orderedlist> + <listitem><para>kgdb core</para> + <para> + The kgdb core is found in kernel/kgdb.c. It contains: + <itemizedlist> + <listitem><para>All the logic to implement the gdb serial protocol</para></listitem> + <listitem><para>A generic OS exception handler which includes sync'ing the processors into a stopped state on an multi cpu system.</para></listitem> + <listitem><para>The API to talk to the kgdb I/O drivers</para></listitem> + <listitem><para>The API to make calls to the arch specific kgdb implementation</para></listitem> + <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> + </itemizedlist> + </para> + </listitem> + <listitem><para>kgdb arch specific implementation</para> + <para> + This implementation is generally found in arch/*/kernel/kgdb.c. + As an example, arch/x86/kernel/kgdb.c contains the specifics to + implement HW breakpoint as well as the initialization to + dynamically register and unregister for the trap handlers on + this architecture. The arch specific portion implements: + <itemizedlist> + <listitem><para>contains an arch specific trap catcher which + invokes kgdb_handle_exception() to start kgdb about doing its + work</para></listitem> + <listitem><para>translation to and from gdb specific packet format to pt_regs</para></listitem> + <listitem><para>Registration and unregistration of architecture specific trap hooks</para></listitem> + <listitem><para>Any special exception handling and cleanup</para></listitem> + <listitem><para>NMI exception handling and cleanup</para></listitem> + <listitem><para>(optional)HW breakpoints</para></listitem> + </itemizedlist> + </para> + </listitem> + <listitem><para>kgdb I/O driver</para> + <para> + Each kgdb I/O driver has to provide an implemenation for the following: + <itemizedlist> + <listitem><para>configuration via builtin or module</para></listitem> + <listitem><para>dynamic configuration and kgdb hook registration calls</para></listitem> + <listitem><para>read and write character interface</para></listitem> + <listitem><para>A cleanup handler for unconfiguring from the kgdb core</para></listitem> + <listitem><para>(optional) Early debug methodology</para></listitem> + </itemizedlist> + Any given kgdb I/O driver has to operate very closely with the + hardware and must do it in such a way that does not enable + interrupts or change other parts of the system context without + completely restoring them. The kgdb core will repeatedly "poll" + a kgdb I/O driver for characters when it needs input. The I/O + driver is expected to return immediately if there is no data + available. Doing so allows for the future possibility to touch + watch dog hardware in such a way as to have a target system not + reset when these are enabled. + </para> + </listitem> + </orderedlist> + </para> + <para> + If you are intent on adding kgdb architecture specific support + for a new architecture, the architecture should define + <constant>HAVE_ARCH_KGDB</constant> in the architecture specific + Kconfig file. This will enable kgdb for the architecture, and + at that point you must create an architecture specific kgdb + implementation. + </para> + <para> + There are a few flags which must be set on every architecture in + their <asm/kgdb.h> file. These are: + <itemizedlist> + <listitem> + <para> + NUMREGBYTES: The size in bytes of all of the registers, so + that we can ensure they will all fit into a packet. + </para> + <para> + BUFMAX: The size in bytes of the buffer GDB will read into. + This must be larger than NUMREGBYTES. + </para> + <para> + CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call + flush_cache_range or flush_icache_range. On some architectures, + these functions may not be safe to call on SMP since we keep other + CPUs in a holding pattern. + </para> + </listitem> + </itemizedlist> + </para> + <para> + There are also the following functions for the common backend, + found in kernel/kgdb.c, that must be supplied by the + architecture-specific backend unless marked as (optional), in + which case a default function maybe used if the architecture + does not need to provide a specific implementation. + </para> +!Iinclude/linux/kgdb.h + </sect1> + <sect1 id="kgdbocDesign"> + <title>kgdboc internals</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" + which the to which the tty driver is attached. In the initial + 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> + <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 + .poll_get_char = serial8250_get_poll_char, + .poll_put_char = serial8250_put_poll_char, +#endif + </programlisting> + Any implementation specifics around creating a polling driver use the + <constant>#ifdef CONFIG_CONSOLE_POLL</constant>, as shown above. + Keep in mind that polling hooks have to be implemented in such a way + 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 + going to mean pressing the reset button. + </para> + </sect1> + </chapter> + <chapter id="credits"> + <title>Credits</title> + <para> + The following people have contributed to this document: + <orderedlist> + <listitem><para>Amit Kale<email>amitkale@linsyssoft.com</email></para></listitem> + <listitem><para>Tom Rini<email>trini@kernel.crashing.org</email></para></listitem> + </orderedlist> + In March 2008 this document was completely rewritten by: + <itemizedlist> + <listitem><para>Jason Wessel<email>jason.wessel@windriver.com</email></para></listitem> + </itemizedlist> + </para> + </chapter> +</book> + diff --git a/Documentation/DocBook/networking.tmpl b/Documentation/DocBook/networking.tmpl new file mode 100644 index 000000000000..f24f9e85e4ae --- /dev/null +++ b/Documentation/DocBook/networking.tmpl @@ -0,0 +1,106 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" + "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> + +<book id="LinuxNetworking"> + <bookinfo> + <title>Linux Networking and Network Devices APIs</title> + + <legalnotice> + <para> + This documentation is free software; you can redistribute + it and/or modify it under the terms of the GNU General Public + License as published by the Free Software Foundation; either + version 2 of the License, or (at your option) any later + version. + </para> + + <para> + This program is distributed in the hope that it will be + useful, but WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + See the GNU General Public License for more details. + </para> + + <para> + You should have received a copy of the GNU General Public + License along with this program; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, + MA 02111-1307 USA + </para> + + <para> + For more details see the file COPYING in the source + distribution of Linux. + </para> + </legalnotice> + </bookinfo> + +<toc></toc> + + <chapter id="netcore"> + <title>Linux Networking</title> + <sect1><title>Networking Base Types</title> +!Iinclude/linux/net.h + </sect1> + <sect1><title>Socket Buffer Functions</title> +!Iinclude/linux/skbuff.h +!Iinclude/net/sock.h +!Enet/socket.c +!Enet/core/skbuff.c +!Enet/core/sock.c +!Enet/core/datagram.c +!Enet/core/stream.c + </sect1> + <sect1><title>Socket Filter</title> +!Enet/core/filter.c + </sect1> + <sect1><title>Generic Network Statistics</title> +!Iinclude/linux/gen_stats.h +!Enet/core/gen_stats.c +!Enet/core/gen_estimator.c + </sect1> + <sect1><title>SUN RPC subsystem</title> +<!-- The !D functionality is not perfect, garbage has to be protected by comments +!Dnet/sunrpc/sunrpc_syms.c +--> +!Enet/sunrpc/xdr.c +!Enet/sunrpc/svc_xprt.c +!Enet/sunrpc/xprt.c +!Enet/sunrpc/sched.c +!Enet/sunrpc/socklib.c +!Enet/sunrpc/stats.c +!Enet/sunrpc/rpc_pipe.c +!Enet/sunrpc/rpcb_clnt.c +!Enet/sunrpc/clnt.c + </sect1> + </chapter> + + <chapter id="netdev"> + <title>Network device support</title> + <sect1><title>Driver Support</title> +!Enet/core/dev.c +!Enet/ethernet/eth.c +!Enet/sched/sch_generic.c +!Iinclude/linux/etherdevice.h +!Iinclude/linux/netdevice.h + </sect1> + <sect1><title>PHY Support</title> +!Edrivers/net/phy/phy.c +!Idrivers/net/phy/phy.c +!Edrivers/net/phy/phy_device.c +!Idrivers/net/phy/phy_device.c +!Edrivers/net/phy/mdio_bus.c +!Idrivers/net/phy/mdio_bus.c + </sect1> +<!-- FIXME: Removed for now since no structured comments in source + <sect1><title>Wireless</title> +X!Enet/core/wireless.c + </sect1> +--> + <sect1><title>Synchronous PPP</title> +!Edrivers/net/wan/syncppp.c + </sect1> + </chapter> + +</book> diff --git a/Documentation/RCU/NMI-RCU.txt b/Documentation/RCU/NMI-RCU.txt index d0634a5c3445..c64158ecde43 100644 --- a/Documentation/RCU/NMI-RCU.txt +++ b/Documentation/RCU/NMI-RCU.txt @@ -25,7 +25,7 @@ the NMI handler to take the default machine-specific action. This nmi_callback variable is a global function pointer to the current NMI handler. - fastcall void do_nmi(struct pt_regs * regs, long error_code) + void do_nmi(struct pt_regs * regs, long error_code) { int cpu; diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist index 34e06d2f194f..da10e0714241 100644 --- a/Documentation/SubmitChecklist +++ b/Documentation/SubmitChecklist @@ -20,7 +20,11 @@ kernel patches. 4: ppc64 is a good architecture for cross-compilation checking because it tends to use `unsigned long' for 64-bit quantities. -5: Matches kernel coding style(!) +5: Check your patch for general style as detailed in + Documentation/CodingStyle. Check for trivial violations with the + patch style checker prior to submission (scripts/checkpatch.pl). + You should be able to justify all violations that remain in + your patch. 6: Any new or modified CONFIG options don't muck up the config menu. @@ -79,13 +83,3 @@ kernel patches. 23: Tested after it has been merged into the -mm patchset to make sure that it still works with all of the other queued patches and various changes in the VM, VFS, and other subsystems. - -24: Avoid whitespace damage such as indenting with spaces or whitespace - at the end of lines. You can test this by feeding the patch to - "git apply --check --whitespace=error-all" - -25: Check your patch for general style as detailed in - Documentation/CodingStyle. Check for trivial violations with the - patch style checker prior to submission (scripts/checkpatch.pl). - You should be able to justify all violations that remain in - your patch. diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 08a1ed1cb5d8..1fc4e7144dce 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -328,7 +328,7 @@ now, but you can do this to mark internal company procedures or just point out some special detail about the sign-off. -13) When to use Acked-by: +13) When to use Acked-by: and Cc: The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path. @@ -349,11 +349,59 @@ Acked-by: does not necessarily indicate acknowledgement of the entire patch. For example, if a patch affects multiple subsystems and has an Acked-by: from one subsystem maintainer then this usually indicates acknowledgement of just the part which affects that maintainer's code. Judgement should be used here. - When in doubt people should refer to the original discussion in the mailing +When in doubt people should refer to the original discussion in the mailing list archives. +If a person has had the opportunity to comment on a patch, but has not +provided such comments, you may optionally add a "Cc:" tag to the patch. +This is the only tag which might be added without an explicit action by the +person it names. This tag documents that potentially interested parties +have been included in the discussion -14) The canonical patch format + +14) Using Test-by: and Reviewed-by: + +A Tested-by: tag indicates that the patch has been successfully tested (in +some environment) by the person named. This tag informs maintainers that +some testing has been performed, provides a means to locate testers for +future patches, and ensures credit for the testers. + +Reviewed-by:, instead, indicates that the patch has been reviewed and found +acceptable according to the Reviewer's Statement: + + Reviewer's statement of oversight + + By offering my Reviewed-by: tag, I state that: + + (a) I have carried out a technical review of this patch to + evaluate its appropriateness and readiness for inclusion into + the mainline kernel. + + (b) Any problems, concerns, or questions relating to the patch + have been communicated back to the submitter. I am satisfied + with the submitter's response to my comments. + + (c) While there may be things that could be improved with this + submission, I believe that it is, at this time, (1) a + worthwhile modification to the kernel, and (2) free of known + issues which would argue against its inclusion. + + (d) While I have reviewed the patch and believe it to be sound, I + do not (unless explicitly stated elsewhere) make any + warranties or guarantees that it will achieve its stated + purpose or function properly in any given situation. + +A Reviewed-by tag is a statement of opinion that the patch is an +appropriate modification of the kernel without any remaining serious +technical issues. Any interested reviewer (who has done the work) can +offer a Reviewed-by tag for a patch. This tag serves to give credit to +reviewers and to inform maintainers of the degree of review which has been +done on the patch. Reviewed-by: tags, when supplied by reviewers known to +understand the subject area and to perform thorough reviews, will normally +increase the liklihood of your patch getting into the kernel. + + +15) The canonical patch format The canonical patch subject line is: @@ -512,7 +560,7 @@ They provide type safety, have no length limitations, no formatting limitations, and under gcc they are as cheap as macros. Macros should only be used for cases where a static inline is clearly -suboptimal [there a few, isolated cases of this in fast paths], +suboptimal [there are a few, isolated cases of this in fast paths], or where it is impossible to use a static inline function [such as string-izing]. diff --git a/Documentation/acpi/dsdt-override.txt b/Documentation/acpi/dsdt-override.txt index 5008f256a2db..febbb1ba4d23 100644 --- a/Documentation/acpi/dsdt-override.txt +++ b/Documentation/acpi/dsdt-override.txt @@ -1,15 +1,7 @@ -Linux supports two methods of overriding the BIOS DSDT: +Linux supports a method of overriding the BIOS DSDT: CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel. -CONFIG_ACPI_CUSTOM_DSDT_INITRD adds the image to the initrd. - -When to use these methods is described in detail on the +When to use this method is described in detail on the Linux/ACPI home page: http://www.lesswatts.org/projects/acpi/overridingDSDT.php - -Note that if both options are used, the DSDT supplied -by the INITRD method takes precedence. - -Documentation/initramfs-add-dsdt.sh is provided for convenience -for use with the CONFIG_ACPI_CUSTOM_DSDT_INITRD method. diff --git a/Documentation/acpi/initramfs-add-dsdt.sh b/Documentation/acpi/initramfs-add-dsdt.sh deleted file mode 100755 index 17ef6e838e14..000000000000 --- a/Documentation/acpi/initramfs-add-dsdt.sh +++ /dev/null @@ -1,43 +0,0 @@ -#!/bin/bash -# Adds a DSDT file to the initrd (if it's an initramfs) -# first argument is the name of archive -# second argument is the name of the file to add -# The file will be copied as /DSDT.aml - -# 20060126: fix "Premature end of file" with some old cpio (Roland Robic) -# 20060205: this time it should really work - -# check the arguments -if [ $# -ne 2 ]; then - program_name=$(basename $0) - echo "\ -$program_name: too few arguments -Usage: $program_name initrd-name.img DSDT-to-add.aml -Adds a DSDT file to an initrd (in initramfs format) - - initrd-name.img: filename of the initrd in initramfs format - DSDT-to-add.aml: filename of the DSDT file to add - " 1>&2 - exit 1 -fi - -# we should check it's an initramfs - -tempcpio=$(mktemp -d) -# cleanup on exit, hangup, interrupt, quit, termination -trap 'rm -rf $tempcpio' 0 1 2 3 15 - -# extract the archive -gunzip -c "$1" > "$tempcpio"/initramfs.cpio || exit 1 - -# copy the DSDT file at the root of the directory so that we can call it "/DSDT.aml" -cp -f "$2" "$tempcpio"/DSDT.aml - -# add the file -cd "$tempcpio" -(echo DSDT.aml | cpio --quiet -H newc -o -A -O "$tempcpio"/initramfs.cpio) || exit 1 -cd "$OLDPWD" - -# re-compress the archive -gzip -c "$tempcpio"/initramfs.cpio > "$1" - diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt index f20c10c2858f..4ef245010457 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt @@ -186,7 +186,8 @@ If the atomic value v is not equal to u, this function adds a to v, and returns non zero. If v is equal to u then it returns zero. This is done as an atomic operation. -atomic_add_unless requires explicit memory barriers around the operation. +atomic_add_unless requires explicit memory barriers around the operation +unless it fails (returns 0). atomic_inc_not_zero, equivalent to atomic_add_unless(v, 1, 0) diff --git a/Documentation/cdrom/ide-cd b/Documentation/cdrom/ide-cd index 29721bfcde12..91c0dcc6fa5c 100644 --- a/Documentation/cdrom/ide-cd +++ b/Documentation/cdrom/ide-cd @@ -45,7 +45,7 @@ This driver provides the following features: --------------- 0. The ide-cd relies on the ide disk driver. See - Documentation/ide.txt for up-to-date information on the ide + Documentation/ide/ide.txt for up-to-date information on the ide driver. 1. Make sure that the ide and ide-cd drivers are compiled into the @@ -64,7 +64,7 @@ This driver provides the following features: Depending on what type of IDE interface you have, you may need to specify additional configuration options. See - Documentation/ide.txt. + Documentation/ide/ide.txt. 2. You should also ensure that the iso9660 filesystem is either compiled into the kernel or available as a loadable module. You @@ -84,7 +84,7 @@ This driver provides the following features: on the primary IDE interface are called `hda' and `hdb', respectively. The drives on the secondary interface are called `hdc' and `hdd'. (Interfaces at other locations get other letters - in the third position; see Documentation/ide.txt.) + in the third position; see Documentation/ide/ide.txt.) If you want your CDROM drive to be found automatically by the driver, you should make sure your IDE interface uses either the @@ -93,7 +93,7 @@ This driver provides the following features: be jumpered as `master'. (If for some reason you cannot configure your system in this manner, you can probably still use the driver. You may have to pass extra configuration information to the kernel - when you boot, however. See Documentation/ide.txt for more + when you boot, however. See Documentation/ide/ide.txt for more information.) 4. Boot the system. If the drive is recognized, you should see a @@ -201,7 +201,7 @@ TEST This section discusses some common problems encountered when trying to use the driver, and some possible solutions. Note that if you are experiencing problems, you should probably also review -Documentation/ide.txt for current information about the underlying +Documentation/ide/ide.txt for current information about the underlying IDE support code. Some of these items apply only to earlier versions of the driver, but are mentioned here for completeness. @@ -211,7 +211,7 @@ from the driver. a. Drive is not detected during booting. - Review the configuration instructions above and in - Documentation/ide.txt, and check how your hardware is + Documentation/ide/ide.txt, and check how your hardware is configured. - If your drive is the only device on an IDE interface, it should @@ -219,7 +219,7 @@ a. Drive is not detected during booting. - If your IDE interface is not at the standard addresses of 0x170 or 0x1f0, you'll need to explicitly inform the driver using a - lilo option. See Documentation/ide.txt. (This feature was + lilo option. See Documentation/ide/ide.txt. (This feature was added around kernel version 1.3.30.) - If the autoprobing is not finding your drive, you can tell the @@ -245,7 +245,7 @@ a. Drive is not detected during booting. Support for some interfaces needing extra initialization is provided in later 1.3.x kernels. You may need to turn on additional kernel configuration options to get them to work; - see Documentation/ide.txt. + see Documentation/ide/ide.txt. Even if support is not available for your interface, you may be able to get it to work with the following procedure. First boot @@ -299,7 +299,7 @@ c. System hangups. be worked around by specifying the `serialize' option when booting. Recent kernels should be able to detect the need for this automatically in most cases, but the detection is not - foolproof. See Documentation/ide.txt for more information + foolproof. See Documentation/ide/ide.txt for more information about the `serialize' option and the CMD640B. - Note that many MS-DOS CDROM drivers will work with such buggy diff --git a/Documentation/cgroups.txt b/Documentation/cgroups.txt index 42d7c4cb39cd..31d12e21ff8a 100644 --- a/Documentation/cgroups.txt +++ b/Documentation/cgroups.txt @@ -28,7 +28,7 @@ CONTENTS: 4. Questions 1. Control Groups -========== +================= 1.1 What are cgroups ? ---------------------- @@ -143,10 +143,10 @@ proliferation of such cgroups. Also lets say that the administrator would like to give enhanced network access temporarily to a student's browser (since it is night and the user -wants to do online gaming :) OR give one of the students simulation +wants to do online gaming :)) OR give one of the students simulation apps enhanced CPU power, -With ability to write pids directly to resource classes, its just a +With ability to write pids directly to resource classes, it's just a matter of : # echo pid > /mnt/network/<new_class>/tasks @@ -227,10 +227,13 @@ Each cgroup is represented by a directory in the cgroup file system containing the following files describing that cgroup: - tasks: list of tasks (by pid) attached to that cgroup - - notify_on_release flag: run /sbin/cgroup_release_agent on exit? + - releasable flag: cgroup currently removeable? + - notify_on_release flag: run the release agent on exit? + - release_agent: the path to use for release notifications (this file + exists in the top cgroup only) Other subsystems such as cpusets may add additional files in each -cgroup dir +cgroup dir. New cgroups are created using the mkdir system call or shell command. The properties of a cgroup, such as its flags, are @@ -257,7 +260,7 @@ performance. To allow access from a cgroup to the css_sets (and hence tasks) that comprise it, a set of cg_cgroup_link objects form a lattice; each cg_cgroup_link is linked into a list of cg_cgroup_links for -a single cgroup on its cont_link_list field, and a list of +a single cgroup on its cgrp_link_list field, and a list of cg_cgroup_links for a single css_set on its cg_link_list. Thus the set of tasks in a cgroup can be listed by iterating over @@ -271,9 +274,6 @@ for cgroups, with a minimum of additional kernel code. 1.4 What does notify_on_release do ? ------------------------------------ -*** notify_on_release is disabled in the current patch set. It will be -*** reactivated in a future patch in a less-intrusive manner - If the notify_on_release flag is enabled (1) in a cgroup, then whenever the last task in the cgroup leaves (exits or attaches to some other cgroup) and the last child cgroup of that cgroup @@ -360,8 +360,8 @@ Now you want to do something with this cgroup. In this directory you can find several files: # ls -notify_on_release release_agent tasks -(plus whatever files are added by the attached subsystems) +notify_on_release releasable tasks +(plus whatever files added by the attached subsystems) Now attach your shell to this cgroup: # /bin/echo $$ > tasks @@ -404,19 +404,13 @@ with a subsystem id which will be assigned by the cgroup system. Other fields in the cgroup_subsys object include: - subsys_id: a unique array index for the subsystem, indicating which - entry in cgroup->subsys[] this subsystem should be - managing. Initialized by cgroup_register_subsys(); prior to this - it should be initialized to -1 + entry in cgroup->subsys[] this subsystem should be managing. -- hierarchy: an index indicating which hierarchy, if any, this - subsystem is currently attached to. If this is -1, then the - subsystem is not attached to any hierarchy, and all tasks should be - considered to be members of the subsystem's top_cgroup. It should - be initialized to -1. +- name: should be initialized to a unique subsystem name. Should be + no longer than MAX_CGROUP_TYPE_NAMELEN. -- name: should be initialized to a unique subsystem name prior to - calling cgroup_register_subsystem. Should be no longer than - MAX_CGROUP_TYPE_NAMELEN +- early_init: indicate if the subsystem needs early initialization + at system boot. Each cgroup object created by the system has an array of pointers, indexed by subsystem id; this pointer is entirely managed by the @@ -434,8 +428,6 @@ situation. See kernel/cgroup.c for more details. Subsystems can take/release the cgroup_mutex via the functions -cgroup_lock()/cgroup_unlock(), and can -take/release the callback_mutex via the functions cgroup_lock()/cgroup_unlock(). Accessing a task's cgroup pointer may be done in the following ways: @@ -444,7 +436,7 @@ Accessing a task's cgroup pointer may be done in the following ways: - inside an rcu_read_lock() section via rcu_dereference() 3.3 Subsystem API --------------------------- +----------------- Each subsystem should: @@ -455,7 +447,8 @@ Each subsystem may export the following methods. The only mandatory methods are create/destroy. Any others that are null are presumed to be successful no-ops. -struct cgroup_subsys_state *create(struct cgroup *cont) +struct cgroup_subsys_state *create(struct cgroup_subsys *ss, + struct cgroup *cgrp) (cgroup_mutex held by caller) Called to create a subsystem state object for a cgroup. The @@ -470,7 +463,7 @@ identified by the passed cgroup object having a NULL parent (since it's the root of the hierarchy) and may be an appropriate place for initialization code. -void destroy(struct cgroup *cont) +void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp) (cgroup_mutex held by caller) The cgroup system is about to destroy the passed cgroup; the subsystem @@ -481,7 +474,14 @@ cgroup->parent is still valid. (Note - can also be called for a newly-created cgroup if an error occurs after this subsystem's create() method has been called for the new cgroup). -int can_attach(struct cgroup_subsys *ss, struct cgroup *cont, +void pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp); +(cgroup_mutex held by caller) + +Called before checking the reference count on each subsystem. This may +be useful for subsystems which have some extra references even if +there are not tasks in the cgroup. + +int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, struct task_struct *task) (cgroup_mutex held by caller) @@ -492,8 +492,8 @@ unspecified task can be moved into the cgroup. Note that this isn't called on a fork. If this method returns 0 (success) then this should remain valid while the caller holds cgroup_mutex. -void attach(struct cgroup_subsys *ss, struct cgroup *cont, - struct cgroup *old_cont, struct task_struct *task) +void attach(struct cgroup_subsys *ss, struct cgroup *cgrp, + struct cgroup *old_cgrp, struct task_struct *task) Called after the task has been attached to the cgroup, to allow any post-attachment activity that requires memory allocations or blocking. @@ -505,9 +505,9 @@ registration for all existing tasks. void exit(struct cgroup_subsys *ss, struct task_struct *task) -Called during task exit +Called during task exit. -int populate(struct cgroup_subsys *ss, struct cgroup *cont) +int populate(struct cgroup_subsys *ss, struct cgroup *cgrp) Called after creation of a cgroup to allow a subsystem to populate the cgroup directory with file entries. The subsystem should make @@ -516,7 +516,7 @@ include/linux/cgroup.h for details). Note that although this method can return an error code, the error code is currently not always handled well. -void post_clone(struct cgroup_subsys *ss, struct cgroup *cont) +void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp) Called at the end of cgroup_clone() to do any paramater initialization which might be required before a task could attach. For diff --git a/Documentation/controllers/memory.txt b/Documentation/controllers/memory.txt index b5bbea92a61a..866b9cd9a959 100644 --- a/Documentation/controllers/memory.txt +++ b/Documentation/controllers/memory.txt @@ -1,4 +1,8 @@ -Memory Controller +Memory Resource Controller + +NOTE: The Memory Resource Controller has been generically been referred +to as the memory controller in this document. Do not confuse memory controller +used here with the memory controller that is used in hardware. Salient features @@ -152,7 +156,7 @@ The memory controller uses the following hierarchy a. Enable CONFIG_CGROUPS b. Enable CONFIG_RESOURCE_COUNTERS -c. Enable CONFIG_CGROUP_MEM_CONT +c. Enable CONFIG_CGROUP_MEM_RES_CTLR 1. Prepare the cgroups # mkdir -p /cgroups @@ -164,20 +168,20 @@ c. Enable CONFIG_CGROUP_MEM_CONT Since now we're in the 0 cgroup, We can alter the memory limit: -# echo -n 4M > /cgroups/0/memory.limit_in_bytes +# echo 4M > /cgroups/0/memory.limit_in_bytes NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo, mega or gigabytes. # cat /cgroups/0/memory.limit_in_bytes -4194304 Bytes +4194304 NOTE: The interface has now changed to display the usage in bytes instead of pages We can check the usage: # cat /cgroups/0/memory.usage_in_bytes -1216512 Bytes +1216512 A successful write to this file does not guarantee a successful set of this limit to the value written into the file. This can be due to a @@ -185,9 +189,9 @@ number of factors, such as rounding up to page boundaries or the total availability of memory on the system. The user is required to re-read this file after a write to guarantee the value committed by the kernel. -# echo -n 1 > memory.limit_in_bytes +# echo 1 > memory.limit_in_bytes # cat memory.limit_in_bytes -4096 Bytes +4096 The memory.failcnt field gives the number of times that the cgroup limit was exceeded. @@ -197,7 +201,7 @@ caches, RSS and Active pages/Inactive pages are shown. The memory.force_empty gives an interface to drop *all* charges by force. -# echo -n 1 > memory.force_empty +# echo 1 > memory.force_empty will drop all charges in cgroup. Currently, this is maintained for test. @@ -233,13 +237,6 @@ cgroup might have some charge associated with it, even though all tasks have migrated away from it. Such charges are automatically dropped at rmdir() if there are no tasks. -4.4 Choosing what to account -- Page Cache (unmapped) vs RSS (mapped)? - -The type of memory accounted by the cgroup can be limited to just -mapped pages by writing "1" to memory.control_type field - -echo -n 1 > memory.control_type - 5. TODO 1. Add support for accounting huge pages (as a separate controller) @@ -262,18 +259,19 @@ References 3. Emelianov, Pavel. Resource controllers based on process cgroups http://lkml.org/lkml/2007/3/6/198 4. Emelianov, Pavel. RSS controller based on process cgroups (v2) - http://lkml.org/lkml/2007/4/9/74 + http://lkml.org/lkml/2007/4/9/78 5. Emelianov, Pavel. RSS controller based on process cgroups (v3) http://lkml.org/lkml/2007/5/30/244 6. Menage, Paul. Control Groups v10, http://lwn.net/Articles/236032/ 7. Vaidyanathan, Srinivasan, Control Groups: Pagecache accounting and control subsystem (v3), http://lwn.net/Articles/235534/ -8. Singh, Balbir. RSS controller V2 test results (lmbench), +8. Singh, Balbir. RSS controller v2 test results (lmbench), http://lkml.org/lkml/2007/5/17/232 -9. Singh, Balbir. RSS controller V2 AIM9 results +9. Singh, Balbir. RSS controller v2 AIM9 results http://lkml.org/lkml/2007/5/18/1 -10. Singh, Balbir. Memory controller v6 results, +10. Singh, Balbir. Memory controller v6 test results, http://lkml.org/lkml/2007/8/19/36 -11. Singh, Balbir. Memory controller v6, http://lkml.org/lkml/2007/8/17/69 +11. Singh, Balbir. Memory controller introduction (v6), + http://lkml.org/lkml/2007/8/17/69 12. Corbet, Jonathan, Controlling memory use in cgroups, http://lwn.net/Articles/243795/ diff --git a/Documentation/cpuidle/core.txt b/Documentation/cpuidle/core.txt new file mode 100644 index 000000000000..63ecc5dc9d8a --- /dev/null +++ b/Documentation/cpuidle/core.txt @@ -0,0 +1,23 @@ + + Supporting multiple CPU idle levels in kernel + + cpuidle + +General Information: + +Various CPUs today support multiple idle levels that are differentiated +by varying exit latencies and power consumption during idle. +cpuidle is a generic in-kernel infrastructure that separates +idle policy (governor) from idle mechanism (driver) and provides a +standardized infrastructure to support independent development of +governors and drivers. + +cpuidle resides under drivers/cpuidle. + +Boot options: +"cpuidle_sysfs_switch" +enables current_governor interface in /sys/devices/system/cpu/cpuidle/, +which can be used to switch governors at run time. This boot option +is meant for developer testing only. In normal usage, kernel picks the +best governor based on governor ratings. +SEE ALSO: sysfs.txt in this directory. diff --git a/Documentation/cpuidle/driver.txt b/Documentation/cpuidle/driver.txt new file mode 100644 index 000000000000..7a9e09ece931 --- /dev/null +++ b/Documentation/cpuidle/driver.txt @@ -0,0 +1,31 @@ + + + Supporting multiple CPU idle levels in kernel + + cpuidle drivers + + + + +cpuidle driver hooks into the cpuidle infrastructure and handles the +architecture/platform dependent part of CPU idle states. Driver +provides the platform idle state detection capability and also +has mechanisms in place to support actual entry-exit into CPU idle states. + +cpuidle driver initializes the cpuidle_device structure for each CPU device +and registers with cpuidle using cpuidle_register_device. + +It can also support the dynamic changes (like battery <-> AC), by using +cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device, +cpuidle_resume_and_unlock. + +Interfaces: +extern int cpuidle_register_driver(struct cpuidle_driver *drv); +extern void cpuidle_unregister_driver(struct cpuidle_driver *drv); +extern int cpuidle_register_device(struct cpuidle_device *dev); +extern void cpuidle_unregister_device(struct cpuidle_device *dev); + +extern void cpuidle_pause_and_lock(void); +extern void cpuidle_resume_and_unlock(void); +extern int cpuidle_enable_device(struct cpuidle_device *dev); +extern void cpuidle_disable_device(struct cpuidle_device *dev); diff --git a/Documentation/cpuidle/governor.txt b/Documentation/cpuidle/governor.txt new file mode 100644 index 000000000000..12c6bd50c9f6 --- /dev/null +++ b/Documentation/cpuidle/governor.txt @@ -0,0 +1,29 @@ + + + + Supporting multiple CPU idle levels in kernel + + cpuidle governors + + + + +cpuidle governor is policy routine that decides what idle state to enter at +any given time. cpuidle core uses different callbacks to the governor. + +* enable() to enable governor for a particular device +* disable() to disable governor for a particular device +* select() to select an idle state to enter +* reflect() called after returning from the idle state, which can be used + by the governor for some record keeping. + +More than one governor can be registered at the same time and +users can switch between drivers using /sysfs interface (when enabled). +More than one governor part is supported for developers to easily experiment +with different governors. By default, most optimal governor based on your +kernel configuration and platform will be selected by cpuidle. + +Interfaces: +extern int cpuidle_register_governor(struct cpuidle_governor *gov); +extern void cpuidle_unregister_governor(struct cpuidle_governor *gov); +struct cpuidle_governor diff --git a/Documentation/cpuidle/sysfs.txt b/Documentation/cpuidle/sysfs.txt new file mode 100644 index 000000000000..50d7b1642759 --- /dev/null +++ b/Documentation/cpuidle/sysfs.txt @@ -0,0 +1,79 @@ + + + Supporting multiple CPU idle levels in kernel + + cpuidle sysfs + +System global cpuidle related information and tunables are under +/sys/devices/system/cpu/cpuidle + +The current interfaces in this directory has self-explanatory names: +* current_driver +* current_governor_ro + +With cpuidle_sysfs_switch boot option (meant for developer testing) +following objects are visible instead. +* current_driver +* available_governors +* current_governor +In this case users can switch the governor at run time by writing +to current_governor. + + +Per logical CPU specific cpuidle information are under +/sys/devices/system/cpu/cpuX/cpuidle +for each online cpu X + +-------------------------------------------------------------------------------- +# ls -lR /sys/devices/system/cpu/cpu0/cpuidle/ +/sys/devices/system/cpu/cpu0/cpuidle/: +total 0 +drwxr-xr-x 2 root root 0 Feb 8 10:42 state0 +drwxr-xr-x 2 root root 0 Feb 8 10:42 state1 +drwxr-xr-x 2 root root 0 Feb 8 10:42 state2 +drwxr-xr-x 2 root root 0 Feb 8 10:42 state3 + +/sys/devices/system/cpu/cpu0/cpuidle/state0: +total 0 +-r--r--r-- 1 root root 4096 Feb 8 10:42 desc +-r--r--r-- 1 root root 4096 Feb 8 10:42 latency +-r--r--r-- 1 root root 4096 Feb 8 10:42 name +-r--r--r-- 1 root root 4096 Feb 8 10:42 power +-r--r--r-- 1 root root 4096 Feb 8 10:42 time +-r--r--r-- 1 root root 4096 Feb 8 10:42 usage + +/sys/devices/system/cpu/cpu0/cpuidle/state1: +total 0 +-r--r--r-- 1 root root 4096 Feb 8 10:42 desc +-r--r--r-- 1 root root 4096 Feb 8 10:42 latency +-r--r--r-- 1 root root 4096 Feb 8 10:42 name +-r--r--r-- 1 root root 4096 Feb 8 10:42 power +-r--r--r-- 1 root root 4096 Feb 8 10:42 time +-r--r--r-- 1 root root 4096 Feb 8 10:42 usage + +/sys/devices/system/cpu/cpu0/cpuidle/state2: +total 0 +-r--r--r-- 1 root root 4096 Feb 8 10:42 desc +-r--r--r-- 1 root root 4096 Feb 8 10:42 latency +-r--r--r-- 1 root root 4096 Feb 8 10:42 name +-r--r--r-- 1 root root 4096 Feb 8 10:42 power +-r--r--r-- 1 root root 4096 Feb 8 10:42 time +-r--r--r-- 1 root root 4096 Feb 8 10:42 usage + +/sys/devices/system/cpu/cpu0/cpuidle/state3: +total 0 +-r--r--r-- 1 root root 4096 Feb 8 10:42 desc +-r--r--r-- 1 root root 4096 Feb 8 10:42 latency +-r--r--r-- 1 root root 4096 Feb 8 10:42 name +-r--r--r-- 1 root root 4096 Feb 8 10:42 power +-r--r--r-- 1 root root 4096 Feb 8 10:42 time +-r--r--r-- 1 root root 4096 Feb 8 10:42 usage +-------------------------------------------------------------------------------- + + +* desc : Small description about the idle state (string) +* latency : Latency to exit out of this idle state (in microseconds) +* name : Name of the idle state (string) +* power : Power consumed while in this idle state (in milliwatts) +* time : Total time spent in this idle state (in microseconds) +* usage : Number of times this state was entered (count) diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt index 43db6fe12814..ad2bb3b3acc1 100644 --- a/Documentation/cpusets.txt +++ b/Documentation/cpusets.txt @@ -209,7 +209,7 @@ and name space for cpusets, with a minimum of additional kernel code. The cpus and mems files in the root (top_cpuset) cpuset are read-only. The cpus file automatically tracks the value of cpu_online_map using a CPU hotplug notifier, and the mems file -automatically tracks the value of node_states[N_MEMORY]--i.e., +automatically tracks the value of node_states[N_HIGH_MEMORY]--i.e., nodes with memory--using the cpuset_track_online_nodes() hook. diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/debugging-via-ohci1394.txt index de4804e8b396..c360d4e91b48 100644 --- a/Documentation/debugging-via-ohci1394.txt +++ b/Documentation/debugging-via-ohci1394.txt @@ -36,14 +36,15 @@ available (notebooks) or too slow for extensive debug information (like ACPI). Drivers ------- -The OHCI-1394 drivers in drivers/firewire and drivers/ieee1394 initialize -the OHCI-1394 controllers to a working state and can be used to enable -physical DMA. By default you only have to load the driver, and physical -DMA access will be granted to all remote nodes, but it can be turned off -when using the ohci1394 driver. - -Because these drivers depend on the PCI enumeration to be completed, an -initialization routine which can runs pretty early (long before console_init(), +The ohci1394 driver in drivers/ieee1394 initializes the OHCI-1394 controllers +to a working state and enables physical DMA by default for all remote nodes. +This can be turned off by ohci1394's module parameter phys_dma=0. + +The alternative firewire-ohci driver in drivers/firewire uses filtered physical +DMA, hence is not yet suitable for remote debugging. + +Because ohci1394 depends on the PCI enumeration to be completed, an +initialization routine which runs pretty early (long before console_init() which makes the printk buffer appear on the console can be called) was written. To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu: diff --git a/Documentation/fb/cmap_xfbdev.txt b/Documentation/fb/cmap_xfbdev.txt new file mode 100644 index 000000000000..55e1f0a3d2b4 --- /dev/null +++ b/Documentation/fb/cmap_xfbdev.txt @@ -0,0 +1,53 @@ +Understanding fbdev's cmap +-------------------------- + +These notes explain how X's dix layer uses fbdev's cmap structures. + +*. example of relevant structures in fbdev as used for a 3-bit grayscale cmap +struct fb_var_screeninfo { + .bits_per_pixel = 8, + .grayscale = 1, + .red = { 4, 3, 0 }, + .green = { 0, 0, 0 }, + .blue = { 0, 0, 0 }, +} +struct fb_fix_screeninfo { + .visual = FB_VISUAL_STATIC_PSEUDOCOLOR, +} +for (i = 0; i < 8; i++) + info->cmap.red[i] = (((2*i)+1)*(0xFFFF))/16; +memcpy(info->cmap.green, info->cmap.red, sizeof(u16)*8); +memcpy(info->cmap.blue, info->cmap.red, sizeof(u16)*8); + +*. X11 apps do something like the following when trying to use grayscale. +for (i=0; i < 8; i++) { + char colorspec[64]; + memset(colorspec,0,64); + sprintf(colorspec, "rgb:%x/%x/%x", i*36,i*36,i*36); + if (!XParseColor(outputDisplay, testColormap, colorspec, &wantedColor)) + printf("Can't get color %s\n",colorspec); + XAllocColor(outputDisplay, testColormap, &wantedColor); + grays[i] = wantedColor; +} +There's also named equivalents like gray1..x provided you have an rgb.txt. + +Somewhere in X's callchain, this results in a call to X code that handles the +colormap. For example, Xfbdev hits the following: + +xc-011010/programs/Xserver/dix/colormap.c: + +FindBestPixel(pentFirst, size, prgb, channel) + +dr = (long) pent->co.local.red - prgb->red; +dg = (long) pent->co.local.green - prgb->green; +db = (long) pent->co.local.blue - prgb->blue; +sq = dr * dr; +UnsignedToBigNum (sq, &sum); +BigNumAdd (&sum, &temp, &sum); + +co.local.red are entries that were brought in through FBIOGETCMAP which come +directly from the info->cmap.red that was listed above. The prgb is the rgb +that the app wants to match to. The above code is doing what looks like a least +squares matching function. That's why the cmap entries can't be set to the left +hand side boundaries of a color range. + diff --git a/Documentation/fb/metronomefb.txt b/Documentation/fb/metronomefb.txt new file mode 100644 index 000000000000..b9a2e7b7e838 --- /dev/null +++ b/Documentation/fb/metronomefb.txt @@ -0,0 +1,38 @@ + Metronomefb + ----------- +Maintained by Jaya Kumar <jayakumar.lkml.gmail.com> +Last revised: Nov 20, 2007 + +Metronomefb is a driver for the Metronome display controller. The controller +is from E-Ink Corporation. It is intended to be used to drive the E-Ink +Vizplex display media. E-Ink hosts some details of this controller and the +display media here http://www.e-ink.com/products/matrix/metronome.html . + +Metronome is interfaced to the host CPU through the AMLCD interface. The +host CPU generates the control information and the image in a framebuffer +which is then delivered to the AMLCD interface by a host specific method. +Currently, that's implemented for the PXA's LCDC controller. The display and +error status are each pulled through individual GPIOs. + +Metronomefb was written for the PXA255/gumstix/lyre combination and +therefore currently has board set specific code in it. If other boards based on +other architectures are available, then the host specific code can be separated +and abstracted out. + +Metronomefb requires waveform information which is delivered via the AMLCD +interface to the metronome controller. The waveform information is expected to +be delivered from userspace via the firmware class interface. The waveform file +can be compressed as long as your udev or hotplug script is aware of the need +to uncompress it before delivering it. metronomefb will ask for waveform.wbf +which would typically go into /lib/firmware/waveform.wbf depending on your +udev/hotplug setup. I have only tested with a single waveform file which was +originally labeled 23P01201_60_WT0107_MTC. I do not know what it stands for. +Caution should be exercised when manipulating the waveform as there may be +a possibility that it could have some permanent effects on the display media. +I neither have access to nor know exactly what the waveform does in terms of +the physical media. + +Metronomefb uses the deferred IO interface so that it can provide a memory +mappable frame buffer. It has been tested with tinyx (Xfbdev). It is known +to work at this time with xeyes, xclock, xloadimage, xpdf. + diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 4d3aa519eadf..164c89394cff 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -212,7 +212,7 @@ Who: Stephen Hemminger <shemminger@linux-foundation.org> --------------------------- What: i386/x86_64 bzImage symlinks -When: April 2008 +When: April 2010 Why: The i386/x86_64 merge provides a symlink to the old bzImage location so not yet updated user space tools, e.g. package @@ -306,3 +306,15 @@ Why: Largely unmaintained and almost entirely unused. File system is largely pointless as without a lot of work only the most trivial of Solaris binaries can work with the emulation code. Who: David S. Miller <davem@davemloft.net> + +--------------------------- + +What: init_mm export +When: 2.6.26 +Why: Not used in-tree. The current out-of-tree users used it to + work around problems in the CPA code which should be resolved + by now. One usecase was described to provide verification code + of the CPA operation. That's a good idea in general, but such + code / infrastructure should be in the kernel and not in some + out-of-tree driver. +Who: Thomas Gleixner <tglx@linutronix.de> diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index e68021c08fbd..52cd611277a3 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -66,6 +66,8 @@ mandatory-locking.txt - info on the Linux implementation of Sys V mandatory file locking. ncpfs.txt - info on Novell Netware(tm) filesystem using NCP protocol. +nfsroot.txt + - short guide on setting up a diskless box with NFS root filesystem. ntfs.txt - info and mount options for the NTFS filesystem (Windows NT). ocfs2.txt @@ -82,6 +84,10 @@ relay.txt - info on relay, for efficient streaming from kernel to user space. romfs.txt - description of the ROMFS filesystem. +rpc-cache.txt + - introduction to the caching mechanisms in the sunrpc layer. +seq_file.txt + - how to use the seq_file API sharedsubtree.txt - a description of shared subtrees for namespaces. smbfs.txt diff --git a/Documentation/nfsroot.txt b/Documentation/filesystems/nfsroot.txt index 31b329172343..31b329172343 100644 --- a/Documentation/nfsroot.txt +++ b/Documentation/filesystems/nfsroot.txt diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 5681e2fa1496..518ebe609e2b 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -1506,13 +1506,13 @@ laptop_mode ----------- laptop_mode is a knob that controls "laptop mode". All the things that are -controlled by this knob are discussed in Documentation/laptop-mode.txt. +controlled by this knob are discussed in Documentation/laptops/laptop-mode.txt. block_dump ---------- block_dump enables block I/O debugging when set to a nonzero value. More -information on block I/O debugging is in Documentation/laptop-mode.txt. +information on block I/O debugging is in Documentation/laptops/laptop-mode.txt. swap_token_timeout ------------------ diff --git a/Documentation/rpc-cache.txt b/Documentation/filesystems/rpc-cache.txt index 8a382bea6808..8a382bea6808 100644 --- a/Documentation/rpc-cache.txt +++ b/Documentation/filesystems/rpc-cache.txt diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt new file mode 100644 index 000000000000..7fb8e6dc62bf --- /dev/null +++ b/Documentation/filesystems/seq_file.txt @@ -0,0 +1,283 @@ +The seq_file interface + + Copyright 2003 Jonathan Corbet <corbet@lwn.net> + This file is originally from the LWN.net Driver Porting series at + http://lwn.net/Articles/driver-porting/ + + +There are numerous ways for a device driver (or other kernel component) to +provide information to the user or system administrator. One useful +technique is the creation of virtual files, in debugfs, /proc or elsewhere. +Virtual files can provide human-readable output that is easy to get at +without any special utility programs; they can also make life easier for +script writers. It is not surprising that the use of virtual files has +grown over the years. + +Creating those files correctly has always been a bit of a challenge, +however. It is not that hard to make a virtual file which returns a +string. But life gets trickier if the output is long - anything greater +than an application is likely to read in a single operation. Handling +multiple reads (and seeks) requires careful attention to the reader's +position within the virtual file - that position is, likely as not, in the +middle of a line of output. The kernel has traditionally had a number of +implementations that got this wrong. + +The 2.6 kernel contains a set of functions (implemented by Alexander Viro) +which are designed to make it easy for virtual file creators to get it +right. + +The seq_file interface is available via <linux/seq_file.h>. There are +three aspects to seq_file: + + * An iterator interface which lets a virtual file implementation + step through the objects it is presenting. + + * Some utility functions for formatting objects for output without + needing to worry about things like output buffers. + + * A set of canned file_operations which implement most operations on + the virtual file. + +We'll look at the seq_file interface via an extremely simple example: a +loadable module which creates a file called /proc/sequence. The file, when +read, simply produces a set of increasing integer values, one per line. The +sequence will continue until the user loses patience and finds something +better to do. The file is seekable, in that one can do something like the +following: + + dd if=/proc/sequence of=out1 count=1 + dd if=/proc/sequence skip=1 out=out2 count=1 + +Then concatenate the output files out1 and out2 and get the right +result. Yes, it is a thoroughly useless module, but the point is to show +how the mechanism works without getting lost in other details. (Those +wanting to see the full source for this module can find it at +http://lwn.net/Articles/22359/). + + +The iterator interface + +Modules implementing a virtual file with seq_file must implement a simple +iterator object that allows stepping through the data of interest. +Iterators must be able to move to a specific position - like the file they +implement - but the interpretation of that position is up to the iterator +itself. A seq_file implementation that is formatting firewall rules, for +example, could interpret position N as the Nth rule in the chain. +Positioning can thus be done in whatever way makes the most sense for the +generator of the data, which need not be aware of how a position translates +to an offset in the virtual file. The one obvious exception is that a +position of zero should indicate the beginning of the file. + +The /proc/sequence iterator just uses the count of the next number it +will output as its position. + +Four functions must be implemented to make the iterator work. The first, +called start() takes a position as an argument and returns an iterator +which will start reading at that position. For our simple sequence example, +the start() function looks like: + + static void *ct_seq_start(struct seq_file *s, loff_t *pos) + { + loff_t *spos = kmalloc(sizeof(loff_t), GFP_KERNEL); + if (! spos) + return NULL; + *spos = *pos; + return spos; + } + +The entire data structure for this iterator is a single loff_t value +holding the current position. There is no upper bound for the sequence +iterator, but that will not be the case for most other seq_file +implementations; in most cases the start() function should check for a +"past end of file" condition and return NULL if need be. + +For more complicated applications, the private field of the seq_file +structure can be used. There is also a special value which can be returned +by the start() function called SEQ_START_TOKEN; it can be used if you wish +to instruct your show() function (described below) to print a header at the +top of the output. SEQ_START_TOKEN should only be used if the offset is +zero, however. + +The next function to implement is called, amazingly, next(); its job is to +move the iterator forward to the next position in the sequence. The +example module can simply increment the position by one; more useful +modules will do what is needed to step through some data structure. The +next() function returns a new iterator, or NULL if the sequence is +complete. Here's the example version: + + static void *ct_seq_next(struct seq_file *s, void *v, loff_t *pos) + { + loff_t *spos = v; + *pos = ++*spos; + return spos; + } + +The stop() function is called when iteration is complete; its job, of +course, is to clean up. If dynamic memory is allocated for the iterator, +stop() is the place to free it. + + static void ct_seq_stop(struct seq_file *s, void *v) + { + kfree(v); + } + +Finally, the show() function should format the object currently pointed to +by the iterator for output. It should return zero, or an error code if +something goes wrong. The example module's show() function is: + + static int ct_seq_show(struct seq_file *s, void *v) + { + loff_t *spos = v; + seq_printf(s, "%lld\n", (long long)*spos); + return 0; + } + +We will look at seq_printf() in a moment. But first, the definition of the +seq_file iterator is finished by creating a seq_operations structure with +the four functions we have just defined: + + static const struct seq_operations ct_seq_ops = { + .start = ct_seq_start, + .next = ct_seq_next, + .stop = ct_seq_stop, + .show = ct_seq_show + }; + +This structure will be needed to tie our iterator to the /proc file in +a little bit. + +It's worth noting that the iterator value returned by start() and +manipulated by the other functions is considered to be completely opaque by +the seq_file code. It can thus be anything that is useful in stepping +through the data to be output. Counters can be useful, but it could also be +a direct pointer into an array or linked list. Anything goes, as long as +the programmer is aware that things can happen between calls to the +iterator function. However, the seq_file code (by design) will not sleep +between the calls to start() and stop(), so holding a lock during that time +is a reasonable thing to do. The seq_file code will also avoid taking any +other locks while the iterator is active. + + +Formatted output + +The seq_file code manages positioning within the output created by the +iterator and getting it into the user's buffer. But, for that to work, that +output must be passed to the seq_file code. Some utility functions have +been defined which make this task easy. + +Most code will simply use seq_printf(), which works pretty much like +printk(), but which requires the seq_file pointer as an argument. It is +common to ignore the return value from seq_printf(), but a function +producing complicated output may want to check that value and quit if +something non-zero is returned; an error return means that the seq_file +buffer has been filled and further output will be discarded. + +For straight character output, the following functions may be used: + + int seq_putc(struct seq_file *m, char c); + int seq_puts(struct seq_file *m, const char *s); + int seq_escape(struct seq_file *m, const char *s, const char *esc); + +The first two output a single character and a string, just like one would +expect. seq_escape() is like seq_puts(), except that any character in s +which is in the string esc will be represented in octal form in the output. + +There is also a function for printing filenames: + + int seq_path(struct seq_file *m, struct path *path, char *esc); + +Here, path indicates the file of interest, and esc is a set of characters +which should be escaped in the output. + + +Making it all work + +So far, we have a nice set of functions which can produce output within the +seq_file system, but we have not yet turned them into a file that a user +can see. Creating a file within the kernel requires, of course, the +creation of a set of file_operations which implement the operations on that +file. The seq_file interface provides a set of canned operations which do +most of the work. The virtual file author still must implement the open() +method, however, to hook everything up. The open function is often a single +line, as in the example module: + + static int ct_open(struct inode *inode, struct file *file) + { + return seq_open(file, &ct_seq_ops); + } + +Here, the call to seq_open() takes the seq_operations structure we created +before, and gets set up to iterate through the virtual file. + +On a successful open, seq_open() stores the struct seq_file pointer in +file->private_data. If you have an application where the same iterator can +be used for more than one file, you can store an arbitrary pointer in the +private field of the seq_file structure; that value can then be retrieved +by the iterator functions. + +The other operations of interest - read(), llseek(), and release() - are +all implemented by the seq_file code itself. So a virtual file's +file_operations structure will look like: + + static const struct file_operations ct_file_ops = { + .owner = THIS_MODULE, + .open = ct_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release + }; + +There is also a seq_release_private() which passes the contents of the +seq_file private field to kfree() before releasing the structure. + +The final step is the creation of the /proc file itself. In the example +code, that is done in the initialization code in the usual way: + + static int ct_init(void) + { + struct proc_dir_entry *entry; + + entry = create_proc_entry("sequence", 0, NULL); + if (entry) + entry->proc_fops = &ct_file_ops; + return 0; + } + + module_init(ct_init); + +And that is pretty much it. + + +seq_list + +If your file will be iterating through a linked list, you may find these +routines useful: + + struct list_head *seq_list_start(struct list_head *head, + loff_t pos); + struct list_head *seq_list_start_head(struct list_head *head, + loff_t pos); + struct list_head *seq_list_next(void *v, struct list_head *head, + loff_t *ppos); + +These helpers will interpret pos as a position within the list and iterate +accordingly. Your start() and next() functions need only invoke the +seq_list_* helpers with a pointer to the appropriate list_head structure. + + +The extra-simple version + +For extremely simple virtual files, there is an even easier interface. A +module can define only the show() function, which should create all the +output that the virtual file will contain. The file's open() method then +calls: + + int single_open(struct file *file, + int (*show)(struct seq_file *m, void *p), + void *data); + +When output time comes, the show() function will be called once. The data +value given to single_open() can be found in the private field of the +seq_file structure. When using single_open(), the programmer should use +single_release() instead of seq_release() in the file_operations structure +to avoid a memory leak. diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index 8da724e2a0ff..54630095aa3c 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt @@ -2,6 +2,9 @@ GPIO Interfaces This provides an overview of GPIO access conventions on Linux. +These calls use the gpio_* naming prefix. No other calls should use that +prefix, or the related __gpio_* prefix. + What is a GPIO? =============== @@ -69,11 +72,13 @@ in this document, but drivers acting as clients to the GPIO interface must not care how it's implemented.) That said, if the convention is supported on their platform, drivers should -use it when possible. Platforms should declare GENERIC_GPIO support in -Kconfig (boolean true), which multi-platform drivers can depend on when -using the include file: +use it when possible. Platforms must declare GENERIC_GPIO support in their +Kconfig (boolean true), and provide an <asm/gpio.h> file. Drivers that can't +work without standard GPIO calls should have Kconfig entries which depend +on GENERIC_GPIO. The GPIO calls are available, either as "real code" or as +optimized-away stubs, when drivers use the include file: - #include <asm/gpio.h> + #include <linux/gpio.h> If you stick to this convention then it'll be easier for other developers to see what your code is doing, and help maintain it. @@ -316,6 +321,9 @@ pulldowns integrated on some platforms. Not all platforms support them, or support them in the same way; and any given board might use external pullups (or pulldowns) so that the on-chip ones should not be used. (When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.) +Likewise drive strength (2 mA vs 20 mA) and voltage (1.8V vs 3.3V) is a +platform-specific issue, as are models like (not) having a one-to-one +correspondence between configurable pins and GPIOs. There are other system-specific mechanisms that are not specified here, like the aforementioned options for input de-glitching and wire-OR output. diff --git a/Documentation/hrtimers/highres.txt b/Documentation/hrtimers/highres.txt index ce0e9a91e157..a73ecf5b4bdb 100644 --- a/Documentation/hrtimers/highres.txt +++ b/Documentation/hrtimers/highres.txt @@ -98,7 +98,7 @@ System-level global event devices are used for the Linux periodic tick. Per-CPU event devices are used to provide local CPU functionality such as process accounting, profiling, and high resolution timers. -The management layer assignes one or more of the folliwing functions to a clock +The management layer assigns one or more of the following functions to a clock event device: - system global periodic tick (jiffies update) - cpu local update_process_times diff --git a/Documentation/hw_random.txt b/Documentation/hw_random.txt index bb58c36b5845..690f52550c80 100644 --- a/Documentation/hw_random.txt +++ b/Documentation/hw_random.txt @@ -1,33 +1,26 @@ - Hardware driver for Intel/AMD/VIA Random Number Generators (RNG) - Copyright 2000,2001 Jeff Garzik <jgarzik@pobox.com> - Copyright 2000,2001 Philipp Rumpf <prumpf@mandrakesoft.com> - Introduction: - The hw_random device driver is software that makes use of a + The hw_random framework is software that makes use of a special hardware feature on your CPU or motherboard, - a Random Number Generator (RNG). + a Random Number Generator (RNG). The software has two parts: + a core providing the /dev/hw_random character device and its + sysfs support, plus a hardware-specific driver that plugs + into that core. - In order to make effective use of this device driver, you + To make the most effective use of these mechanisms, you should download the support software as well. Download the latest version of the "rng-tools" package from the hw_random driver's official Web site: http://sourceforge.net/projects/gkernel/ -About the Intel RNG hardware, from the firmware hub datasheet: - - The Firmware Hub integrates a Random Number Generator (RNG) - using thermal noise generated from inherently random quantum - mechanical properties of silicon. When not generating new random - bits the RNG circuitry will enter a low power state. Intel will - provide a binary software driver to give third party software - access to our RNG for use as a security feature. At this time, - the RNG is only to be used with a system in an OS-present state. + Those tools use /dev/hw_random to fill the kernel entropy pool, + which is used internally and exported by the /dev/urandom and + /dev/random special files. Theory of operation: - Character driver. Using the standard open() + CHARACTER DEVICE. Using the standard open() and read() system calls, you can read random data from the hardware RNG device. This data is NOT CHECKED by any fitness tests, and could potentially be bogus (if the @@ -36,9 +29,37 @@ Theory of operation: a security-conscious person would run fitness tests on the data before assuming it is truly random. - /dev/hwrandom is char device major 10, minor 183. + The rng-tools package uses such tests in "rngd", and lets you + run them by hand with a "rngtest" utility. + + /dev/hw_random is char device major 10, minor 183. + + CLASS DEVICE. There is a /sys/class/misc/hw_random node with + two unique attributes, "rng_available" and "rng_current". The + "rng_available" attribute lists the hardware-specific drivers + available, while "rng_current" lists the one which is currently + connected to /dev/hw_random. If your system has more than one + RNG available, you may change the one used by writing a name from + the list in "rng_available" into "rng_current". + +========================================================================== + + Hardware driver for Intel/AMD/VIA Random Number Generators (RNG) + Copyright 2000,2001 Jeff Garzik <jgarzik@pobox.com> + Copyright 2000,2001 Philipp Rumpf <prumpf@mandrakesoft.com> + + +About the Intel RNG hardware, from the firmware hub datasheet: + + The Firmware Hub integrates a Random Number Generator (RNG) + using thermal noise generated from inherently random quantum + mechanical properties of silicon. When not generating new random + bits the RNG circuitry will enter a low power state. Intel will + provide a binary software driver to give third party software + access to our RNG for use as a security feature. At this time, + the RNG is only to be used with a system in an OS-present state. -Driver notes: +Intel RNG Driver notes: * FIXME: support poll(2) diff --git a/Documentation/hwmon/adt7473 b/Documentation/hwmon/adt7473 new file mode 100644 index 000000000000..22d8b19046ab --- /dev/null +++ b/Documentation/hwmon/adt7473 @@ -0,0 +1,79 @@ +Kernel driver adt7473 +====================== + +Supported chips: + * Analog Devices ADT7473 + Prefix: 'adt7473' + Addresses scanned: I2C 0x2C, 0x2D, 0x2E + Datasheet: Publicly available at the Analog Devices website + +Author: Darrick J. Wong + +Description +----------- + +This driver implements support for the Analog Devices ADT7473 chip family. + +The LM85 uses the 2-wire interface compatible with the SMBUS 2.0 +specification. Using an analog to digital converter it measures three (3) +temperatures and two (2) voltages. It has three (3) 16-bit counters for +measuring fan speed. There are three (3) PWM outputs that can be used +to control fan speed. + +A sophisticated control system for the PWM outputs is designed into the +LM85 that allows fan speed to be adjusted automatically based on any of the +three temperature sensors. Each PWM output is individually adjustable and +programmable. Once configured, the ADT7473 will adjust the PWM outputs in +response to the measured temperatures without further host intervention. +This feature can also be disabled for manual control of the PWM's. + +Each of the measured inputs (voltage, temperature, fan speed) has +corresponding high/low limit values. The ADT7473 will signal an ALARM if +any measured value exceeds either limit. + +The ADT7473 samples all inputs continuously. The driver will not read +the registers more often than once every other second. Further, +configuration data is only read once per minute. + +Special Features +---------------- + +The ADT7473 have a 10-bit ADC and can therefore measure temperatures +with 0.25 degC resolution. Temperature readings can be configured either +for twos complement format or "Offset 64" format, wherein 63 is subtracted +from the raw value to get the temperature value. + +The Analog Devices datasheet is very detailed and describes a procedure for +determining an optimal configuration for the automatic PWM control. + +Hardware Configurations +----------------------- + +The ADT7473 chips have an optional SMBALERT output that can be used to +signal the chipset in case a limit is exceeded or the temperature sensors +fail. Individual sensor interrupts can be masked so they won't trigger +SMBALERT. The SMBALERT output if configured replaces the PWM2 function. + +Configuration Notes +------------------- + +Besides standard interfaces driver adds the following: + +* PWM Control + +* pwm#_auto_point1_pwm and pwm#_auto_point1_temp and +* pwm#_auto_point2_pwm and pwm#_auto_point2_temp - + +point1: Set the pwm speed at a lower temperature bound. +point2: Set the pwm speed at a higher temperature bound. + +The ADT7473 will scale the pwm between the lower and higher pwm speed when +the temperature is between the two temperature boundaries. PWM values range +from 0 (off) to 255 (full speed). + +Notes +----- + +The NVIDIA binary driver presents an ADT7473 chip via an on-card i2c bus. +Unfortunately, they fail to set the i2c adapter class, so this driver may +fail to find the chip until the nvidia driver is patched. diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp index 170bf862437b..dbbe6c7025b0 100644 --- a/Documentation/hwmon/coretemp +++ b/Documentation/hwmon/coretemp @@ -4,9 +4,10 @@ Kernel driver coretemp Supported chips: * All Intel Core family Prefix: 'coretemp' - CPUID: family 0x6, models 0xe, 0xf, 0x16 + CPUID: family 0x6, models 0xe, 0xf, 0x16, 0x17 Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide + http://softwarecommunity.intel.com/Wiki/Mobility/720.htm Author: Rudolf Marek @@ -25,7 +26,8 @@ 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 - Core temperature (in millidegrees Celsius). -temp1_crit - Maximum junction temperature (in millidegrees Celsius). +temp1_max - All cooling devices should be turned on (on Core2). +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. temp1_label - Contains string "Core X", where X is processor diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 3bd958360159..c31e0291e167 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -12,8 +12,9 @@ Supported adapters: * Intel 82801G (ICH7) * Intel 631xESB/632xESB (ESB2) * Intel 82801H (ICH8) - * Intel ICH9 + * Intel 82801I (ICH9) * Intel Tolapai + * Intel ICH10 Datasheets: Publicly available at the Intel website Authors: diff --git a/Documentation/i386/IO-APIC.txt b/Documentation/i386/IO-APIC.txt index 435e69e6e9aa..30b4c714fbe1 100644 --- a/Documentation/i386/IO-APIC.txt +++ b/Documentation/i386/IO-APIC.txt @@ -1,12 +1,14 @@ Most (all) Intel-MP compliant SMP boards have the so-called 'IO-APIC', -which is an enhanced interrupt controller, it enables us to route -hardware interrupts to multiple CPUs, or to CPU groups. +which is an enhanced interrupt controller. It enables us to route +hardware interrupts to multiple CPUs, or to CPU groups. Without an +IO-APIC, interrupts from hardware will be delivered only to the +CPU which boots the operating system (usually CPU#0). Linux supports all variants of compliant SMP boards, including ones with -multiple IO-APICs. (multiple IO-APICs are used in high-end servers to -distribute IRQ load further). +multiple IO-APICs. Multiple IO-APICs are used in high-end servers to +distribute IRQ load further. -There are (a few) known breakages in certain older boards, which bugs are +There are (a few) known breakages in certain older boards, such bugs are usually worked around by the kernel. If your MP-compliant SMP board does not boot Linux, then consult the linux-smp mailing list archives first. @@ -28,18 +30,18 @@ If your box boots fine with enabled IO-APIC IRQs, then your hell:~> <---------------------------- -some interrupts are still listed as 'XT PIC', but this is not a problem, +Some interrupts are still listed as 'XT PIC', but this is not a problem; none of those IRQ sources is performance-critical. -in the unlikely case that your board does not create a working mp-table, +In the unlikely case that your board does not create a working mp-table, you can use the pirq= boot parameter to 'hand-construct' IRQ entries. This -is nontrivial though and cannot be automated. One sample /etc/lilo.conf +is non-trivial though and cannot be automated. One sample /etc/lilo.conf entry: append="pirq=15,11,10" -the actual numbers depend on your system, on your PCI cards and on their +The actual numbers depend on your system, on your PCI cards and on their PCI slot position. Usually PCI slots are 'daisy chained' before they are connected to the PCI chipset IRQ routing facility (the incoming PIRQ1-4 lines): @@ -54,7 +56,7 @@ lines): PIRQ1 ----| |- `----| |- `----| |- `----| |--------| | `-' `-' `-' `-' `-' -every PCI card emits a PCI IRQ, which can be INTA,INTB,INTC,INTD: +Every PCI card emits a PCI IRQ, which can be INTA, INTB, INTC or INTD: ,-. INTD--| | @@ -68,7 +70,7 @@ every PCI card emits a PCI IRQ, which can be INTA,INTB,INTC,INTD: These INTA-D PCI IRQs are always 'local to the card', their real meaning depends on which slot they are in. If you look at the daisy chaining diagram, -a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ2 of +a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ4 of the PCI chipset. Most cards issue INTA, this creates optimal distribution between the PIRQ lines. (distributing IRQ sources properly is not a necessity, PCI IRQs can be shared at will, but it's a good for performance @@ -95,21 +97,21 @@ card (IRQ11) in Slot3, and have Slot1 empty: [value '0' is a generic 'placeholder', reserved for empty (or non-IRQ emitting) slots.] -generally, it's always possible to find out the correct pirq= settings, just +Generally, it's always possible to find out the correct pirq= settings, just permute all IRQ numbers properly ... it will take some time though. An 'incorrect' pirq line will cause the booting process to hang, or a device -won't function properly (if it's inserted as eg. a module). +won't function properly (e.g. if it's inserted as a module). -If you have 2 PCI buses, then you can use up to 8 pirq values. Although such +If you have 2 PCI buses, then you can use up to 8 pirq values, although such boards tend to have a good configuration. Be prepared that it might happen that you need some strange pirq line: append="pirq=0,0,0,0,0,0,9,11" -use smart try-and-err techniques to find out the correct pirq line ... +Use smart trial-and-error techniques to find out the correct pirq line ... -good luck and mail to linux-smp@vger.kernel.org or +Good luck and mail to linux-smp@vger.kernel.org or linux-kernel@vger.kernel.org if you have any problems that are not covered by this document. diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt index fc49b79bc1ab..2eb16100bb3f 100644 --- a/Documentation/i386/boot.txt +++ b/Documentation/i386/boot.txt @@ -170,6 +170,8 @@ Offset Proto Name Meaning 0238/4 2.06+ cmdline_size Maximum size of the kernel command line 023C/4 2.07+ hardware_subarch Hardware subarchitecture 0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data +0248/4 2.08+ payload_offset Offset of kernel payload +024C/4 2.08+ payload_length Length of kernel payload (1) For backwards compatibility, if the setup_sects field contains 0, the real value is 4. @@ -512,6 +514,32 @@ Protocol: 2.07+ A pointer to data that is specific to hardware subarch +Field name: payload_offset +Type: read +Offset/size: 0x248/4 +Protocol: 2.08+ + + If non-zero then this field contains the offset from the end of the + real-mode code to the payload. + + The payload may be compressed. The format of both the compressed and + uncompressed data should be determined using the standard magic + numbers. Currently only gzip compressed ELF is used. + +Field name: payload_length +Type: read +Offset/size: 0x24c/4 +Protocol: 2.08+ + + The length of the payload. + +**** THE IMAGE CHECKSUM + +From boot protocol version 2.08 onwards the CRC-32 is calculated over +the entire file using the characteristic polynomial 0x04C11DB7 and an +initial remainder of 0xffffffff. The checksum is appended to the +file; therefore the CRC of the file up to the limit specified in the +syssize field of the header is always 0. **** THE KERNEL COMMAND LINE diff --git a/Documentation/ide/00-INDEX b/Documentation/ide/00-INDEX new file mode 100644 index 000000000000..d6b778842b75 --- /dev/null +++ b/Documentation/ide/00-INDEX @@ -0,0 +1,12 @@ +00-INDEX + - this file +ChangeLog.ide-cd.1994-2004 + - ide-cd changelog +ChangeLog.ide-floppy.1996-2002 + - ide-floppy changelog +ChangeLog.ide-tape.1995-2002 + - ide-tape changelog +ide-tape.txt + - info on the IDE ATAPI streaming tape driver +ide.txt + - important info for users of ATA devices (IDE/EIDE disks and CD-ROMS). diff --git a/Documentation/ide.txt b/Documentation/ide/ide.txt index 94e2e3b9e77f..818676aad45a 100644 --- a/Documentation/ide.txt +++ b/Documentation/ide/ide.txt @@ -3,11 +3,11 @@ ============================================================================== - + The hdparm utility can be used to control various IDE features on a running system. It is packaged separately. Please Look for it on popular linux FTP sites. - + *** IMPORTANT NOTICES: BUGGY IDE CHIPSETS CAN CORRUPT DATA!! @@ -51,7 +51,7 @@ Common pitfalls: ================================================================================ -This is the multiple IDE interface driver, as evolved from hd.c. +This is the multiple IDE interface driver, as evolved from hd.c. It supports up to 9 IDE interfaces per default, on one or more IRQs (usually 14 & 15). There can be up to two drives per interface, as per the ATA-6 spec. @@ -105,7 +105,7 @@ Drives are normally found by auto-probing and/or examining the CMOS/BIOS data. For really weird situations, the apparent (fdisk) geometry can also be specified on the kernel "command line" using LILO. The format of such lines is: - hdx=cyls,heads,sects,wpcom,irq + hdx=cyls,heads,sects or hdx=cdrom where hdx can be any of hda through hdh, Three values are required @@ -214,26 +214,19 @@ driver using the "options=" keyword to insmod, while replacing any ',' with Summary of ide driver parameters for kernel command line -------------------------------------------------------- - "hdx=" is recognized for all "x" from "a" to "h", such as "hdc". - - "idex=" is recognized for all "x" from "0" to "3", such as "ide1". + "hdx=" is recognized for all "x" from "a" to "u", such as "hdc". + + "idex=" is recognized for all "x" from "0" to "9", such as "ide1". "hdx=noprobe" : drive may be present, but do not probe for it - + "hdx=none" : drive is NOT present, ignore cmos and do not probe - - "hdx=nowerr" : ignore the WRERR_STAT bit on this drive - - "hdx=cdrom" : drive is present, and is a cdrom drive - - "hdx=cyl,head,sect" : disk drive is present, with specified geometry - "hdx=remap" : remap access of sector 0 to sector 1 (for EZDrive) + "hdx=nowerr" : ignore the WRERR_STAT bit on this drive - "hdx=remap63" : remap the drive: add 63 to all sector numbers - (for DM OnTrack) + "hdx=cdrom" : drive is present, and is a cdrom drive - "idex=noautotune" : driver will NOT attempt to tune interface speed + "hdx=cyl,head,sect" : disk drive is present, with specified geometry "hdx=autotune" : driver will attempt to tune interface speed to the fastest PIO mode supported, @@ -244,10 +237,6 @@ Summary of ide driver parameters for kernel command line "hdx=nodma" : disallow DMA - "hdx=scsi" : the return of the ide-scsi flag, this is useful for - allowing ide-floppy, ide-tape, and ide-cdrom|writers - to use ide-scsi emulation on a device specific option. - "idebus=xx" : inform IDE driver of VESA/PCI bus speed in MHz, where "xx" is between 20 and 66 inclusive, used when tuning chipset PIO modes. @@ -258,12 +247,10 @@ Summary of ide driver parameters for kernel command line As for VLB, it is safest to not specify it. Bigger values are safer than smaller ones. - "idex=noprobe" : do not attempt to access/use this interface - "idex=base" : probe for an interface at the addr specified, where "base" is usually 0x1f0 or 0x170 and "ctl" is assumed to be "base"+0x206 - + "idex=base,ctl" : specify both base and ctl "idex=base,ctl,irq" : specify base, ctl, and irq number @@ -274,7 +261,7 @@ Summary of ide driver parameters for kernel command line to take effect. "idex=four" : four drives on idex and ide(x^1) share same ports - + "idex=reset" : reset interface after probe "idex=ata66" : informs the interface that it has an 80c cable @@ -284,10 +271,6 @@ Summary of ide driver parameters for kernel command line "ide=reverse" : formerly called to pci sub-system, but now local. -The following are valid ONLY on ide0, which usually corresponds -to the first ATA interface found on the particular host, and the defaults for -the base,ctl ports must not be altered. - "ide=doubler" : probe/support IDE doublers on Amiga There may be more options than shown -- use the source, Luke! @@ -309,53 +292,6 @@ are detected automatically). ================================================================================ -IDE ATAPI streaming tape driver -------------------------------- - -This driver is a part of the Linux ide driver and works in co-operation -with linux/drivers/block/ide.c. - -The driver, in co-operation with ide.c, basically traverses the -request-list for the block device interface. The character device -interface, on the other hand, creates new requests, adds them -to the request-list of the block device, and waits for their completion. - -Pipelined operation mode is now supported on both reads and writes. - -The block device major and minor numbers are determined from the -tape's relative position in the ide interfaces, as explained in ide.c. - -The character device interface consists of the following devices: - - ht0 major 37, minor 0 first IDE tape, rewind on close. - ht1 major 37, minor 1 second IDE tape, rewind on close. - ... - nht0 major 37, minor 128 first IDE tape, no rewind on close. - nht1 major 37, minor 129 second IDE tape, no rewind on close. - ... - -Run /dev/MAKEDEV to create the above entries. - -The general magnetic tape commands compatible interface, as defined by -include/linux/mtio.h, is accessible through the character device. - -General ide driver configuration options, such as the interrupt-unmask -flag, can be configured by issuing an ioctl to the block device interface, -as any other ide device. - -Our own ide-tape ioctl's can be issued to either the block device or -the character device interface. - -Maximal throughput with minimal bus load will usually be achieved in the -following scenario: - - 1. ide-tape is operating in the pipelined operation mode. - 2. No buffering is performed by the user backup program. - - - -================================================================================ - Some Terminology ---------------- IDE = Integrated Drive Electronics, meaning that each drive has a built-in diff --git a/Documentation/input/notifier.txt b/Documentation/input/notifier.txt new file mode 100644 index 000000000000..95172ca6f3d2 --- /dev/null +++ b/Documentation/input/notifier.txt @@ -0,0 +1,52 @@ +Keyboard notifier + +One can use register_keyboard_notifier to get called back on keyboard +events (see kbd_keycode() function for details). The passed structure is +keyboard_notifier_param: + +- 'vc' always provide the VC for which the keyboard event applies; +- 'down' is 1 for a key press event, 0 for a key release; +- 'shift' is the current modifier state, mask bit indexes are KG_*; +- 'value' depends on the type of event. + +- KBD_KEYCODE events are always sent before other events, value is the keycode. +- KBD_UNBOUND_KEYCODE events are sent if the keycode is not bound to a keysym. + value is the keycode. +- KBD_UNICODE events are sent if the keycode -> keysym translation produced a + unicode character. value is the unicode value. +- KBD_KEYSYM events are sent if the keycode -> keysym translation produced a + non-unicode character. value is the keysym. +- KBD_POST_KEYSYM events are sent after the treatment of non-unicode keysyms. + That permits one to inspect the resulting LEDs for instance. + +For each kind of event but the last, the callback may return NOTIFY_STOP in +order to "eat" the event: the notify loop is stopped and the keyboard event is +dropped. + +In a rough C snippet, we have: + +kbd_keycode(keycode) { + ... + params.value = keycode; + if (notifier_call_chain(KBD_KEYCODE,¶ms) == NOTIFY_STOP) + || !bound) { + notifier_call_chain(KBD_UNBOUND_KEYCODE,¶ms); + return; + } + + if (unicode) { + param.value = unicode; + if (notifier_call_chain(KBD_UNICODE,¶ms) == NOTIFY_STOP) + return; + emit unicode; + return; + } + + params.value = keysym; + if (notifier_call_chain(KBD_KEYSYM,¶ms) == NOTIFY_STOP) + return; + apply keysym; + notifier_call_chain(KBD_POST_KEYSYM,¶ms); +} + +NOTE: This notifier is usually called from interrupt context. diff --git a/Documentation/ja_JP/stable_kernel_rules.txt b/Documentation/ja_JP/stable_kernel_rules.txt index 17d87519e468..b3ffe870de33 100644 --- a/Documentation/ja_JP/stable_kernel_rules.txt +++ b/Documentation/ja_JP/stable_kernel_rules.txt @@ -11,69 +11,69 @@ comment or update of this file, please try to update Original(English) file at first. ================================== -ããã¯ã +これは、 linux-2.6.24/Documentation/stable_kernel_rules.txt -ã®å訳ã§ãã +の和訳です。 -翻訳å£ä½ï¼ JF ããã¸ã§ã¯ã < http://www.linux.or.jp/JF/ > -翻訳æ¥ï¼ 2007/12/30 -翻訳è
ï¼ Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com> -æ ¡æ£è
ï¼ æ¦äºä¼¸å
ããã<takei at webmasters dot gr dot jp> - ããããã (Seiji Kaneko) <skaneko at a2 dot mbn dot or dot jp> - å°æ é
å
¸ãã (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp> - éå£ãã (Kenji Noguchi) <tokyo246 at gmail dot com> - ç¥å®®ä¿¡å¤ªéãã <jin at libjingu dot jp> +翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ > +翻訳日： 2007/12/30 +翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com> +校正者： 武井伸光さん、<takei at webmasters dot gr dot jp> + かねこさん (Seiji Kaneko) <skaneko at a2 dot mbn dot or dot jp> + 小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp> + 野口さん (Kenji Noguchi) <tokyo246 at gmail dot com> + 神宮信太郎さん <jin at libjingu dot jp> ================================== -ãã£ã¨ç¥ãããã£ã Linux 2.6 -stable ãªãªã¼ã¹ã®å
¨ã¦ +ずっと知りたかった Linux 2.6 -stable リリースの全て -"-stable" ããªã¼ã«ã©ã®ãããªç¨®é¡ã®ããããåãå
¥ããããããã©ã®ãã㪠-ãã®ãåãå
¥ããããªãããã«ã¤ãã¦ã®è¦å- +"-stable" ツリーにどのような種類のパッチが受け入れられるか、どのような +ものが受け入れられないか、についての規則- - - æããã«æ£ããããã¹ãããã¦ãããã®ã§ãªããã°ãªããªãã - - æè(å¤æ´è¡ã®åå¾)ãå«ã㦠100 è¡ãã大ããã¦ã¯ãããªãã - - ãã ä¸åã®ãã¨ã ããä¿®æ£ãã¦ããã¹ãã - - çãæ©ã¾ãã¦ããæ¬ç©ã®ãã°ãä¿®æ£ããªããã°ãªããªãã("ããã¯ãã°ã§ - ãããããããªãã..." ã®ãããªãã®ã§ã¯ãªã) - - ãã«ãã¨ã©ã¼(CONFIG_BROKENã«ãªã£ã¦ãããã®ãé¤ã), oops, ãã³ã°ããã¼ - ã¿ç ´å£ãç¾å®ã®ã»ãã¥ãªãã£åé¡ããã®ä» "ãããããã¯ãã¡ã ã"ã¨ãã - ãããªãã®ãä¿®æ£ããªããã°ãªããªããçãè¨ãã°ãé大ãªåé¡ã - - ã©ã®ããã«ç«¶åç¶æ
ãçºçãããã®èª¬æãä¸ç·ã«æ¸ããã¦ããªãéãã - "çè«çã«ã¯ç«¶åç¶æ
ã«ãªã"ãããªãã®ã¯ä¸å¯ã - - ãããªãäºç´°ãªä¿®æ£ãå«ãããã¨ã¯ã§ããªãã(ã¹ãã«ã®ä¿®æ£ã空ç½ã®ã¯ãªã¼ - ã³ã¢ãããªã©) - - 対å¿ãããµãã·ã¹ãã ã¡ã³ãããåãå
¥ãããã®ã§ãªããã°ãªããªãã - - Documentation/SubmittingPatches ã®è¦åã«å¾ã£ããã®ã§ãªããã°ãªããªãã + - 明らかに正しく、テストされているものでなければならない。 + - 文脈(変更行の前後)を含めて 100 行より大きくてはいけない。 + - ただ一個のことだけを修正しているべき。 + - 皆を悩ませている本物のバグを修正しなければならない。("これはバグで + あるかもしれないが..." のようなものではない) + - ビルドエラー(CONFIG_BROKENになっているものを除く), oops, ハング、デー + タ破壊、現実のセキュリティ問題、その他 "ああ、これはダメだね"という + ようなものを修正しなければならない。短く言えば、重大な問題。 + - どのように競合状態が発生するかの説明も一緒に書かれていない限り、 + "理論的には競合状態になる"ようなものは不可。 + - いかなる些細な修正も含めることはできない。(スペルの修正、空白のクリー + ンアップなど) + - 対応するサブシステムメンテナが受け入れたものでなければならない。 + - Documentation/SubmittingPatches の規則に従ったものでなければならない。 --stable ããªã¼ã«ããããéä»ããæç¶ã- +-stable ツリーにパッチを送付する手続き- - - ä¸è¨ã®è¦åã«å¾ã£ã¦ãããã確èªããå¾ã«ãstable@kernel.org ã«ããã - ãéãã - - éä¿¡è
ã¯ãããããã¥ã¼ã«åãä»ããããéã«ã¯ ACK ããå´ä¸ãããå ´å - ã«ã¯ NAK ãåãåãããã®åå¿ã¯éçºè
ãã¡ã®ã¹ã±ã¸ã¥ã¼ã«ã«ãã£ã¦ãæ° - æ¥ãããå ´åãããã - - ããåãåããããããããã¯ä»ã®éçºè
ãã¡ã®ã¬ãã¥ã¼ã®ããã« - -stable ãã¥ã¼ã«è¿½å ãããã - - ã»ãã¥ãªãã£ãããã¯ãã®ã¨ã¤ãªã¢ã¹ (stable@kernel.org) ã«éãããã¹ - ãã§ã¯ãªãã代ããã« security@kernel.org ã®ã¢ãã¬ã¹ã«éãããã + - 上記の規則に従っているかを確認した後に、stable@kernel.org にパッチ + を送る。 + - 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合 + には NAK を受け取る。この反応は開発者たちのスケジュールによって、数 + 日かかる場合がある。 + - もし受け取られたら、パッチは他の開発者たちのレビューのために + -stable キューに追加される。 + - セキュリティパッチはこのエイリアス (stable@kernel.org) に送られるべ + きではなく、代わりに security@kernel.org のアドレスに送られる。 -ã¬ãã¥ã¼ãµã¤ã¯ã«- +レビューサイクル- - - -stable ã¡ã³ãããã¬ãã¥ã¼ãµã¤ã¯ã«ã決ããã¨ãããããã¯ã¬ãã¥ã¼å§ - å¡ä¼ã¨ããããå½±é¿ããé åã®ã¡ã³ãã(æä¾è
ããã®é åã®ã¡ã³ããã§ç¡ - ãéã)ã«éãããlinux-kernel ã¡ã¼ãªã³ã°ãªã¹ãã«CCãããã - - ã¬ãã¥ã¼å§å¡ä¼ã¯ 48æéã®éã« ACK ã NAK ãåºãã - - ããããããå§å¡ä¼ã®ã¡ã³ãããå´ä¸ããããã¡ã³ããéãã¡ã³ããæ°ä» - ããªãã£ãåé¡ãæã¡ããããlinux-kernel ã¡ã³ãããããã«ç°è°ãå±ã - ãå ´åã«ã¯ããããã¯ãã¥ã¼ããåé¤ãããã - - ã¬ãã¥ã¼ãµã¤ã¯ã«ã®æå¾ã«ãACK ãåãããããã¯ææ°ã® -stable ãªãªã¼ - ã¹ã«è¿½å ããããã®å¾ã«æ°ãã -stable ãªãªã¼ã¹ãè¡ãããã - - ã»ãã¥ãªãã£ãããã¯ãé常ã®ã¬ãã¥ã¼ãµã¤ã¯ã«ãéãããã»ãã¥ãªã㣠- ã«ã¼ãã«ãã¼ã ããç´æ¥ -stable ããªã¼ã«åãä»ããããã - ãã®æç¶ãã®è©³ç´°ã«ã¤ãã¦ã¯ kernel security ãã¼ã ã«åãåããããã¨ã + - -stable メンテナがレビューサイクルを決めるとき、パッチはレビュー委 + 員会とパッチが影響する領域のメンテナ(提供者がその領域のメンテナで無 + い限り)に送られ、linux-kernel メーリングリストにCCされる。 + - レビュー委員会は 48時間の間に ACK か NAK を出す。 + - もしパッチが委員会のメンバから却下されるか、メンテナ達やメンバが気付 + かなかった問題が持ちあがり、linux-kernel メンバがパッチに異議を唱え + た場合には、パッチはキューから削除される。 + - レビューサイクルの最後に、ACK を受けたパッチは最新の -stable リリー + スに追加され、その後に新しい -stable リリースが行われる。 + - セキュリティパッチは、通常のレビューサイクルを通らず、セキュリティ + カーネルチームから直接 -stable ツリーに受け付けられる。 + この手続きの詳細については kernel security チームに問い合わせること。 -ã¬ãã¥ã¼å§å¡ä¼- +レビュー委員会- - - ãã®å§å¡ä¼ã¯ããã®ã¿ã¹ã¯ã«ã¤ãã¦æ´»åããå¤ãã®ãã©ã³ãã£ã¢ã¨ãå°æ°ã® - éãã©ã³ãã£ã¢ã®ã«ã¼ãã«éçºè
éã§æ§æããã¦ããã + - この委員会は、このタスクについて活動する多くのボランティアと、少数の + 非ボランティアのカーネル開発者達で構成されている。 diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index a4fc7fc21439..c867f506366d 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -138,7 +138,7 @@ and is between 256 and 4096 characters. It is defined in the file strict -- Be less tolerant of platforms that are not strictly ACPI specification compliant. - See also Documentation/pm.txt, pci=noacpi + See also Documentation/power/pm.txt, pci=noacpi acpi_apic_instance= [ACPI, IOAPIC] Format: <int> @@ -170,16 +170,8 @@ and is between 256 and 4096 characters. It is defined in the file acpi_irq_isa= [HW,ACPI] If irq_balance, mark listed IRQs used by ISA Format: <irq>,<irq>... - acpi_new_pts_ordering [HW,ACPI] - Enforce the ACPI 2.0 ordering of the _PTS control - method wrt putting devices into low power states - default: pre ACPI 2.0 ordering of _PTS - acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT - acpi_no_initrd_override [KNL,ACPI] - Disable loading custom ACPI tables from the initramfs - acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS Format: To spoof as Windows 98: ="Microsoft Windows" @@ -383,6 +375,10 @@ and is between 256 and 4096 characters. It is defined in the file ccw_timeout_log [S390] See Documentation/s390/CommonIO for details. + cgroup_disable= [KNL] Disable a particular controller + Format: {name of the controller(s) to disable} + {Currently supported controllers - "memory"} + checkreqprot [SELINUX] Set initial checkreqprot flag value. Format: { "0" | "1" } See security/selinux/Kconfig help text. @@ -712,7 +708,7 @@ and is between 256 and 4096 characters. It is defined in the file Format: <cyl>,<head>,<sect> hd?= [HW] (E)IDE subsystem - hd?lun= See Documentation/ide.txt. + hd?lun= See Documentation/ide/ide.txt. highmem=nn[KMG] [KNL,BOOT] forces the highmem zone to have an exact size of <nn>. This works even on boxes that have no @@ -735,6 +731,8 @@ and is between 256 and 4096 characters. It is defined in the file (Don't attempt to blink the leds) i8042.noaux [HW] Don't check for auxiliary (== mouse) port i8042.nokbd [HW] Don't check/create keyboard port + i8042.noloop [HW] Disable the AUX Loopback command while probing + for the AUX port i8042.nomux [HW] Don't check presence of an active multiplexing controller i8042.nopnp [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX @@ -766,14 +764,14 @@ and is between 256 and 4096 characters. It is defined in the file ide= [HW] (E)IDE subsystem Format: ide=nodma or ide=doubler or ide=reverse - See Documentation/ide.txt. + See Documentation/ide/ide.txt. ide?= [HW] (E)IDE subsystem Format: ide?=noprobe or chipset specific parameters. - See Documentation/ide.txt. + See Documentation/ide/ide.txt. idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed - See Documentation/ide.txt. + See Documentation/ide/ide.txt. idle= [X86] Format: idle=poll or idle=mwait @@ -814,6 +812,19 @@ and is between 256 and 4096 characters. It is defined in the file inttest= [IA64] + iommu= [x86] + off + force + noforce + biomerge + panic + nopanic + merge + nomerge + forcesac + soft + + intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option off Disable intel iommu driver. @@ -846,7 +857,7 @@ and is between 256 and 4096 characters. It is defined in the file arch/alpha/kernel/core_marvel.c. ip= [IP_PNP] - See Documentation/nfsroot.txt. + See Documentation/filesystems/nfsroot.txt. ip2= [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards See comment before ip2_setup() in @@ -930,6 +941,11 @@ and is between 256 and 4096 characters. It is defined in the file kstack=N [X86-32,X86-64] Print N words from the kernel stack in oops dumps. + kgdboc= [HW] kgdb over consoles. + Requires a tty driver that supports console polling. + (only serial suported for now) + Format: <serial_device>[,baud] + l2cr= [PPC] lapic [X86-32,APIC] Enable the local APIC even if BIOS @@ -950,6 +966,41 @@ and is between 256 and 4096 characters. It is defined in the file when set. Format: <int> + libata.force= [LIBATA] Force configurations. The format is comma + separated list of "[ID:]VAL" where ID is + PORT[:DEVICE]. PORT and DEVICE are decimal numbers + matching port, link or device. Basically, it matches + the ATA ID string printed on console by libata. If + the whole ID part is omitted, the last PORT and DEVICE + values are used. If ID hasn't been specified yet, the + configuration applies to all ports, links and devices. + + If only DEVICE is omitted, the parameter applies to + the port and all links and devices behind it. DEVICE + number of 0 either selects the first device or the + first fan-out link behind PMP device. It does not + select the host link. DEVICE number of 15 selects the + host link and device attached to it. + + The VAL specifies the configuration to force. As long + as there's no ambiguity shortcut notation is allowed. + For example, both 1.5 and 1.5G would work for 1.5Gbps. + The following configurations can be forced. + + * Cable type: 40c, 80c, short40c, unk, ign or sata. + Any ID with matching PORT is used. + + * SATA link speed limit: 1.5Gbps or 3.0Gbps. + + * Transfer mode: pio[0-7], mwdma[0-4] and udma[0-7]. + udma[/][16,25,33,44,66,100,133] notation is also + allowed. + + * [no]ncq: Turn on or off NCQ. + + If there are multiple matching configurations changing + the same attribute, the last one is used. + load_ramdisk= [RAM] List of ramdisks to load from floppy See Documentation/ramdisk.txt. @@ -1056,8 +1107,6 @@ and is between 256 and 4096 characters. It is defined in the file [SCSI] Maximum number of LUNs received. Should be between 1 and 16384. - mca-pentium [BUGS=X86-32] - mcatest= [IA-64] mce [X86-32] Machine Check Exception @@ -1098,6 +1147,15 @@ and is between 256 and 4096 characters. It is defined in the file memmap=nn[KMG]$ss[KMG] [KNL,ACPI] Mark specific memory as reserved. Region of memory to be used, from ss to ss+nn. + Example: Exclude memory from 0x18690000-0x1869ffff + memmap=64K$0x18690000 + or + memmap=0x10000$0x18690000 + + memtest= [KNL,X86_64] Enable memtest + Format: <integer> + range: 0,4 : pattern number + default : 0 <disable> meye.*= [HW] Set MotionEye Camera parameters See Documentation/video4linux/meye.txt. @@ -1163,10 +1221,10 @@ and is between 256 and 4096 characters. It is defined in the file file if at all. nfsaddrs= [NFS] - See Documentation/nfsroot.txt. + See Documentation/filesystems/nfsroot.txt. nfsroot= [NFS] nfs root filesystem for disk-less boxes. - See Documentation/nfsroot.txt. + See Documentation/filesystems/nfsroot.txt. nfs.callback_tcpport= [NFS] set the TCP port on which the NFSv4 callback diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index 30c101761d0d..be89f393274f 100644 --- a/Documentation/kprobes.txt +++ b/Documentation/kprobes.txt @@ -92,9 +92,8 @@ handler has run. Up to MAX_STACK_SIZE bytes are copied -- e.g., 64 bytes on i386. Note that the probed function's args may be passed on the stack -or in registers (e.g., for x86_64 or for an i386 fastcall function). -The jprobe will work in either case, so long as the handler's -prototype matches that of the probed function. +or in registers. The jprobe will work in either case, so long as the +handler's prototype matches that of the probed function. 1.3 Return Probes @@ -193,7 +192,8 @@ code mapping. The Kprobes API includes a "register" function and an "unregister" function for each type of probe. Here are terse, mini-man-page specifications for these functions and the associated probe handlers -that you'll write. See the latter half of this document for examples. +that you'll write. See the files in the samples/kprobes/ sub-directory +for examples. 4.1 register_kprobe @@ -270,9 +270,9 @@ Kprobes runs the handler whose address is jp->entry. The handler should have the same arg list and return type as the probed function; and just before it returns, it must call jprobe_return(). (The handler never actually returns, since jprobe_return() returns -control to Kprobes.) If the probed function is declared asmlinkage, -fastcall, or anything else that affects how args are passed, the -handler's declaration must match. +control to Kprobes.) If the probed function is declared asmlinkage +or anything else that affects how args are passed, the handler's +declaration must match. register_jprobe() returns 0 on success, or a negative errno otherwise. @@ -421,249 +421,15 @@ e. Watchpoint probes (which fire on data references). 8. Kprobes Example -Here's a sample kernel module showing the use of kprobes to dump a -stack trace and selected i386 registers when do_fork() is called. ------ cut here ----- -/*kprobe_example.c*/ -#include <linux/kernel.h> -#include <linux/module.h> -#include <linux/kprobes.h> -#include <linux/sched.h> - -/*For each probe you need to allocate a kprobe structure*/ -static struct kprobe kp; - -/*kprobe pre_handler: called just before the probed instruction is executed*/ -int handler_pre(struct kprobe *p, struct pt_regs *regs) -{ - printk("pre_handler: p->addr=0x%p, eip=%lx, eflags=0x%lx\n", - p->addr, regs->eip, regs->eflags); - dump_stack(); - return 0; -} - -/*kprobe post_handler: called after the probed instruction is executed*/ -void handler_post(struct kprobe *p, struct pt_regs *regs, unsigned long flags) -{ - printk("post_handler: p->addr=0x%p, eflags=0x%lx\n", - p->addr, regs->eflags); -} - -/* fault_handler: this is called if an exception is generated for any - * instruction within the pre- or post-handler, or when Kprobes - * single-steps the probed instruction. - */ -int handler_fault(struct kprobe *p, struct pt_regs *regs, int trapnr) -{ - printk("fault_handler: p->addr=0x%p, trap #%dn", - p->addr, trapnr); - /* Return 0 because we don't handle the fault. */ - return 0; -} - -static int __init kprobe_init(void) -{ - int ret; - kp.pre_handler = handler_pre; - kp.post_handler = handler_post; - kp.fault_handler = handler_fault; - kp.symbol_name = "do_fork"; - - ret = register_kprobe(&kp); - if (ret < 0) { - printk("register_kprobe failed, returned %d\n", ret); - return ret; - } - printk("kprobe registered\n"); - return 0; -} - -static void __exit kprobe_exit(void) -{ - unregister_kprobe(&kp); - printk("kprobe unregistered\n"); -} - -module_init(kprobe_init) -module_exit(kprobe_exit) -MODULE_LICENSE("GPL"); ------ cut here ----- - -You can build the kernel module, kprobe-example.ko, using the following -Makefile: ------ cut here ----- -obj-m := kprobe-example.o -KDIR := /lib/modules/$(shell uname -r)/build -PWD := $(shell pwd) -default: - $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules -clean: - rm -f *.mod.c *.ko *.o ------ cut here ----- - -$ make -$ su - -... -# insmod kprobe-example.ko - -You will see the trace data in /var/log/messages and on the console -whenever do_fork() is invoked to create a new process. +See samples/kprobes/kprobe_example.c 9. Jprobes Example -Here's a sample kernel module showing the use of jprobes to dump -the arguments of do_fork(). ------ cut here ----- -/*jprobe-example.c */ -#include <linux/kernel.h> -#include <linux/module.h> -#include <linux/fs.h> -#include <linux/uio.h> -#include <linux/kprobes.h> - -/* - * Jumper probe for do_fork. - * Mirror principle enables access to arguments of the probed routine - * from the probe handler. - */ - -/* Proxy routine having the same arguments as actual do_fork() routine */ -long jdo_fork(unsigned long clone_flags, unsigned long stack_start, - struct pt_regs *regs, unsigned long stack_size, - int __user * parent_tidptr, int __user * child_tidptr) -{ - printk("jprobe: clone_flags=0x%lx, stack_size=0x%lx, regs=0x%p\n", - clone_flags, stack_size, regs); - /* Always end with a call to jprobe_return(). */ - jprobe_return(); - /*NOTREACHED*/ - return 0; -} - -static struct jprobe my_jprobe = { - .entry = jdo_fork -}; - -static int __init jprobe_init(void) -{ - int ret; - my_jprobe.kp.symbol_name = "do_fork"; - - if ((ret = register_jprobe(&my_jprobe)) <0) { - printk("register_jprobe failed, returned %d\n", ret); - return -1; - } - printk("Planted jprobe at %p, handler addr %p\n", - my_jprobe.kp.addr, my_jprobe.entry); - return 0; -} - -static void __exit jprobe_exit(void) -{ - unregister_jprobe(&my_jprobe); - printk("jprobe unregistered\n"); -} - -module_init(jprobe_init) -module_exit(jprobe_exit) -MODULE_LICENSE("GPL"); ------ cut here ----- - -Build and insert the kernel module as shown in the above kprobe -example. You will see the trace data in /var/log/messages and on -the console whenever do_fork() is invoked to create a new process. -(Some messages may be suppressed if syslogd is configured to -eliminate duplicate messages.) +See samples/kprobes/jprobe_example.c 10. Kretprobes Example -Here's a sample kernel module showing the use of return probes to -report failed calls to sys_open(). ------ cut here ----- -/*kretprobe-example.c*/ -#include <linux/kernel.h> -#include <linux/module.h> -#include <linux/kprobes.h> -#include <linux/ktime.h> - -/* per-instance private data */ -struct my_data { - ktime_t entry_stamp; -}; - -static const char *probed_func = "sys_open"; - -/* Timestamp function entry. */ -static int entry_handler(struct kretprobe_instance *ri, struct pt_regs *regs) -{ - struct my_data *data; - - if(!current->mm) - return 1; /* skip kernel threads */ - - data = (struct my_data *)ri->data; - data->entry_stamp = ktime_get(); - return 0; -} - -/* If the probed function failed, log the return value and duration. - * Duration may turn out to be zero consistently, depending upon the - * granularity of time accounting on the platform. */ -static int return_handler(struct kretprobe_instance *ri, struct pt_regs *regs) -{ - int retval = regs_return_value(regs); - struct my_data *data = (struct my_data *)ri->data; - s64 delta; - ktime_t now; - - if (retval < 0) { - now = ktime_get(); - delta = ktime_to_ns(ktime_sub(now, data->entry_stamp)); - printk("%s: return val = %d (duration = %lld ns)\n", - probed_func, retval, delta); - } - return 0; -} - -static struct kretprobe my_kretprobe = { - .handler = return_handler, - .entry_handler = entry_handler, - .data_size = sizeof(struct my_data), - .maxactive = 20, /* probe up to 20 instances concurrently */ -}; - -static int __init kretprobe_init(void) -{ - int ret; - my_kretprobe.kp.symbol_name = (char *)probed_func; - - if ((ret = register_kretprobe(&my_kretprobe)) < 0) { - printk("register_kretprobe failed, returned %d\n", ret); - return -1; - } - printk("Kretprobe active on %s\n", my_kretprobe.kp.symbol_name); - return 0; -} - -static void __exit kretprobe_exit(void) -{ - unregister_kretprobe(&my_kretprobe); - printk("kretprobe unregistered\n"); - /* nmissed > 0 suggests that maxactive was set too low. */ - printk("Missed probing %d instances of %s\n", - my_kretprobe.nmissed, probed_func); -} - -module_init(kretprobe_init) -module_exit(kretprobe_exit) -MODULE_LICENSE("GPL"); ------ cut here ----- - -Build and insert the kernel module as shown in the above kprobe -example. You will see the trace data in /var/log/messages and on the -console whenever sys_open() returns a negative value. (Some messages -may be suppressed if syslogd is configured to eliminate duplicate -messages.) +See samples/kprobes/kretprobe_example.c For additional information on Kprobes, refer to the following URLs: http://www-106.ibm.com/developerworks/library/l-kprobes.html?ca=dgr-lnxw42Kprobe diff --git a/Documentation/laptops/00-INDEX b/Documentation/laptops/00-INDEX index 729c2c062e10..ee5692b26dd4 100644 --- a/Documentation/laptops/00-INDEX +++ b/Documentation/laptops/00-INDEX @@ -2,6 +2,8 @@ - This file acer-wmi.txt - information on the Acer Laptop WMI Extras driver. +laptop-mode.txt + - how to conserve battery power using laptop-mode. sony-laptop.txt - Sony Notebook Control Driver (SNC) Readme. sonypi.txt diff --git a/Documentation/laptops/acer-wmi.txt b/Documentation/laptops/acer-wmi.txt index b06696329cff..23df051dbf69 100644 --- a/Documentation/laptops/acer-wmi.txt +++ b/Documentation/laptops/acer-wmi.txt @@ -48,7 +48,7 @@ DSDT. To send me the DSDT, as root/sudo: -cat /sys/firmware/acpi/DSDT > dsdt +cat /sys/firmware/acpi/tables/DSDT > dsdt And send me the resulting 'dsdt' file. @@ -169,7 +169,7 @@ can be added to acer-wmi. The LED is exposed through the LED subsystem, and can be found in: -/sys/devices/platform/acer-wmi/leds/acer-mail:green/ +/sys/devices/platform/acer-wmi/leds/acer-wmi::mail/ The mail LED is autodetected, so if you don't have one, the LED device won't be registered. diff --git a/Documentation/laptop-mode.txt b/Documentation/laptops/laptop-mode.txt index eeedee11c8c2..eeedee11c8c2 100644 --- a/Documentation/laptop-mode.txt +++ b/Documentation/laptops/laptop-mode.txt diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 6c2477754a2a..76cb428435da 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -160,7 +160,7 @@ Hot keys procfs: /proc/acpi/ibm/hotkey sysfs device attribute: hotkey_* -In a ThinkPad, the ACPI HKEY handler is responsible for comunicating +In a ThinkPad, the ACPI HKEY handler is responsible for communicating some important events and also keyboard hot key presses to the operating system. Enabling the hotkey functionality of thinkpad-acpi signals the firmware that such a driver is present, and modifies how the ThinkPad @@ -193,7 +193,7 @@ Not all bits in the mask can be modified. Not all bits that can be modified do anything. Not all hot keys can be individually controlled by the mask. Some models do not support the mask at all, and in those models, hot keys cannot be controlled individually. The behaviour of -the mask is, therefore, higly dependent on the ThinkPad model. +the mask is, therefore, highly dependent on the ThinkPad model. Note that unmasking some keys prevents their default behavior. For example, if Fn+F5 is unmasked, that key will no longer enable/disable @@ -288,7 +288,7 @@ sysfs notes: in ACPI event mode, volume up/down/mute are reported as separate events, but this behaviour may be corrected in future releases of this driver, in which case the - ThinkPad volume mixer user interface semanthics will be + ThinkPad volume mixer user interface semantics will be enforced. hotkey_poll_freq: @@ -306,13 +306,20 @@ sysfs notes: The recommended polling frequency is 10Hz. hotkey_radio_sw: - if the ThinkPad has a hardware radio switch, this + If the ThinkPad has a hardware radio switch, this attribute will read 0 if the switch is in the "radios - disabled" postition, and 1 if the switch is in the + disabled" position, and 1 if the switch is in the "radios enabled" position. This attribute has poll()/select() support. + hotkey_tablet_mode: + If the ThinkPad has tablet capabilities, this attribute + will read 0 if the ThinkPad is in normal mode, and + 1 if the ThinkPad is in tablet mode. + + This attribute has poll()/select() support. + hotkey_report_mode: Returns the state of the procfs ACPI event report mode filter for hot keys. If it is set to 1 (the default), @@ -339,7 +346,7 @@ sysfs notes: wakeup_hotunplug_complete: Set to 1 if the system was waken up because of an undock or bay ejection request, and that request - was sucessfully completed. At this point, it might + was successfully completed. At this point, it might be useful to send the system back to sleep, at the user's choice. Refer to HKEY events 0x4003 and 0x3003, below. @@ -392,7 +399,7 @@ event code Key Notes Lenovo: battery 0x1004 0x03 FN+F4 Sleep button (ACPI sleep button - semanthics, i.e. sleep-to-RAM). + semantics, i.e. sleep-to-RAM). It is always generate some kind of event, either the hot key event or a ACPI sleep button @@ -403,12 +410,12 @@ event code Key Notes time passes. 0x1005 0x04 FN+F5 Radio. Enables/disables - the internal BlueTooth hardware + the internal Bluetooth hardware and W-WAN card if left in control of the firmware. Does not affect the WLAN card. Should be used to turn on/off all - radios (bluetooth+W-WAN+WLAN), + radios (Bluetooth+W-WAN+WLAN), really. 0x1006 0x05 FN+F6 - @@ -417,7 +424,7 @@ event code Key Notes Do you feel lucky today? 0x1008 0x07 FN+F8 IBM: toggle screen expand - Lenovo: configure ultranav + Lenovo: configure UltraNav 0x1009 0x08 FN+F9 - .. .. .. @@ -447,7 +454,7 @@ event code Key Notes 0x1011 0x10 FN+END Brightness down. See brightness up for details. -0x1012 0x11 FN+PGUP Thinklight toggle. This key is +0x1012 0x11 FN+PGUP ThinkLight toggle. This key is always handled by the firmware, even when unmasked. @@ -469,7 +476,7 @@ event code Key Notes key is always handled by the firmware, even when unmasked. -0x1018 0x17 THINKPAD Thinkpad/Access IBM/Lenovo key +0x1018 0x17 THINKPAD ThinkPad/Access IBM/Lenovo key 0x1019 0x18 unknown .. .. .. @@ -488,9 +495,17 @@ If a key is mapped to KEY_UNKNOWN, it generates an input event that includes an scan code. If a key is mapped to anything else, it will generate input device EV_KEY events. +In addition to the EV_KEY events, thinkpad-acpi may also issue EV_SW +events for switches: + +SW_RADIO T60 and later hardare rfkill rocker switch +SW_TABLET_MODE Tablet ThinkPads HKEY events 0x5009 and 0x500A + Non hot-key ACPI HKEY event map: 0x5001 Lid closed 0x5002 Lid opened +0x5009 Tablet swivel: switched to tablet mode +0x500A Tablet swivel: switched to normal mode 0x7000 Radio Switch may have changed state The above events are not propagated by the driver, except for legacy @@ -505,9 +520,7 @@ The above events are never propagated by the driver. 0x3003 Bay ejection (see 0x2x05) complete, can sleep again 0x4003 Undocked (see 0x2x04), can sleep again -0x5009 Tablet swivel: switched to tablet mode -0x500A Tablet swivel: switched to normal mode -0x500B Tablet pen insterted into its storage bay +0x500B Tablet pen inserted into its storage bay 0x500C Tablet pen removed from its storage bay 0x5010 Brightness level changed (newer Lenovo BIOSes) @@ -539,7 +552,7 @@ sysfs (it is read-only). If the hotkey_report_mode module parameter is set to 1 or 2, it cannot be changed later through sysfs (any writes will return -EPERM to signal that hotkey_report_mode was locked. On 2.6.23 and later, where -hotkey_report_mode cannot be changed at all, writes will return -EACES). +hotkey_report_mode cannot be changed at all, writes will return -EACCES). hotkey_report_mode set to 1 makes the driver export through the procfs ACPI event interface all hot key presses (which are *also* sent to the @@ -584,7 +597,7 @@ Sysfs notes: 0: disables Bluetooth / Bluetooth is disabled 1: enables Bluetooth / Bluetooth is enabled. - Note: this interface will be probably be superseeded by the + Note: this interface will be probably be superseded by the generic rfkill class, so it is NOT to be considered stable yet. Video output control -- /proc/acpi/ibm/video @@ -791,12 +804,12 @@ on the X40 (tpb is the ThinkPad Buttons utility): 1 - Related to "Volume up" key press 2 - Related to "Mute on" key press 3 - Related to "Access IBM" key press - 4 - Related to "LCD brightness up" key pess + 4 - Related to "LCD brightness up" key press 5 - Related to "LCD brightness down" key press 11 - Related to "toggle screen expansion" key press/function 12 - Related to "ThinkLight on" 13 - Related to "ThinkLight off" - 14 - Related to "ThinkLight" key press (toggle thinklight) + 14 - Related to "ThinkLight" key press (toggle ThinkLight) The cmos command interface is prone to firmware split-brain problems, as in newer ThinkPads it is just a compatibility layer. Do not use it, it is @@ -1024,7 +1037,7 @@ There are two interfaces to the firmware for direct brightness control, EC and CMOS. To select which one should be used, use the brightness_mode module parameter: brightness_mode=1 selects EC mode, brightness_mode=2 selects CMOS mode, brightness_mode=3 selects both EC -and CMOS. The driver tries to autodetect which interface to use. +and CMOS. The driver tries to auto-detect which interface to use. When display backlight brightness controls are available through the standard ACPI interface, it is best to use it instead of this direct @@ -1266,8 +1279,8 @@ experimental=1 parameter when loading the module. This feature shows the presence and current state of a W-WAN (Sierra Wireless EV-DO) device. -It was tested on a Lenovo Thinkpad X60. It should probably work on other -Thinkpad models which come with this module installed. +It was tested on a Lenovo ThinkPad X60. It should probably work on other +ThinkPad models which come with this module installed. Procfs notes: @@ -1286,7 +1299,7 @@ Sysfs notes: 0: disables WWAN card / WWAN card is disabled 1: enables WWAN card / WWAN card is enabled. - Note: this interface will be probably be superseeded by the + Note: this interface will be probably be superseded by the generic rfkill class, so it is NOT to be considered stable yet. Multiple Commands, Module Parameters @@ -1309,7 +1322,7 @@ Enabling debugging output The module takes a debug parameter which can be used to selectively enable various classes of debugging output, for example: - modprobe ibm_acpi debug=0xffff + modprobe thinkpad_acpi debug=0xffff will enable all debugging output classes. It takes a bitmask, so to enable more than one output class, just add their values. @@ -1356,7 +1369,7 @@ Sysfs interface changelog: NVRAM is compiled out by the user because it is unneeded/undesired in the first place). 0x020101: Marker for thinkpad-acpi with hot key NVRAM polling - and proper hotkey_mask semanthics (version 8 of the + and proper hotkey_mask semantics (version 8 of the NVRAM polling patch). Some development snapshots of 0.18 had an earlier version that did strange things to hotkey_mask. diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c index 0f23d67f958f..4c1fc65a8b3d 100644 --- a/Documentation/lguest/lguest.c +++ b/Documentation/lguest/lguest.c @@ -1,7 +1,7 @@ /*P:100 This is the Launcher code, a simple program which lays out the - * "physical" memory for the new Guest by mapping the kernel image and the - * virtual devices, then reads repeatedly from /dev/lguest to run the Guest. -:*/ + * "physical" memory for the new Guest by mapping the kernel image and + * the virtual devices, then opens /dev/lguest to tell the kernel + * about the Guest and control it. :*/ #define _LARGEFILE64_SOURCE #define _GNU_SOURCE #include <stdio.h> @@ -43,7 +43,7 @@ #include "linux/virtio_console.h" #include "linux/virtio_ring.h" #include "asm-x86/bootparam.h" -/*L:110 We can ignore the 38 include files we need for this program, but I do +/*L:110 We can ignore the 39 include files we need for this program, but I do * want to draw attention to the use of kernel-style types. * * As Linus said, "C is a Spartan language, and so should your naming be." I @@ -320,7 +320,7 @@ static unsigned long map_elf(int elf_fd, const Elf32_Ehdr *ehdr) err(1, "Reading program headers"); /* Try all the headers: there are usually only three. A read-only one, - * a read-write one, and a "note" section which isn't loadable. */ + * a read-write one, and a "note" section which we don't load. */ for (i = 0; i < ehdr->e_phnum; i++) { /* If this isn't a loadable segment, we ignore it */ if (phdr[i].p_type != PT_LOAD) @@ -387,7 +387,7 @@ static unsigned long load_kernel(int fd) if (memcmp(hdr.e_ident, ELFMAG, SELFMAG) == 0) return map_elf(fd, &hdr); - /* Otherwise we assume it's a bzImage, and try to unpack it */ + /* Otherwise we assume it's a bzImage, and try to load it. */ return load_bzimage(fd); } @@ -433,12 +433,12 @@ static unsigned long load_initrd(const char *name, unsigned long mem) return len; } -/* Once we know how much memory we have, we can construct simple linear page +/* Once we know how much memory we have we can construct simple linear page * tables which set virtual == physical which will get the Guest far enough * into the boot to create its own. * * We lay them out of the way, just below the initrd (which is why we need to - * know its size). */ + * know its size here). */ static unsigned long setup_pagetables(unsigned long mem, unsigned long initrd_size) { @@ -486,9 +486,12 @@ static void concat(char *dst, char *args[]) unsigned int i, len = 0; for (i = 0; args[i]; i++) { + if (i) { + strcat(dst+len, " "); + len++; + } strcpy(dst+len, args[i]); - strcat(dst+len, " "); - len += strlen(args[i]) + 1; + len += strlen(args[i]); } /* In case it's empty. */ dst[len] = '\0'; @@ -847,7 +850,8 @@ static void handle_console_output(int fd, struct virtqueue *vq) * * Handling output for network is also simple: we get all the output buffers * and write them (ignoring the first element) to this device's file descriptor - * (stdout). */ + * (/dev/net/tun). + */ static void handle_net_output(int fd, struct virtqueue *vq) { unsigned int head, out, in; @@ -921,7 +925,7 @@ static void enable_fd(int fd, struct virtqueue *vq) write(waker_fd, &vq->dev->fd, sizeof(vq->dev->fd)); } -/* Resetting a device is fairly easy. */ +/* When the Guest asks us to reset a device, it's is fairly easy. */ static void reset_device(struct device *dev) { struct virtqueue *vq; @@ -1000,8 +1004,8 @@ static void handle_input(int fd) if (select(devices.max_infd+1, &fds, NULL, NULL, &poll) == 0) break; - /* Otherwise, call the device(s) which have readable - * file descriptors and a method of handling them. */ + /* Otherwise, call the device(s) which have readable file + * descriptors and a method of handling them. */ for (i = devices.dev; i; i = i->next) { if (i->handle_input && FD_ISSET(i->fd, &fds)) { int dev_fd; @@ -1012,8 +1016,7 @@ static void handle_input(int fd) * should no longer service it. Networking and * console do this when there's no input * buffers to deliver into. Console also uses - * it when it discovers that stdin is - * closed. */ + * it when it discovers that stdin is closed. */ FD_CLR(i->fd, &devices.infds); /* Tell waker to ignore it too, by sending a * negative fd number (-1, since 0 is a valid @@ -1030,7 +1033,8 @@ static void handle_input(int fd) * * All devices need a descriptor so the Guest knows it exists, and a "struct * device" so the Launcher can keep track of it. We have common helper - * routines to allocate and manage them. */ + * routines to allocate and manage them. + */ /* The layout of the device page is a "struct lguest_device_desc" followed by a * number of virtqueue descriptors, then two sets of feature bits, then an @@ -1075,7 +1079,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs, struct virtqueue **i, *vq = malloc(sizeof(*vq)); void *p; - /* First we need some pages for this virtqueue. */ + /* First we need some memory for this virtqueue. */ pages = (vring_size(num_descs, getpagesize()) + getpagesize() - 1) / getpagesize(); p = get_pages(pages); @@ -1119,7 +1123,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs, } /* The first half of the feature bitmask is for us to advertise features. The - * second half if for the Guest to accept features. */ + * second half is for the Guest to accept features. */ static void add_feature(struct device *dev, unsigned bit) { u8 *features = get_feature_bits(dev); @@ -1148,7 +1152,9 @@ static void set_config(struct device *dev, unsigned len, const void *conf) } /* This routine does all the creation and setup of a new device, including - * calling new_dev_desc() to allocate the descriptor and device memory. */ + * calling new_dev_desc() to allocate the descriptor and device memory. + * + * See what I mean about userspace being boring? */ static struct device *new_device(const char *name, u16 type, int fd, bool (*handle_input)(int, struct device *)) { @@ -1380,7 +1386,6 @@ struct vblk_info * Launcher triggers interrupt to Guest. */ int done_fd; }; -/*:*/ /*L:210 * The Disk @@ -1490,7 +1495,10 @@ static int io_thread(void *_dev) while (read(vblk->workpipe[0], &c, 1) == 1) { /* We acknowledge each request immediately to reduce latency, * rather than waiting until we've done them all. I haven't - * measured to see if it makes any difference. */ + * measured to see if it makes any difference. + * + * That would be an interesting test, wouldn't it? You could + * also try having more than one I/O thread. */ while (service_io(dev)) write(vblk->done_fd, &c, 1); } @@ -1498,7 +1506,7 @@ static int io_thread(void *_dev) } /* Now we've seen the I/O thread, we return to the Launcher to see what happens - * when the thread tells us it's completed some I/O. */ + * when that thread tells us it's completed some I/O. */ static bool handle_io_finish(int fd, struct device *dev) { char c; @@ -1570,11 +1578,12 @@ static void setup_block_file(const char *filename) * more work. */ pipe(vblk->workpipe); - /* Create stack for thread and run it */ + /* Create stack for thread and run it. Since stack grows upwards, we + * point the stack pointer to the end of this region. */ stack = malloc(32768); /* SIGCHLD - We dont "wait" for our cloned thread, so prevent it from * becoming a zombie. */ - if (clone(io_thread, stack + 32768, CLONE_VM | SIGCHLD, dev) == -1) + if (clone(io_thread, stack + 32768, CLONE_VM | SIGCHLD, dev) == -1) err(1, "Creating clone"); /* We don't need to keep the I/O thread's end of the pipes open. */ @@ -1584,14 +1593,14 @@ static void setup_block_file(const char *filename) verbose("device %u: virtblock %llu sectors\n", devices.device_num, le64_to_cpu(conf.capacity)); } -/* That's the end of device setup. :*/ +/* That's the end of device setup. */ -/* Reboot */ +/*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */ static void __attribute__((noreturn)) restart_guest(void) { unsigned int i; - /* Closing pipes causes the waker thread and io_threads to die, and + /* Closing pipes causes the Waker thread and io_threads to die, and * closing /dev/lguest cleans up the Guest. Since we don't track all * open fds, we simply close everything beyond stderr. */ for (i = 3; i < FD_SETSIZE; i++) @@ -1600,7 +1609,7 @@ static void __attribute__((noreturn)) restart_guest(void) err(1, "Could not exec %s", main_args[0]); } -/*L:220 Finally we reach the core of the Launcher, which runs the Guest, serves +/*L:220 Finally we reach the core of the Launcher which runs the Guest, serves * its input and output, and finally, lays it to rest. */ static void __attribute__((noreturn)) run_guest(int lguest_fd) { @@ -1641,7 +1650,7 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd) err(1, "Resetting break"); } } -/* +/*L:240 * This is the end of the Launcher. The good news: we are over halfway * through! The bad news: the most fiendish part of the code still lies ahead * of us. @@ -1688,8 +1697,8 @@ int main(int argc, char *argv[]) * device receive input from a file descriptor, we keep an fdset * (infds) and the maximum fd number (max_infd) with the head of the * list. We also keep a pointer to the last device. Finally, we keep - * the next interrupt number to hand out (1: remember that 0 is used by - * the timer). */ + * the next interrupt number to use for devices (1: remember that 0 is + * used by the timer). */ FD_ZERO(&devices.infds); devices.max_infd = -1; devices.lastdev = NULL; @@ -1790,8 +1799,8 @@ int main(int argc, char *argv[]) lguest_fd = tell_kernel(pgdir, start); /* We fork off a child process, which wakes the Launcher whenever one - * of the input file descriptors needs attention. Otherwise we would - * run the Guest until it tries to output something. */ + * of the input file descriptors needs attention. We call this the + * Waker, and we'll cover it in a moment. */ waker_fd = setup_waker(lguest_fd); /* Finally, run the Guest. This doesn't return. */ diff --git a/Documentation/lguest/lguest.txt b/Documentation/lguest/lguest.txt index 722d4e7fbebe..29510dc51510 100644 --- a/Documentation/lguest/lguest.txt +++ b/Documentation/lguest/lguest.txt @@ -1,6 +1,7 @@ -Rusty's Remarkably Unreliable Guide to Lguest - - or, A Young Coder's Illustrated Hypervisor -http://lguest.ozlabs.org + __ + (___()'`; Rusty's Remarkably Unreliable Guide to Lguest + /, /` - or, A Young Coder's Illustrated Hypervisor + \\"--\\ http://lguest.ozlabs.org Lguest is designed to be a minimal hypervisor for the Linux kernel, for Linux developers and users to experiment with virtualization with the @@ -41,12 +42,16 @@ Running Lguest: CONFIG_PHYSICAL_ALIGN=0x100000) "Device Drivers": + "Block devices" + "Virtio block driver (EXPERIMENTAL)" = M/Y "Network device support" "Universal TUN/TAP device driver support" = M/Y - (CONFIG_TUN=m) - "Virtualization" - "Linux hypervisor example code" = M/Y - (CONFIG_LGUEST=m) + "Virtio network driver (EXPERIMENTAL)" = M/Y + (CONFIG_VIRTIO_BLK=m, CONFIG_VIRTIO_NET=m and CONFIG_TUN=m) + + "Virtualization" + "Linux hypervisor example code" = M/Y + (CONFIG_LGUEST=m) - A tool called "lguest" is available in this directory: type "make" to build it. If you didn't build your kernel in-tree, use "make diff --git a/Documentation/mca.txt b/Documentation/mca.txt index aabce4ad90f9..510375d4209a 100644 --- a/Documentation/mca.txt +++ b/Documentation/mca.txt @@ -143,14 +143,7 @@ MCA Device Drivers Currently, there are a number of MCA-specific device drivers. -1) PS/2 ESDI - drivers/block/ps2esdi.c - include/linux/ps2esdi.h - Uses major number 36, and should use /dev files /dev/eda, /dev/edb. - Supports two drives, but only one controller. May use the - command-line args "ed=cyl,head,sec" and "tp720". - -2) PS/2 SCSI +1) PS/2 SCSI drivers/scsi/ibmmca.c drivers/scsi/ibmmca.h The driver for the IBM SCSI subsystem. Includes both integrated @@ -159,25 +152,25 @@ Currently, there are a number of MCA-specific device drivers. machine with a front-panel display (i.e. model 95), you can use "ibmmcascsi=display" to enable a drive activity indicator. -3) 3c523 +2) 3c523 drivers/net/3c523.c drivers/net/3c523.h 3Com 3c523 Etherlink/MC ethernet driver. -4) SMC Ultra/MCA and IBM Adapter/A +3) SMC Ultra/MCA and IBM Adapter/A drivers/net/smc-mca.c drivers/net/smc-mca.h Driver for the MCA version of the SMC Ultra and various other OEM'ed and work-alike cards (Elite, Adapter/A, etc). -5) NE/2 +4) NE/2 driver/net/ne2.c driver/net/ne2.h The NE/2 is the MCA version of the NE2000. This may not work with clones that have a different adapter id than the original NE/2. -6) Future Domain MCS-600/700, OEM'd IBM Fast SCSI Adapter/A and +5) Future Domain MCS-600/700, OEM'd IBM Fast SCSI Adapter/A and Reply Sound Blaster/SCSI (SCSI part) Better support for these cards than the driver for ISA. Supports multiple cards with IRQ sharing. diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 4e17beba2379..1f506f7830ec 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1493,7 +1493,7 @@ explicit lock operations, described later). These include: atomic_dec_and_test(); atomic_sub_and_test(); atomic_add_negative(); - atomic_add_unless(); + atomic_add_unless(); /* when succeeds (returns 1) */ test_and_set_bit(); test_and_clear_bit(); test_and_change_bit(); diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index 02e56d447a8f..c485ee028bd9 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -84,9 +84,6 @@ policy-routing.txt - IP policy-based routing ray_cs.txt - Raylink Wireless LAN card driver info. -sk98lin.txt - - Marvell Yukon Chipset / SysKonnect SK-98xx compliant Gigabit - Ethernet Adapter family driver info skfp.txt - SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info. smc9.txt diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index f1b2de170929..641d2afacffa 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt @@ -281,10 +281,10 @@ solution for a couple of reasons: sa_family_t can_family; int can_ifindex; union { - struct { canid_t rx_id, tx_id; } tp16; - struct { canid_t rx_id, tx_id; } tp20; - struct { canid_t rx_id, tx_id; } mcnet; - struct { canid_t rx_id, tx_id; } isotp; + /* transport protocol class address info (e.g. ISOTP) */ + struct { canid_t rx_id, tx_id; } tp; + + /* reserved for future CAN protocols address information */ } can_addr; }; diff --git a/Documentation/networking/sk98lin.txt b/Documentation/networking/sk98lin.txt deleted file mode 100644 index 8590a954df1d..000000000000 --- a/Documentation/networking/sk98lin.txt +++ /dev/null @@ -1,568 +0,0 @@ -(C)Copyright 1999-2004 Marvell(R). -All rights reserved -=========================================================================== - -sk98lin.txt created 13-Feb-2004 - -Readme File for sk98lin v6.23 -Marvell Yukon/SysKonnect SK-98xx Gigabit Ethernet Adapter family driver for LINUX - -This file contains - 1 Overview - 2 Required Files - 3 Installation - 3.1 Driver Installation - 3.2 Inclusion of adapter at system start - 4 Driver Parameters - 4.1 Per-Port Parameters - 4.2 Adapter Parameters - 5 Large Frame Support - 6 VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad) - 7 Troubleshooting - -=========================================================================== - - -1 Overview -=========== - -The sk98lin driver supports the Marvell Yukon and SysKonnect -SK-98xx/SK-95xx compliant Gigabit Ethernet Adapter on Linux. It has -been tested with Linux on Intel/x86 machines. -*** - - -2 Required Files -================= - -The linux kernel source. -No additional files required. -*** - - -3 Installation -=============== - -It is recommended to download the latest version of the driver from the -SysKonnect web site www.syskonnect.com. If you have downloaded the latest -driver, the Linux kernel has to be patched before the driver can be -installed. For details on how to patch a Linux kernel, refer to the -patch.txt file. - -3.1 Driver Installation ------------------------- - -The following steps describe the actions that are required to install -the driver and to start it manually. These steps should be carried -out for the initial driver setup. Once confirmed to be ok, they can -be included in the system start. - -NOTE 1: To perform the following tasks you need 'root' access. - -NOTE 2: In case of problems, please read the section "Troubleshooting" - below. - -The driver can either be integrated into the kernel or it can be compiled -as a module. Select the appropriate option during the kernel -configuration. - -Compile/use the driver as a module ----------------------------------- -To compile the driver, go to the directory /usr/src/linux and -execute the command "make menuconfig" or "make xconfig" and proceed as -follows: - -To integrate the driver permanently into the kernel, proceed as follows: - -1. Select the menu "Network device support" and then "Ethernet(1000Mbit)" -2. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support" - with (*) -3. Build a new kernel when the configuration of the above options is - finished. -4. Install the new kernel. -5. Reboot your system. - -To use the driver as a module, proceed as follows: - -1. Enable 'loadable module support' in the kernel. -2. For automatic driver start, enable the 'Kernel module loader'. -3. Select the menu "Network device support" and then "Ethernet(1000Mbit)" -4. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support" - with (M) -5. Execute the command "make modules". -6. Execute the command "make modules_install". - The appropriate modules will be installed. -7. Reboot your system. - - -Load the module manually ------------------------- -To load the module manually, proceed as follows: - -1. Enter "modprobe sk98lin". -2. If a Marvell Yukon or SysKonnect SK-98xx adapter is installed in - your computer and you have a /proc file system, execute the command: - "ls /proc/net/sk98lin/" - This should produce an output containing a line with the following - format: - eth0 eth1 ... - which indicates that your adapter has been found and initialized. - - NOTE 1: If you have more than one Marvell Yukon or SysKonnect SK-98xx - adapter installed, the adapters will be listed as 'eth0', - 'eth1', 'eth2', etc. - For each adapter, repeat steps 3 and 4 below. - - NOTE 2: If you have other Ethernet adapters installed, your Marvell - Yukon or SysKonnect SK-98xx adapter will be mapped to the - next available number, e.g. 'eth1'. The mapping is executed - automatically. - The module installation message (displayed either in a system - log file or on the console) prints a line for each adapter - found containing the corresponding 'ethX'. - -3. Select an IP address and assign it to the respective adapter by - entering: - ifconfig eth0 <ip-address> - With this command, the adapter is connected to the Ethernet. - - SK-98xx Gigabit Ethernet Server Adapters: The yellow LED on the adapter - is now active, the link status LED of the primary port is active and - the link status LED of the secondary port (on dual port adapters) is - blinking (if the ports are connected to a switch or hub). - SK-98xx V2.0 Gigabit Ethernet Adapters: The link status LED is active. - In addition, you will receive a status message on the console stating - "ethX: network connection up using port Y" and showing the selected - connection parameters (x stands for the ethernet device number - (0,1,2, etc), y stands for the port name (A or B)). - - NOTE: If you are in doubt about IP addresses, ask your network - administrator for assistance. - -4. Your adapter should now be fully operational. - Use 'ping <otherstation>' to verify the connection to other computers - on your network. -5. To check the adapter configuration view /proc/net/sk98lin/[devicename]. - For example by executing: - "cat /proc/net/sk98lin/eth0" - -Unload the module ------------------ -To stop and unload the driver modules, proceed as follows: - -1. Execute the command "ifconfig eth0 down". -2. Execute the command "rmmod sk98lin". - -3.2 Inclusion of adapter at system start ------------------------------------------ - -Since a large number of different Linux distributions are -available, we are unable to describe a general installation procedure -for the driver module. -Because the driver is now integrated in the kernel, installation should -be easy, using the standard mechanism of your distribution. -Refer to the distribution's manual for installation of ethernet adapters. - -*** - -4 Driver Parameters -==================== - -Parameters can be set at the command line after the module has been -loaded with the command 'modprobe'. -In some distributions, the configuration tools are able to pass parameters -to the driver module. - -If you use the kernel module loader, you can set driver parameters -in the file /etc/modprobe.conf (or /etc/modules.conf in 2.4 or earlier). -To set the driver parameters in this file, proceed as follows: - -1. Insert a line of the form : - options sk98lin ... - For "...", the same syntax is required as described for the command - line parameters of modprobe below. -2. To activate the new parameters, either reboot your computer - or - unload and reload the driver. - The syntax of the driver parameters is: - - modprobe sk98lin parameter=value1[,value2[,value3...]] - - where value1 refers to the first adapter, value2 to the second etc. - -NOTE: All parameters are case sensitive. Write them exactly as shown - below. - -Example: -Suppose you have two adapters. You want to set auto-negotiation -on the first adapter to ON and on the second adapter to OFF. -You also want to set DuplexCapabilities on the first adapter -to FULL, and on the second adapter to HALF. -Then, you must enter: - - modprobe sk98lin AutoNeg_A=On,Off DupCap_A=Full,Half - -NOTE: The number of adapters that can be configured this way is - limited in the driver (file skge.c, constant SK_MAX_CARD_PARAM). - The current limit is 16. If you happen to install - more adapters, adjust this and recompile. - - -4.1 Per-Port Parameters ------------------------- - -These settings are available for each port on the adapter. -In the following description, '?' stands for the port for -which you set the parameter (A or B). - -Speed ------ -Parameter: Speed_? -Values: 10, 100, 1000, Auto -Default: Auto - -This parameter is used to set the speed capabilities. It is only valid -for the SK-98xx V2.0 copper adapters. -Usually, the speed is negotiated between the two ports during link -establishment. If this fails, a port can be forced to a specific setting -with this parameter. - -Auto-Negotiation ----------------- -Parameter: AutoNeg_? -Values: On, Off, Sense -Default: On - -The "Sense"-mode automatically detects whether the link partner supports -auto-negotiation or not. - -Duplex Capabilities -------------------- -Parameter: DupCap_? -Values: Half, Full, Both -Default: Both - -This parameters is only relevant if auto-negotiation for this port is -not set to "Sense". If auto-negotiation is set to "On", all three values -are possible. If it is set to "Off", only "Full" and "Half" are allowed. -This parameter is useful if your link partner does not support all -possible combinations. - -Flow Control ------------- -Parameter: FlowCtrl_? -Values: Sym, SymOrRem, LocSend, None -Default: SymOrRem - -This parameter can be used to set the flow control capabilities the -port reports during auto-negotiation. It can be set for each port -individually. -Possible modes: - -- Sym = Symmetric: both link partners are allowed to send - PAUSE frames - -- SymOrRem = SymmetricOrRemote: both or only remote partner - are allowed to send PAUSE frames - -- LocSend = LocalSend: only local link partner is allowed - to send PAUSE frames - -- None = no link partner is allowed to send PAUSE frames - -NOTE: This parameter is ignored if auto-negotiation is set to "Off". - -Role in Master-Slave-Negotiation (1000Base-T only) --------------------------------------------------- -Parameter: Role_? -Values: Auto, Master, Slave -Default: Auto - -This parameter is only valid for the SK-9821 and SK-9822 adapters. -For two 1000Base-T ports to communicate, one must take the role of the -master (providing timing information), while the other must be the -slave. Usually, this is negotiated between the two ports during link -establishment. If this fails, a port can be forced to a specific setting -with this parameter. - - -4.2 Adapter Parameters ------------------------ - -Connection Type (SK-98xx V2.0 copper adapters only) ---------------- -Parameter: ConType -Values: Auto, 100FD, 100HD, 10FD, 10HD -Default: Auto - -The parameter 'ConType' is a combination of all five per-port parameters -within one single parameter. This simplifies the configuration of both ports -of an adapter card! The different values of this variable reflect the most -meaningful combinations of port parameters. - -The following table shows the values of 'ConType' and the corresponding -combinations of the per-port parameters: - - ConType | DupCap AutoNeg FlowCtrl Role Speed - ----------+------------------------------------------------------ - Auto | Both On SymOrRem Auto Auto - 100FD | Full Off None Auto (ignored) 100 - 100HD | Half Off None Auto (ignored) 100 - 10FD | Full Off None Auto (ignored) 10 - 10HD | Half Off None Auto (ignored) 10 - -Stating any other port parameter together with this 'ConType' variable -will result in a merged configuration of those settings. This due to -the fact, that the per-port parameters (e.g. Speed_? ) have a higher -priority than the combined variable 'ConType'. - -NOTE: This parameter is always used on both ports of the adapter card. - -Interrupt Moderation --------------------- -Parameter: Moderation -Values: None, Static, Dynamic -Default: None - -Interrupt moderation is employed to limit the maximum number of interrupts -the driver has to serve. That is, one or more interrupts (which indicate any -transmit or receive packet to be processed) are queued until the driver -processes them. When queued interrupts are to be served, is determined by the -'IntsPerSec' parameter, which is explained later below. - -Possible modes: - - -- None - No interrupt moderation is applied on the adapter card. - Therefore, each transmit or receive interrupt is served immediately - as soon as it appears on the interrupt line of the adapter card. - - -- Static - Interrupt moderation is applied on the adapter card. - All transmit and receive interrupts are queued until a complete - moderation interval ends. If such a moderation interval ends, all - queued interrupts are processed in one big bunch without any delay. - The term 'static' reflects the fact, that interrupt moderation is - always enabled, regardless how much network load is currently - passing via a particular interface. In addition, the duration of - the moderation interval has a fixed length that never changes while - the driver is operational. - - -- Dynamic - Interrupt moderation might be applied on the adapter card, - depending on the load of the system. If the driver detects that the - system load is too high, the driver tries to shield the system against - too much network load by enabling interrupt moderation. If - at a later - time - the CPU utilization decreases again (or if the network load is - negligible) the interrupt moderation will automatically be disabled. - -Interrupt moderation should be used when the driver has to handle one or more -interfaces with a high network load, which - as a consequence - leads also to a -high CPU utilization. When moderation is applied in such high network load -situations, CPU load might be reduced by 20-30%. - -NOTE: The drawback of using interrupt moderation is an increase of the round- -trip-time (RTT), due to the queueing and serving of interrupts at dedicated -moderation times. - -Interrupts per second ---------------------- -Parameter: IntsPerSec -Values: 30...40000 (interrupts per second) -Default: 2000 - -This parameter is only used if either static or dynamic interrupt moderation -is used on a network adapter card. Using this parameter if no moderation is -applied will lead to no action performed. - -This parameter determines the length of any interrupt moderation interval. -Assuming that static interrupt moderation is to be used, an 'IntsPerSec' -parameter value of 2000 will lead to an interrupt moderation interval of -500 microseconds. - -NOTE: The duration of the moderation interval is to be chosen with care. -At first glance, selecting a very long duration (e.g. only 100 interrupts per -second) seems to be meaningful, but the increase of packet-processing delay -is tremendous. On the other hand, selecting a very short moderation time might -compensate the use of any moderation being applied. - - -Preferred Port --------------- -Parameter: PrefPort -Values: A, B -Default: A - -This is used to force the preferred port to A or B (on dual-port network -adapters). The preferred port is the one that is used if both are detected -as fully functional. - -RLMT Mode (Redundant Link Management Technology) ------------------------------------------------- -Parameter: RlmtMode -Values: CheckLinkState,CheckLocalPort, CheckSeg, DualNet -Default: CheckLinkState - -RLMT monitors the status of the port. If the link of the active port -fails, RLMT switches immediately to the standby link. The virtual link is -maintained as long as at least one 'physical' link is up. - -Possible modes: - - -- CheckLinkState - Check link state only: RLMT uses the link state - reported by the adapter hardware for each individual port to - determine whether a port can be used for all network traffic or - not. - - -- CheckLocalPort - In this mode, RLMT monitors the network path - between the two ports of an adapter by regularly exchanging packets - between them. This mode requires a network configuration in which - the two ports are able to "see" each other (i.e. there must not be - any router between the ports). - - -- CheckSeg - Check local port and segmentation: This mode supports the - same functions as the CheckLocalPort mode and additionally checks - network segmentation between the ports. Therefore, this mode is only - to be used if Gigabit Ethernet switches are installed on the network - that have been configured to use the Spanning Tree protocol. - - -- DualNet - In this mode, ports A and B are used as separate devices. - If you have a dual port adapter, port A will be configured as eth0 - and port B as eth1. Both ports can be used independently with - distinct IP addresses. The preferred port setting is not used. - RLMT is turned off. - -NOTE: RLMT modes CLP and CLPSS are designed to operate in configurations - where a network path between the ports on one adapter exists. - Moreover, they are not designed to work where adapters are connected - back-to-back. -*** - - -5 Large Frame Support -====================== - -The driver supports large frames (also called jumbo frames). Using large -frames can result in an improved throughput if transferring large amounts -of data. -To enable large frames, set the MTU (maximum transfer unit) of the -interface to the desired value (up to 9000), execute the following -command: - ifconfig eth0 mtu 9000 -This will only work if you have two adapters connected back-to-back -or if you use a switch that supports large frames. When using a switch, -it should be configured to allow large frames and auto-negotiation should -be set to OFF. The setting must be configured on all adapters that can be -reached by the large frames. If one adapter is not set to receive large -frames, it will simply drop them. - -You can switch back to the standard ethernet frame size by executing the -following command: - ifconfig eth0 mtu 1500 - -To permanently configure this setting, add a script with the 'ifconfig' -line to the system startup sequence (named something like "S99sk98lin" -in /etc/rc.d/rc2.d). -*** - - -6 VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad) -================================================================== - -The Marvell Yukon/SysKonnect Linux drivers are able to support VLAN and -Link Aggregation according to IEEE standards 802.1, 802.1q, and 802.3ad. -These features are only available after installation of open source -modules available on the Internet: -For VLAN go to: http://www.candelatech.com/~greear/vlan.html -For Link Aggregation go to: http://www.st.rim.or.jp/~yumo - -NOTE: SysKonnect GmbH does not offer any support for these open source - modules and does not take the responsibility for any kind of - failures or problems arising in connection with these modules. - -NOTE: Configuring Link Aggregation on a SysKonnect dual link adapter may - cause problems when unloading the driver. - - -7 Troubleshooting -================== - -If any problems occur during the installation process, check the -following list: - - -Problem: The SK-98xx adapter cannot be found by the driver. -Solution: In /proc/pci search for the following entry: - 'Ethernet controller: SysKonnect SK-98xx ...' - If this entry exists, the SK-98xx or SK-98xx V2.0 adapter has - been found by the system and should be operational. - If this entry does not exist or if the file '/proc/pci' is not - found, there may be a hardware problem or the PCI support may - not be enabled in your kernel. - The adapter can be checked using the diagnostics program which - is available on the SysKonnect web site: - www.syskonnect.com - - Some COMPAQ machines have problems dealing with PCI under Linux. - This problem is described in the 'PCI howto' document - (included in some distributions or available from the - web, e.g. at 'www.linux.org'). - - -Problem: Programs such as 'ifconfig' or 'route' cannot be found or the - error message 'Operation not permitted' is displayed. -Reason: You are not logged in as user 'root'. -Solution: Logout and login as 'root' or change to 'root' via 'su'. - - -Problem: Upon use of the command 'ping <address>' the message - "ping: sendto: Network is unreachable" is displayed. -Reason: Your route is not set correctly. -Solution: If you are using RedHat, you probably forgot to set up the - route in the 'network configuration'. - Check the existing routes with the 'route' command and check - if an entry for 'eth0' exists, and if so, if it is set correctly. - - -Problem: The driver can be started, the adapter is connected to the - network, but you cannot receive or transmit any packets; - e.g. 'ping' does not work. -Reason: There is an incorrect route in your routing table. -Solution: Check the routing table with the command 'route' and read the - manual help pages dealing with routes (enter 'man route'). - -NOTE: Although the 2.2.x kernel versions generate the routing entry - automatically, problems of this kind may occur here as well. We've - come across a situation in which the driver started correctly at - system start, but after the driver has been removed and reloaded, - the route of the adapter's network pointed to the 'dummy0'device - and had to be corrected manually. - - -Problem: Your computer should act as a router between multiple - IP subnetworks (using multiple adapters), but computers in - other subnetworks cannot be reached. -Reason: Either the router's kernel is not configured for IP forwarding - or the routing table and gateway configuration of at least one - computer is not working. - -Problem: Upon driver start, the following error message is displayed: - "eth0: -- ERROR -- - Class: internal Software error - Nr: 0xcc - Msg: SkGeInitPort() cannot init running ports" -Reason: You are using a driver compiled for single processor machines - on a multiprocessor machine with SMP (Symmetric MultiProcessor) - kernel. -Solution: Configure your kernel appropriately and recompile the kernel or - the modules. - - - -If your problem is not listed here, please contact SysKonnect's technical -support for help (linux@syskonnect.de). -When contacting our technical support, please ensure that the following -information is available: -- System Manufacturer and HW Informations (CPU, Memory... ) -- PCI-Boards in your system -- Distribution -- Kernel version -- Driver version -*** - - - -***End of Readme File*** diff --git a/Documentation/networking/tcp.txt b/Documentation/networking/tcp.txt index 0121edc3ba06..7d11bb5dc30a 100644 --- a/Documentation/networking/tcp.txt +++ b/Documentation/networking/tcp.txt @@ -1,7 +1,7 @@ TCP protocol ============ -Last updated: 21 June 2005 +Last updated: 9 February 2008 Contents ======== @@ -52,9 +52,9 @@ research and RFC's before developing new modules. The method that is used to determine which congestion control mechanism is determined by the setting of the sysctl net.ipv4.tcp_congestion_control. The default congestion control will be the last one registered (LIFO); -so if you built everything as modules. the default will be reno. If you -build with the default's from Kconfig, then BIC will be builtin (not a module) -and it will end up the default. +so if you built everything as modules, the default will be reno. If you +build with the defaults from Kconfig, then CUBIC will be builtin (not a +module) and it will end up the default. If you really want a particular default value then you will need to set it with the sysctl. If you use a sysctl, the module will be autoloaded diff --git a/Documentation/nmi_watchdog.txt b/Documentation/nmi_watchdog.txt index c025a4561c10..757c729ee42e 100644 --- a/Documentation/nmi_watchdog.txt +++ b/Documentation/nmi_watchdog.txt @@ -23,8 +23,7 @@ kernel debugging options, such as Kernel Stack Meter or Kernel Tracer, may implicitly disable the NMI watchdog.] For x86-64, the needed APIC is always compiled in, and the NMI watchdog is -always enabled with I/O-APIC mode (nmi_watchdog=1). Currently, local APIC -mode (nmi_watchdog=2) does not work on x86-64. +always enabled with I/O-APIC mode (nmi_watchdog=1). Using local APIC (nmi_watchdog=2) needs the first performance register, so you can't use it for other purposes (such as high precision performance diff --git a/Documentation/pci.txt b/Documentation/pci.txt index 72b20c639596..d2c2e6e2b224 100644 --- a/Documentation/pci.txt +++ b/Documentation/pci.txt @@ -123,7 +123,8 @@ initialization with a pointer to a structure describing the driver The ID table is an array of struct pci_device_id entries ending with an -all-zero entry. Each entry consists of: +all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the preferred +method of declaring the table. Each entry consists of: vendor,device Vendor and device ID to match (or PCI_ANY_ID) @@ -191,7 +192,8 @@ Tips on when/where to use the above attributes: o Do not mark the struct pci_driver. - o The ID table array should be marked __devinitdata. + o The ID table array should be marked __devinitconst; this is done + automatically if the table is declared with DEFINE_PCI_DEVICE_TABLE(). o The probe() and remove() functions should be marked __devinit and __devexit respectively. All initialization functions diff --git a/Documentation/power/00-INDEX b/Documentation/power/00-INDEX index 8db4e41a052d..a55d7f1c836d 100644 --- a/Documentation/power/00-INDEX +++ b/Documentation/power/00-INDEX @@ -14,6 +14,12 @@ notifiers.txt - Registering suspend notifiers in device drivers pci.txt - How the PCI Subsystem Does Power Management +pm.txt + - info on Linux power management support. +pm_qos_interface.txt + - info on Linux PM Quality of Service interface +power_supply_class.txt + - Tells userspace about battery, UPS, AC or DC power supply properties s2ram.txt - How to get suspend to ram working (and debug it when it isn't) states.txt diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index c53d26361919..461e4f1dbec4 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -310,9 +310,12 @@ used with suspend-to-disk: PM_EVENT_SUSPEND -- quiesce the driver and put hardware into a low-power state. When used with system sleep states like "suspend-to-RAM" or "standby", the upcoming resume() call will often be able to rely on - state kept in hardware, or issue system wakeup events. When used - instead with suspend-to-disk, few devices support this capability; - most are completely powered off. + state kept in hardware, or issue system wakeup events. + + PM_EVENT_HIBERNATE -- Put hardware into a low-power state and enable wakeup + events as appropriate. It is only used with hibernation + (suspend-to-disk) and few devices are able to wake up the system from + this state; most are completely powered off. PM_EVENT_FREEZE -- quiesce the driver, but don't necessarily change into any low power mode. A system snapshot is about to be taken, often @@ -329,8 +332,8 @@ used with suspend-to-disk: wakeup events nor DMA are allowed. To enter "standby" (ACPI S1) or "Suspend to RAM" (STR, ACPI S3) states, or -the similarly named APM states, only PM_EVENT_SUSPEND is used; for "Suspend -to Disk" (STD, hibernate, ACPI S4), all of those event codes are used. +the similarly named APM states, only PM_EVENT_SUSPEND is used; the other event +codes are used for hibernation ("Suspend to Disk", STD, ACPI S4). There's also PM_EVENT_ON, a value which never appears as a suspend event but is sometimes used to record the "not suspended" device state. diff --git a/Documentation/pm.txt b/Documentation/power/pm.txt index da8589a0e07d..be841507e43f 100644 --- a/Documentation/pm.txt +++ b/Documentation/power/pm.txt @@ -108,7 +108,7 @@ void pm_unregister_all(pm_callback cback); * EINVAL if the request is not supported * EBUSY if the device is now busy and cannot handle the request * ENOMEM if the device was unable to handle the request due to memory - * + * * Details: The device request callback will be called before the * device/system enters a suspend state (ACPI D1-D3) or * or after the device/system resumes from suspend (ACPI D0). diff --git a/Documentation/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt index 49adb1a33514..49adb1a33514 100644 --- a/Documentation/pm_qos_interface.txt +++ b/Documentation/power/pm_qos_interface.txt diff --git a/Documentation/power_supply_class.txt b/Documentation/power/power_supply_class.txt index a8686e5a6857..a8686e5a6857 100644 --- a/Documentation/power_supply_class.txt +++ b/Documentation/power/power_supply_class.txt diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt index 0eb7c58916de..e05420973698 100644 --- a/Documentation/s390/s390dbf.txt +++ b/Documentation/s390/s390dbf.txt @@ -115,6 +115,27 @@ Return Value: Handle for generated debug area Description: Allocates memory for a debug log Must not be called within an interrupt handler +---------------------------------------------------------------------------- +debug_info_t *debug_register_mode(char *name, int pages, int nr_areas, + int buf_size, mode_t mode, uid_t uid, + gid_t gid); + +Parameter: name: Name of debug log (e.g. used for debugfs entry) + pages: Number of pages, which will be allocated per area + nr_areas: Number of debug areas + buf_size: Size of data area in each debug entry + mode: File mode for debugfs files. E.g. S_IRWXUGO + uid: User ID for debugfs files. Currently only 0 is + supported. + gid: Group ID for debugfs files. Currently only 0 is + supported. + +Return Value: Handle for generated debug area + NULL if register failed + +Description: Allocates memory for a debug log + Must not be called within an interrupt handler + --------------------------------------------------------------------------- void debug_unregister (debug_info_t * id); diff --git a/Documentation/scheduler/00-INDEX b/Documentation/scheduler/00-INDEX index b5f5ca069b2d..fc234d093fbf 100644 --- a/Documentation/scheduler/00-INDEX +++ b/Documentation/scheduler/00-INDEX @@ -12,5 +12,7 @@ sched-domains.txt - information on scheduling domains. sched-nice-design.txt - How and why the scheduler's nice levels are implemented. +sched-rt-group.txt + - real-time group scheduling. sched-stats.txt - information on schedstats (Linux Scheduler Statistics). diff --git a/Documentation/scheduler/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt new file mode 100644 index 000000000000..1c6332f4543c --- /dev/null +++ b/Documentation/scheduler/sched-rt-group.txt @@ -0,0 +1,59 @@ + + +Real-Time group scheduling. + +The problem space: + +In order to schedule multiple groups of realtime tasks each group must +be assigned a fixed portion of the CPU time available. Without a minimum +guarantee a realtime group can obviously fall short. A fuzzy upper limit +is of no use since it cannot be relied upon. Which leaves us with just +the single fixed portion. + +CPU time is divided by means of specifying how much time can be spent +running in a given period. Say a frame fixed realtime renderer must +deliver 25 frames a second, which yields a period of 0.04s. Now say +it will also have to play some music and respond to input, leaving it +with around 80% for the graphics. We can then give this group a runtime +of 0.8 * 0.04s = 0.032s. + +This way the graphics group will have a 0.04s period with a 0.032s runtime +limit. + +Now if the audio thread needs to refill the DMA buffer every 0.005s, but +needs only about 3% CPU time to do so, it can do with a 0.03 * 0.005s += 0.00015s. + + +The Interface: + +system wide: + +/proc/sys/kernel/sched_rt_period_ms +/proc/sys/kernel/sched_rt_runtime_us + +CONFIG_FAIR_USER_SCHED + +/sys/kernel/uids/<uid>/cpu_rt_runtime_us + +or + +CONFIG_FAIR_CGROUP_SCHED + +/cgroup/<cgroup>/cpu.rt_runtime_us + +[ time is specified in us because the interface is s32; this gives an + operating range of ~35m to 1us ] + +The period takes values in [ 1, INT_MAX ], runtime in [ -1, INT_MAX - 1 ]. + +A runtime of -1 specifies runtime == period, ie. no limit. + +New groups get the period from /proc/sys/kernel/sched_rt_period_us and +a runtime of 0. + +Settings are constrained to: + + \Sum_{i} runtime_{i} / global_period <= global_runtime / global_period + +in order to keep the configuration schedulable. diff --git a/Documentation/scheduler/sched-stats.txt b/Documentation/scheduler/sched-stats.txt index 442e14d35dea..01e69404ee5e 100644 --- a/Documentation/scheduler/sched-stats.txt +++ b/Documentation/scheduler/sched-stats.txt @@ -142,7 +142,7 @@ of idleness (idle, busy, and newly idle): /proc/<pid>/schedstat ---------------- -schedstats also adds a new /proc/<pid/schedstat file to include some of +schedstats also adds a new /proc/<pid>/schedstat file to include some of the same information on a per-process level. There are three fields in this file correlating for that process to: 1) time spent on the cpu diff --git a/Documentation/scsi/ChangeLog.arcmsr b/Documentation/scsi/ChangeLog.arcmsr index de2bcacfa870..038a3e6ecaa4 100644 --- a/Documentation/scsi/ChangeLog.arcmsr +++ b/Documentation/scsi/ChangeLog.arcmsr @@ -109,4 +109,10 @@ ** 8.replace pci_alloc_consistent()/pci_free_consistent() with kmalloc()/kfree() in arcmsr_iop_message_xfer() ** 9. fix the release of dma memory for type B in arcmsr_free_ccb_pool() ** 10.fix the arcmsr_polling_hbb_ccbdone() +** 1.20.00.15 02/27/2008 Erich Chen & Nick Cheng +** 1.arcmsr_iop_message_xfer() is called from atomic context under the +** queuecommand scsi_host_template handler. James Bottomley pointed out +** that the current GFP_KERNEL|GFP_DMA flags are wrong: firstly we are in +** atomic context, secondly this memory is not used for DMA. +** Also removed some unneeded casts. Thanks to Daniel Drake <dsd@gentoo.org> ************************************************************************** diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index 8861e47e5a2d..6d5f18143c50 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary @@ -116,6 +116,13 @@ low order bit. So when a chip's timing diagram shows the clock starting low (CPOL=0) and data stabilized for sampling during the trailing clock edge (CPHA=1), that's SPI mode 1. +Note that the clock mode is relevant as soon as the chipselect goes +active. So the master must set the clock to inactive before selecting +a slave, and the slave can tell the chosen polarity by sampling the +clock level when its select line goes active. That's why many devices +support for example both modes 0 and 3: they don't care about polarity, +and alway clock data in/out on rising clock edges. + How do these driver programming interfaces work? ------------------------------------------------ @@ -379,8 +386,14 @@ any more such messages. + when bidirectional reads and writes start ... by how its sequence of spi_transfer requests is arranged; + + which I/O buffers are used ... each spi_transfer wraps a + buffer for each transfer direction, supporting full duplex + (two pointers, maybe the same one in both cases) and half + duplex (one pointer is NULL) transfers; + + optionally defining short delays after transfers ... using - the spi_transfer.delay_usecs setting; + the spi_transfer.delay_usecs setting (this delay can be the + only protocol effect, if the buffer length is zero); + whether the chipselect becomes inactive after a transfer and any delay ... by using the spi_transfer.cs_change flag; diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt index 471e75389778..619699dde593 100644 --- a/Documentation/spinlocks.txt +++ b/Documentation/spinlocks.txt @@ -5,6 +5,28 @@ Please use DEFINE_SPINLOCK()/DEFINE_RWLOCK() or __SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static initialization. +Most of the time, you can simply turn: + + static spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED; + +into: + + static DEFINE_SPINLOCK(xxx_lock); + +Static structure member variables go from: + + struct foo bar { + .lock = SPIN_LOCK_UNLOCKED; + }; + +to: + + struct foo bar { + .lock = __SPIN_LOCK_UNLOCKED(bar.lock); + }; + +Declaration of static rw_locks undergo a similar transformation. + Dynamic initialization, when necessary, may be performed as demonstrated below. diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index c815c5206e84..4cfc78835bc1 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -16,8 +16,9 @@ Rules on what kind of patches are accepted, and which ones are not, into the race can be exploited is also provided. - It cannot contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc). - - It must be accepted by the relevant subsystem maintainer. - It must follow the Documentation/SubmittingPatches rules. + - It or an equivalent fix must already exist in Linus' tree. Quote the + respective commit ID in Linus' tree in your patch submission to -stable. Procedure for submitting patches to the -stable tree: @@ -28,7 +29,9 @@ Procedure for submitting patches to the -stable tree: queue, or a NAK if the patch is rejected. This response might take a few days, according to the developer's schedules. - If accepted, the patch will be added to the -stable queue, for review by - other developers. + other developers and by the relevant subsystem maintainer. + - If the stable@kernel.org address is added to a patch, when it goes into + Linus's tree it will automatically be emailed to the stable team. - Security patches should not be sent to this alias, but instead to the documented security@kernel.org address. diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index dc8801d4e944..276a7e637822 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -29,7 +29,7 @@ show up in /proc/sys/kernel: - java-interpreter [ binfmt_java, obsolete ] - kstack_depth_to_print [ X86 only ] - l2cr [ PPC only ] -- modprobe ==> Documentation/kmod.txt +- modprobe ==> Documentation/debugging-modules.txt - msgmax - msgmnb - msgmni diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index ba9c2da5a8c2..d9f28be75403 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -143,10 +143,10 @@ type Strings which represent the thermal zone type. This is given by thermal zone driver as part of registration. Eg: "ACPI thermal zone" indicates it's a ACPI thermal device RO - Optional + Required temp Current temperature as reported by thermal zone (sensor) - Unit: degree Celsius + Unit: millidegree Celsius RO Required @@ -163,7 +163,7 @@ mode One of the predefined values in [kernel, user] charge of the thermal management. trip_point_[0-*]_temp The temperature above which trip point will be fired - Unit: degree Celsius + Unit: millidegree Celsius RO Optional @@ -193,7 +193,7 @@ type String which represents the type of device eg. For memory controller device on intel_menlow platform: this should be "Memory controller" RO - Optional + Required max_state The maximum permissible cooling state of this cooling device. RO @@ -219,16 +219,16 @@ the sys I/F structure will be built like this: |thermal_zone1: |-----type: ACPI thermal zone - |-----temp: 37 + |-----temp: 37000 |-----mode: kernel - |-----trip_point_0_temp: 100 + |-----trip_point_0_temp: 100000 |-----trip_point_0_type: critical - |-----trip_point_1_temp: 80 + |-----trip_point_1_temp: 80000 |-----trip_point_1_type: passive - |-----trip_point_2_temp: 70 - |-----trip_point_2_type: active[0] - |-----trip_point_3_temp: 60 - |-----trip_point_3_type: active[1] + |-----trip_point_2_temp: 70000 + |-----trip_point_2_type: active0 + |-----trip_point_3_temp: 60000 + |-----trip_point_3_type: active1 |-----cdev0: --->/sys/class/thermal/cooling_device0 |-----cdev0_trip_point: 1 /* cdev0 can be used for passive */ |-----cdev1: --->/sys/class/thermal/cooling_device3 diff --git a/Documentation/unaligned-memory-access.txt b/Documentation/unaligned-memory-access.txt index 6223eace3c09..b0472ac5226a 100644 --- a/Documentation/unaligned-memory-access.txt +++ b/Documentation/unaligned-memory-access.txt @@ -57,7 +57,7 @@ here; a summary of the common scenarios is presented below: unaligned access to be corrected. - Some architectures are not capable of unaligned memory access, but will silently perform a different memory access to the one that was requested, - resulting a a subtle code bug that is hard to detect! + resulting in a subtle code bug that is hard to detect! It should be obvious from the above that if your code causes unaligned memory accesses to happen, your code will not work correctly on certain @@ -209,7 +209,7 @@ memory and you wish to avoid unaligned access, its usage is as follows: u32 value = get_unaligned((u32 *) data); -These macros work work for memory accesses of any length (not just 32 bits as +These macros work for memory accesses of any length (not just 32 bits as in the examples above). Be aware that when compared to standard access of aligned memory, using these macros to access unaligned memory can be costly in terms of performance. diff --git a/Documentation/usb/usb-help.txt b/Documentation/usb/usb-help.txt index a7408593829f..4273ca2b86ba 100644 --- a/Documentation/usb/usb-help.txt +++ b/Documentation/usb/usb-help.txt @@ -1,5 +1,5 @@ usb-help.txt -2000-July-12 +2008-Mar-7 For USB help other than the readme files that are located in Documentation/usb/*, see the following: @@ -10,9 +10,7 @@ Linux-USB project: http://www.linux-usb.org Linux USB Guide: http://linux-usb.sourceforge.net Linux-USB device overview (working devices and drivers): http://www.qbik.ch/usb/devices/ - -The Linux-USB mailing lists are: - linux-usb-users@lists.sourceforge.net for general user help - linux-usb-devel@lists.sourceforge.net for developer discussions + +The Linux-USB mailing list is at linux-usb@vger.kernel.org ### diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index 6a8469f2bcae..f40e09296f30 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -8,7 +8,7 @@ 7 -> Leadtek Winfast USB II (em2800) 8 -> Kworld USB2800 (em2800) 9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a] - 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500] + 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500,2040:6502] 11 -> Terratec Hybrid XS (em2880) [0ccd:0042] 12 -> Kworld PVR TV 2800 RF (em2820/em2840) 13 -> Terratec Prodigy XS (em2880) [0ccd:0047] diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 5d3b6b4d2515..0424901ebc78 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -92,9 +92,9 @@ 91 -> AVerMedia A169 B [1461:7360] 92 -> AVerMedia A169 B1 [1461:6360] 93 -> Medion 7134 Bridge #2 [16be:0005] - 94 -> LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB [5168:3306,5168:3502,4e42:3502] + 94 -> LifeView FlyDVB-T Hybrid Cardbus/MSI TV @nywhere A/D NB [5168:3306,5168:3502,5168:3307,4e42:3502] 95 -> LifeView FlyVIDEO3000 (NTSC) [5169:0138] - 96 -> Medion Md8800 Quadro [16be:0007,16be:0008] + 96 -> Medion Md8800 Quadro [16be:0007,16be:0008,16be:000d] 97 -> LifeView FlyDVB-S /Acorp TV134DS [5168:0300,4e42:0300] 98 -> Proteus Pro 2309 [0919:2003] 99 -> AVerMedia TV Hybrid A16AR [1461:2c00] @@ -129,3 +129,5 @@ 128 -> Beholder BeholdTV Columbus TVFM [0000:5201] 129 -> Beholder BeholdTV 607 / BeholdTV 609 [5ace:6070,5ace:6071,5ace:6072,5ace:6073,5ace:6090,5ace:6091,5ace:6092,5ace:6093] 130 -> Beholder BeholdTV M6 / BeholdTV M6 Extra [5ace:6190,5ace:6193] +131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] +132 -> Genius TVGO AM11MCE diff --git a/Documentation/video4linux/zr364xx.txt b/Documentation/video4linux/zr364xx.txt index 4d9a0c33f2fd..5c81e3ae6458 100644 --- a/Documentation/video4linux/zr364xx.txt +++ b/Documentation/video4linux/zr364xx.txt @@ -25,7 +25,7 @@ modprobe zr364xx debug=X mode=Y - debug : set to 1 to enable verbose debug messages - mode : 0 = 320x240, 1 = 160x120, 2 = 640x480 You can then use the camera with V4L2 compatible applications, for example Ekiga. -To capture a single image, try this: dd if=/dev/video0 of=test.jpg bs=1 count=1 +To capture a single image, try this: dd if=/dev/video0 of=test.jpg bs=1M count=1 links : http://mxhaard.free.fr/ (support for many others cams including some Aiptek PocketDV) @@ -63,3 +63,5 @@ Vendor Product Distributor Model 0x06d6 0x0034 Trust Powerc@m 750 0x0a17 0x0062 Pentax Optio 50L 0x06d6 0x003b Trust Powerc@m 970Z +0x0a17 0x004e Pentax Optio 50 +0x041e 0x405d Creative DiVi CAM 516 diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt index f962d01bea2a..3102b81bef88 100644 --- a/Documentation/vm/hugetlbpage.txt +++ b/Documentation/vm/hugetlbpage.txt @@ -88,10 +88,9 @@ hugepages from the buddy allocator, if the normal pool is exhausted. As these surplus hugepages go out of use, they are freed back to the buddy allocator. -Caveat: Shrinking the pool via nr_hugepages while a surplus is in effect -will allow the number of surplus huge pages to exceed the overcommit -value, as the pool hugepages (which must have been in use for a surplus -hugepages to be allocated) will become surplus hugepages. As long as +Caveat: Shrinking the pool via nr_hugepages such that it becomes less +than the number of hugepages in use will convert the balance to surplus +huge pages even if it would exceed the overcommit value. As long as this condition holds, however, no more surplus huge pages will be allowed on the system until one of the two sysctls are increased sufficiently, or the surplus huge pages go out of use and are freed. diff --git a/Documentation/vm/slabinfo.c b/Documentation/vm/slabinfo.c index 7123fee708ca..22d7e3e4d60c 100644 --- a/Documentation/vm/slabinfo.c +++ b/Documentation/vm/slabinfo.c @@ -1123,7 +1123,7 @@ void read_slab_dir(void) char *t; int count; - if (chdir("/sys/kernel/slab")) + if (chdir("/sys/kernel/slab") && chdir("/sys/slab")) fatal("SYSFS support for SLUB not active\n"); dir = opendir("."); diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt index dcf8bcf846d6..7c13f22a0c9e 100644 --- a/Documentation/vm/slub.txt +++ b/Documentation/vm/slub.txt @@ -50,14 +50,14 @@ F.e. in order to boot just with sanity checks and red zoning one would specify: Trying to find an issue in the dentry cache? Try - slub_debug=,dentry_cache + slub_debug=,dentry to only enable debugging on the dentry cache. Red zoning and tracking may realign the slab. We can just apply sanity checks to the dentry cache with - slub_debug=F,dentry_cache + slub_debug=F,dentry In case you forgot to enable debugging on the kernel command line: It is possible to enable debugging manually when the kernel is up. Look at the diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt new file mode 100644 index 000000000000..17965f927c15 --- /dev/null +++ b/Documentation/x86/pat.txt @@ -0,0 +1,100 @@ + +PAT (Page Attribute Table) + +x86 Page Attribute Table (PAT) allows for setting the memory attribute at the +page level granularity. PAT is complementary to the MTRR settings which allows +for setting of memory types over physical address ranges. However, PAT is +more flexible than MTRR due to its capability to set attributes at page level +and also due to the fact that there are no hardware limitations on number of +such attribute settings allowed. Added flexibility comes with guidelines for +not having memory type aliasing for the same physical memory with multiple +virtual addresses. + +PAT allows for different types of memory attributes. The most commonly used +ones that will be supported at this time are Write-back, Uncached, +Write-combined and Uncached Minus. + +There are many different APIs in the kernel that allows setting of memory +attributes at the page level. In order to avoid aliasing, these interfaces +should be used thoughtfully. Below is a table of interfaces available, +their intended usage and their memory attribute relationships. Internally, +these APIs use a reserve_memtype()/free_memtype() interface on the physical +address range to avoid any aliasing. + + +------------------------------------------------------------------- +API | RAM | ACPI,... | Reserved/Holes | +-----------------------|----------|------------|------------------| + | | | | +ioremap | -- | UC | UC | + | | | | +ioremap_cache | -- | WB | WB | + | | | | +ioremap_nocache | -- | UC | UC | + | | | | +ioremap_wc | -- | -- | WC | + | | | | +set_memory_uc | UC | -- | -- | + set_memory_wb | | | | + | | | | +set_memory_wc | WC | -- | -- | + set_memory_wb | | | | + | | | | +pci sysfs resource | -- | -- | UC | + | | | | +pci sysfs resource_wc | -- | -- | WC | + is IORESOURCE_PREFETCH| | | | + | | | | +pci proc | -- | -- | UC | + !PCIIOC_WRITE_COMBINE | | | | + | | | | +pci proc | -- | -- | WC | + PCIIOC_WRITE_COMBINE | | | | + | | | | +/dev/mem | -- | UC | UC | + read-write | | | | + | | | | +/dev/mem | -- | UC | UC | + mmap SYNC flag | | | | + | | | | +/dev/mem | -- | WB/WC/UC | WB/WC/UC | + mmap !SYNC flag | |(from exist-| (from exist- | + and | | ing alias)| ing alias) | + any alias to this area| | | | + | | | | +/dev/mem | -- | WB | WB | + mmap !SYNC flag | | | | + no alias to this area | | | | + and | | | | + MTRR says WB | | | | + | | | | +/dev/mem | -- | -- | UC_MINUS | + mmap !SYNC flag | | | | + no alias to this area | | | | + and | | | | + MTRR says !WB | | | | + | | | | +------------------------------------------------------------------- + +Notes: + +-- in the above table mean "Not suggested usage for the API". Some of the --'s +are strictly enforced by the kernel. Some others are not really enforced +today, but may be enforced in future. + +For ioremap and pci access through /sys or /proc - The actual type returned +can be more restrictive, in case of any existing aliasing for that address. +For example: If there is an existing uncached mapping, a new ioremap_wc can +return uncached mapping in place of write-combine requested. + +set_memory_[uc|wc] and set_memory_wb should be used in pairs, where driver will +first make a region uc or wc and switch it back to wb after use. + +Over time writes to /proc/mtrr will be deprecated in favor of using PAT based +interfaces. Users writing to /proc/mtrr are suggested to use above interfaces. + +Drivers should use ioremap_[uc|wc] to access PCI BARs with [uc|wc] access +types. + +Drivers should use set_memory_[uc|wc] to set access type for RAM ranges. + diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt index 34abae4e9442..b0c7b6c4abda 100644 --- a/Documentation/x86_64/boot-options.txt +++ b/Documentation/x86_64/boot-options.txt @@ -307,3 +307,8 @@ Debugging stuck (default) Miscellaneous + + nogbpages + Do not use GB pages for kernel direct mappings. + gbpages + Use GB pages for kernel direct mappings. |