diff --git a/[refs] b/[refs] index 35702335ae2d..9f19297da676 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 5b9b5572c87b460cd91f7722ac233d1873cfb084 +refs/heads/master: c38778c3a9aeadcd1ee319cfc8ea5a9cbf8cdafa diff --git a/trunk/CREDITS b/trunk/CREDITS index 5d75254bcb81..cc3453a55fb9 100644 --- a/trunk/CREDITS +++ b/trunk/CREDITS @@ -34,7 +34,6 @@ E: magrawal@nortelnetworks.com D: Basic Interphase 5575 driver with UBR and ABR support. S: 75 Donald St, Apt 42 S: Weymouth, MA 02188 -S: USA N: Dave Airlie E: airlied@linux.ie @@ -203,7 +202,6 @@ S: MS42 S: Hewlett-Packard S: 3404 E Harmony Rd S: Fort Collins, CO 80525 -S: USA N: Arindam Banerji E: axb@cse.nd.edu @@ -446,7 +444,6 @@ E: rbradetich@uswest.net D: Linux/PA-RISC hacker S: 1200 Goldenrod Dr. S: Nampa, Idaho 83686 -S: USA N: Derrick J. Brashear E: shadow@dementia.org @@ -636,7 +633,6 @@ E: scole@lanl.gov E: elenstev@mesatop.com D: Various build fixes and kernel documentation. S: Los Alamos, New Mexico -S: USA N: Hamish Coleman E: hamish@zot.apana.org.au @@ -955,12 +951,6 @@ S: Brevia 1043 S: S-114 79 Stockholm S: Sweden -N: Pekka Enberg -E: penberg@cs.helsinki.fi -W: http://www.cs.helsinki.fi/u/penberg/ -D: Various kernel hacks, fixes, and cleanups. -S: Finland - N: David Engebretsen E: engebret@us.ibm.com D: Linux port to 64-bit PowerPC architecture @@ -1630,8 +1620,7 @@ D: fbdev hacking N: Jesper Juhl E: jesper.juhl@gmail.com -D: Various fixes, cleanups and minor features all over the tree. -D: Wrote initial version of the hdaps driver (since passed on to others). +D: Various fixes, cleanups and minor features. S: Lemnosvej 1, 3.tv S: 2300 Copenhagen S. S: Denmark @@ -2013,7 +2002,6 @@ W: http://www.mathematik.uni-stuttgart.de/~floeff D: Busmaster driver for HP 10/100 Mbit Network Adapters S: University of Stuttgart, Germany and S: Ecole Nationale Superieure des Telecommunications, Paris -S: France N: Jamie Lokier E: jamie@shareable.org @@ -2183,7 +2171,6 @@ S: Hewlett Packard S: MS 42 S: 3404 E. Harmony Road S: Fort Collins, CO 80528 -S: USA N: Torben Mathiasen E: torben.mathiasen@compaq.com @@ -2240,12 +2227,6 @@ D: tc: HFSC scheduler S: Freiburg S: Germany -N: Paul E. McKenney -E: paulmck@us.ibm.com -W: http://www.rdrop.com/users/paulmck/ -D: RCU and variants -D: rcutorture module - N: Mike McLagan E: mike.mclagan@linux.org W: http://www.invlogic.com/~mmclagan @@ -2496,8 +2477,7 @@ S: Derbyshire DE4 3RL S: United Kingdom N: Ian S. Nelson -E: nelsonis@earthlink.net -P: 1024D/00D3D983 3EFD 7B86 B888 D7E2 29B6 9E97 576F 1B97 00D3 D983 +E: ian.nelson@echostar.com D: Minor mmap and ide hacks S: 1370 Atlantis Ave. S: Lafayette CO, 80026 @@ -2987,10 +2967,6 @@ S: 69 rue Dunois S: 75013 Paris S: France -N: Dipankar Sarma -E: dipankar@in.ibm.com -D: RCU - N: Hannu Savolainen E: hannu@opensound.com D: Maintainer of the sound drivers until 2.1.x days. @@ -3303,12 +3279,6 @@ S: 3 Ballow Crescent S: MacGregor A.C.T 2615 S: Australia -N: Josh Triplett -E: josh@freedesktop.org -P: 1024D/D0FE7AFB B24A 65C9 1D71 2AC2 DE87 CA26 189B 9946 D0FE 7AFB -D: rcutorture maintainer -D: lock annotations, finding and fixing lock bugs - N: Winfried Trümper E: winni@xpilot.org W: http://www.shop.de/~winni/ @@ -3680,7 +3650,7 @@ S: Portland, OR S: USA N: Michal Wronski -E: michal.wronski@gmail.com +E: Michal.Wronski@motorola.com D: POSIX message queues fs (with K. Benedyczak) S: Krakow S: Poland diff --git a/trunk/Documentation/ABI/removed/devfs b/trunk/Documentation/ABI/obsolete/devfs similarity index 72% rename from trunk/Documentation/ABI/removed/devfs rename to trunk/Documentation/ABI/obsolete/devfs index 8195c4e0d0a1..b8b87399bc8f 100644 --- a/trunk/Documentation/ABI/removed/devfs +++ b/trunk/Documentation/ABI/obsolete/devfs @@ -1,12 +1,13 @@ What: devfs -Date: July 2005 (scheduled), finally removed in kernel v2.6.18 +Date: July 2005 Contact: Greg Kroah-Hartman Description: devfs has been unmaintained for a number of years, has unfixable races, contains a naming policy within the kernel that is against the LSB, and can be replaced by using udev. - The files fs/devfs/*, include/linux/devfs_fs*.h were removed, + The files fs/devfs/*, include/linux/devfs_fs*.h will be removed, along with the the assorted devfs function calls throughout the kernel tree. Users: + diff --git a/trunk/Documentation/ABI/testing/sysfs-power b/trunk/Documentation/ABI/testing/sysfs-power deleted file mode 100644 index d882f8093871..000000000000 --- a/trunk/Documentation/ABI/testing/sysfs-power +++ /dev/null @@ -1,88 +0,0 @@ -What: /sys/power/ -Date: August 2006 -Contact: Rafael J. Wysocki -Description: - The /sys/power directory will contain files that will - provide a unified interface to the power management - subsystem. - -What: /sys/power/state -Date: August 2006 -Contact: Rafael J. Wysocki -Description: - The /sys/power/state file controls the system power state. - Reading from this file returns what states are supported, - which is hard-coded to 'standby' (Power-On Suspend), 'mem' - (Suspend-to-RAM), and 'disk' (Suspend-to-Disk). - - Writing to this file one of these strings causes the system to - transition into that state. Please see the file - Documentation/power/states.txt for a description of each of - these states. - -What: /sys/power/disk -Date: August 2006 -Contact: Rafael J. Wysocki -Description: - The /sys/power/disk file controls the operating mode of the - suspend-to-disk mechanism. Reading from this file returns - the name of the method by which the system will be put to - sleep on the next suspend. There are four methods supported: - 'firmware' - means that the memory image will be saved to disk - by some firmware, in which case we also assume that the - firmware will handle the system suspend. - 'platform' - the memory image will be saved by the kernel and - the system will be put to sleep by the platform driver (e.g. - ACPI or other PM registers). - 'shutdown' - the memory image will be saved by the kernel and - the system will be powered off. - 'reboot' - the memory image will be saved by the kernel and - the system will be rebooted. - - The suspend-to-disk method may be chosen by writing to this - file one of the accepted strings: - - 'firmware' - 'platform' - 'shutdown' - 'reboot' - - It will only change to 'firmware' or 'platform' if the system - supports that. - -What: /sys/power/image_size -Date: August 2006 -Contact: Rafael J. Wysocki -Description: - The /sys/power/image_size file controls the size of the image - created by the suspend-to-disk mechanism. It can be written a - string representing a non-negative integer that will be used - as an upper limit of the image size, in bytes. The kernel's - suspend-to-disk code will do its best to ensure the image size - will not exceed this number. However, if it turns out to be - impossible, the kernel will try to suspend anyway using the - smallest image possible. In particular, if "0" is written to - this file, the suspend image will be as small as possible. - - Reading from this file will display the current image size - limit, which is set to 500 MB by default. - -What: /sys/power/pm_trace -Date: August 2006 -Contact: Rafael J. Wysocki -Description: - The /sys/power/pm_trace file controls the code which saves the - last PM event point in the RTC across reboots, so that you can - debug a machine that just hangs during suspend (or more - commonly, during resume). Namely, the RTC is only used to save - the last PM event point if this file contains '1'. Initially - it contains '0' which may be changed to '1' by writing a - string representing a nonzero integer into it. - - To use this debugging feature you should attempt to suspend - the machine, then reboot it and run - - dmesg -s 1000000 | grep 'hash matches' - - CAUTION: Using it will cause your machine's real-time (CMOS) - clock to be set to a random invalid time after a resume. diff --git a/trunk/Documentation/CodingStyle b/trunk/Documentation/CodingStyle index 29c18966b050..6d2412ec91ed 100644 --- a/trunk/Documentation/CodingStyle +++ b/trunk/Documentation/CodingStyle @@ -532,40 +532,6 @@ appears outweighs the potential value of the hint that tells gcc to do something it would have done anyway. - Chapter 16: Function return values and names - -Functions can return values of many different kinds, and one of the -most common is a value indicating whether the function succeeded or -failed. Such a value can be represented as an error-code integer -(-Exxx = failure, 0 = success) or a "succeeded" boolean (0 = failure, -non-zero = success). - -Mixing up these two sorts of representations is a fertile source of -difficult-to-find bugs. If the C language included a strong distinction -between integers and booleans then the compiler would find these mistakes -for us... but it doesn't. To help prevent such bugs, always follow this -convention: - - If the name of a function is an action or an imperative command, - the function should return an error-code integer. If the name - is a predicate, the function should return a "succeeded" boolean. - -For example, "add work" is a command, and the add_work() function returns 0 -for success or -EBUSY for failure. In the same way, "PCI device present" is -a predicate, and the pci_dev_present() function returns 1 if it succeeds in -finding a matching device or 0 if it doesn't. - -All EXPORTed functions must respect this convention, and so should all -public functions. Private (static) functions need not, but it is -recommended that they do. - -Functions whose return value is the actual result of a computation, rather -than an indication of whether the computation succeeded, are not subject to -this rule. Generally they indicate failure by returning some out-of-range -result. Typical examples would be functions that return pointers; they use -NULL or the ERR_PTR mechanism to report failure. - - Appendix I: References diff --git a/trunk/Documentation/DMA-mapping.txt b/trunk/Documentation/DMA-mapping.txt index 028614cdd062..63392c9132b4 100644 --- a/trunk/Documentation/DMA-mapping.txt +++ b/trunk/Documentation/DMA-mapping.txt @@ -107,7 +107,7 @@ The query is performed via a call to pci_set_dma_mask(): int pci_set_dma_mask(struct pci_dev *pdev, u64 device_mask); -The query for consistent allocations is performed via a call to +The query for consistent allocations is performed via a a call to pci_set_consistent_dma_mask(): int pci_set_consistent_dma_mask(struct pci_dev *pdev, u64 device_mask); @@ -117,7 +117,7 @@ device_mask is a bit mask describing which bits of a PCI address your device supports. It returns zero if your card can perform DMA properly on the machine given the address mask you provided. -If it returns non-zero, your device cannot perform DMA properly on +If it returns non-zero, your device can not perform DMA properly on this platform, and attempting to do so will result in undefined behavior. You must either use a different mask, or not use DMA. diff --git a/trunk/Documentation/DocBook/kernel-api.tmpl b/trunk/Documentation/DocBook/kernel-api.tmpl index 2b5ac604948c..f8fe882e33dc 100644 --- a/trunk/Documentation/DocBook/kernel-api.tmpl +++ b/trunk/Documentation/DocBook/kernel-api.tmpl @@ -158,7 +158,6 @@ X!Ilib/string.c !Emm/filemap.c !Emm/memory.c !Emm/vmalloc.c -!Imm/page_alloc.c !Emm/mempool.c !Emm/page-writeback.c !Emm/truncate.c @@ -182,6 +181,27 @@ X!Ilib/string.c + + The proc filesystem + + sysctl interface +!Ekernel/sysctl.c + + + proc filesystem interface +!Ifs/proc/base.c + + + + + The debugfs filesystem + + debugfs interface +!Efs/debugfs/inode.c +!Efs/debugfs/file.c + + + The Linux VFS The Filesystem types @@ -214,50 +234,6 @@ X!Ilib/string.c - - The proc filesystem - - sysctl interface -!Ekernel/sysctl.c - - - proc filesystem interface -!Ifs/proc/base.c - - - - - The Filesystem for Exporting Kernel Objects -!Efs/sysfs/file.c -!Efs/sysfs/symlink.c -!Efs/sysfs/bin.c - - - - The debugfs filesystem - - debugfs interface -!Efs/debugfs/inode.c -!Efs/debugfs/file.c - - - - - relay interface support - - - Relay interface support - is designed to provide an efficient mechanism for tools and - facilities to relay large amounts of data from kernel space to - user space. - - - relay interface -!Ekernel/relay.c -!Ikernel/relay.c - - - Linux Networking Networking Base Types @@ -326,13 +302,8 @@ X!Ekernel/module.c !Ekernel/irq/manage.c - DMA Channels -!Ekernel/dma.c - - Resources Management !Ikernel/resource.c -!Ekernel/resource.c MTRR Handling @@ -378,6 +349,13 @@ X!Earch/i386/kernel/mca.c + + The Filesystem for Exporting Kernel Objects +!Efs/sysfs/file.c +!Efs/sysfs/symlink.c +!Efs/sysfs/bin.c + + Security Framework !Esecurity/security.c @@ -408,7 +386,6 @@ X!Iinclude/linux/device.h --> !Edrivers/base/driver.c !Edrivers/base/core.c -!Edrivers/base/class.c !Edrivers/base/firmware_class.c !Edrivers/base/transport_class.c !Edrivers/base/dmapool.c @@ -460,11 +437,6 @@ X!Edrivers/pnp/system.c !Eblock/ll_rw_blk.c - - Char devices -!Efs/char_dev.c - - Miscellaneous Devices !Edrivers/char/misc.c diff --git a/trunk/Documentation/DocBook/libata.tmpl b/trunk/Documentation/DocBook/libata.tmpl index c684abf0d3b2..065e8dc23e3a 100644 --- a/trunk/Documentation/DocBook/libata.tmpl +++ b/trunk/Documentation/DocBook/libata.tmpl @@ -1400,7 +1400,7 @@ and other resources, etc. When it's known that HBA is in ready state but ATA/ATAPI - device is in unknown state, reset only device. + device in in unknown state, reset only device. diff --git a/trunk/Documentation/DocBook/usb.tmpl b/trunk/Documentation/DocBook/usb.tmpl index 143e5ff7deb8..320af25de3a2 100644 --- a/trunk/Documentation/DocBook/usb.tmpl +++ b/trunk/Documentation/DocBook/usb.tmpl @@ -43,52 +43,59 @@ A Universal Serial Bus (USB) is used to connect a host, such as a PC or workstation, to a number of peripheral - devices. USB uses a tree structure, with the host as the + devices. USB uses a tree structure, with the host at the root (the system's master), hubs as interior nodes, and - peripherals as leaves (and slaves). + peripheral devices as leaves (and slaves). Modern PCs support several such trees of USB devices, usually one USB 2.0 tree (480 Mbit/sec each) with a few USB 1.1 trees (12 Mbit/sec each) that are used when you connect a USB 1.1 device directly to the machine's "root hub". - That master/slave asymmetry was designed-in for a number of - reasons, one being ease of use. It is not physically possible to - assemble (legal) USB cables incorrectly: all upstream "to the host" - connectors are the rectangular type (matching the sockets on - root hubs), and all downstream connectors are the squarish type - (or they are built into the peripheral). - Also, the host software doesn't need to deal with distributed - auto-configuration since the pre-designated master node manages all that. - And finally, at the electrical level, bus protocol overhead is reduced by - eliminating arbitration and moving scheduling into the host software. + That master/slave asymmetry was designed in part for + ease of use. It is not physically possible to assemble + (legal) USB cables incorrectly: all upstream "to-the-host" + connectors are the rectangular type, matching the sockets on + root hubs, and the downstream type are the squarish type + (or they are built in to the peripheral). + Software doesn't need to deal with distributed autoconfiguration + since the pre-designated master node manages all that. + At the electrical level, bus protocol overhead is reduced by + eliminating arbitration and moving scheduling into host software. - USB 1.0 was announced in January 1996 and was revised + USB 1.0 was announced in January 1996, and was revised as USB 1.1 (with improvements in hub specification and support for interrupt-out transfers) in September 1998. - USB 2.0 was released in April 2000, adding high-speed - transfers and transaction-translating hubs (used for USB 1.1 + USB 2.0 was released in April 2000, including high speed + transfers and transaction translating hubs (used for USB 1.1 and 1.0 backward compatibility). - Kernel developers added USB support to Linux early in the 2.2 kernel - series, shortly before 2.3 development forked. Updates from 2.3 were - regularly folded back into 2.2 releases, which improved reliability and - brought /sbin/hotplug support as well more drivers. - Such improvements were continued in the 2.5 kernel series, where they added - USB 2.0 support, improved performance, and made the host controller drivers - (HCDs) more consistent. They also simplified the API (to make bugs less - likely) and added internal "kerneldoc" documentation. + USB support was added to Linux early in the 2.2 kernel series + shortly before the 2.3 development forked off. Updates + from 2.3 were regularly folded back into 2.2 releases, bringing + new features such as /sbin/hotplug support, + more drivers, and more robustness. + The 2.5 kernel series continued such improvements, and also + worked on USB 2.0 support, + higher performance, + better consistency between host controller drivers, + API simplification (to make bugs less likely), + and providing internal "kerneldoc" documentation. Linux can run inside USB devices as well as on the hosts that control the devices. - But USB device drivers running inside those peripherals + Because the Linux 2.x USB support evolved to support mass market + platforms such as Apple Macintosh or PC-compatible systems, + it didn't address design concerns for those types of USB systems. + So it can't be used inside mass-market PDAs, or other peripherals. + USB device drivers running inside those Linux peripherals don't do the same things as the ones running inside hosts, - so they've been given a different name: - gadget drivers. - This document does not cover gadget drivers. + and so they've been given a different name: + they're called gadget drivers. + This document does not present gadget drivers. @@ -96,14 +103,17 @@ USB Host-Side API Model - Host-side drivers for USB devices talk to the "usbcore" APIs. - There are two. One is intended for - general-purpose drivers (exposed through - driver frameworks), and the other is for drivers that are - part of the core. - Such core drivers include the hub driver - (which manages trees of USB devices) and several different kinds - of host controller drivers, + Within the kernel, + host-side drivers for USB devices talk to the "usbcore" APIs. + There are two types of public "usbcore" APIs, targetted at two different + layers of USB driver. Those are + general purpose drivers, exposed through + driver frameworks such as block, character, or network devices; + and drivers that are part of the core, + which are involved in managing a USB bus. + Such core drivers include the hub driver, + which manages trees of USB devices, and several different kinds + of host controller driver (HCD), which control individual busses. @@ -112,21 +122,21 @@ - USB supports four kinds of data transfers - (control, bulk, interrupt, and isochronous). Two of them (control - and bulk) use bandwidth as it's available, - while the other two (interrupt and isochronous) + USB supports four kinds of data transfer + (control, bulk, interrupt, and isochronous). Two transfer + types use bandwidth as it's available (control and bulk), + while the other two types of transfer (interrupt and isochronous) are scheduled to provide guaranteed bandwidth. The device description model includes one or more "configurations" per device, only one of which is active at a time. - Devices that are capable of high-speed operation must also support - full-speed configurations, along with a way to ask about the - "other speed" configurations which might be used. + Devices that are capable of high speed operation must also support + full speed configurations, along with a way to ask about the + "other speed" configurations that might be used. - Configurations have one or more "interfaces", each + Configurations have one or more "interface", each of which may have "alternate settings". Interfaces may be standardized by USB "Class" specifications, or may be specific to a vendor or device. @@ -152,7 +162,7 @@ The Linux USB API supports synchronous calls for - control and bulk messages. + control and bulk messaging. It also supports asynchnous calls for all kinds of data transfer, using request structures called "URBs" (USB Request Blocks). @@ -314,7 +324,8 @@ usbdevfs although it wasn't solving what devfs was. Every USB device will appear in usbfs, regardless of whether or - not it has a kernel driver. + not it has a kernel driver; but only devices with kernel drivers + show up in devfs. @@ -452,25 +463,14 @@ file in your Linux kernel sources. - This file, in combination with the poll() system call, can - also be used to detect when devices are added or removed: -int fd; -struct pollfd pfd; - -fd = open("/proc/bus/usb/devices", O_RDONLY); -pfd = { fd, POLLIN, 0 }; -for (;;) { - /* The first time through, this call will return immediately. */ - poll(&pfd, 1, -1); - - /* To see what's changed, compare the file's previous and current - contents or scan the filesystem. (Scanning is more precise.) */ -} - Note that this behavior is intended to be used for informational - and debug purposes. It would be more appropriate to use programs - such as udev or HAL to initialize a device or start a user-mode - helper program, for instance. + Otherwise the main use for this file from programs + is to poll() it to get notifications of usb devices + as they're plugged or unplugged. + To see what changed, you'd need to read the file and + compare "before" and "after" contents, scan the filesystem, + or see its hotplug event. + @@ -740,7 +740,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param) Synchronous I/O Support Synchronous requests involve the kernel blocking - until the user mode request completes, either by + until until the user mode request completes, either by finishing successfully or by reporting an error. In most cases this is the simplest way to use usbfs, although as noted above it does prevent performing I/O diff --git a/trunk/Documentation/DocBook/writing_usb_driver.tmpl b/trunk/Documentation/DocBook/writing_usb_driver.tmpl index 07cd34c1940b..008a341234d0 100644 --- a/trunk/Documentation/DocBook/writing_usb_driver.tmpl +++ b/trunk/Documentation/DocBook/writing_usb_driver.tmpl @@ -224,8 +224,13 @@ static int skel_probe(struct usb_interface *interface, Conversely, when the device is removed from the USB bus, the disconnect function is called with the device pointer. The driver needs to clean any private data that has been allocated at this time and to shut down any - pending urbs that are in the USB system. + pending urbs that are in the USB system. The driver also unregisters + itself from the devfs subsystem with the call: + +/* remove our devfs node */ +devfs_unregister(skel->devfs); + Now that the device is plugged into the system and the driver is bound to the device, any of the functions in the file_operations structure that diff --git a/trunk/Documentation/HOWTO b/trunk/Documentation/HOWTO index d6f3dd1a3464..915ae8c986c6 100644 --- a/trunk/Documentation/HOWTO +++ b/trunk/Documentation/HOWTO @@ -358,8 +358,7 @@ Here is a list of some of the different kernel trees available: quilt trees: - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ - - x86-64, partly i386, Andi Kleen - ftp.firstfloor.org:/pub/ak/x86_64/quilt/ + Bug Reporting ------------- @@ -375,26 +374,6 @@ of information is needed by the kernel developers to help track down the problem. -Managing bug reports --------------------- - -One of the best ways to put into practice your hacking skills is by fixing -bugs reported by other people. Not only you will help to make the kernel -more stable, you'll learn to fix real world problems and you will improve -your skills, and other developers will be aware of your presence. Fixing -bugs is one of the best ways to earn merit amongst the developers, because -not many people like wasting time fixing other people's bugs. - -To work in the already reported bug reports, go to http://bugzilla.kernel.org. -If you want to be advised of the future bug reports, you can subscribe to the -bugme-new mailing list (only new bug reports are mailed here) or to the -bugme-janitor mailing list (every change in the bugzilla is mailed here) - - http://lists.osdl.org/mailman/listinfo/bugme-new - http://lists.osdl.org/mailman/listinfo/bugme-janitors - - - Mailing lists ------------- diff --git a/trunk/Documentation/IPMI.txt b/trunk/Documentation/IPMI.txt index 0e3924ecd76b..0256805b548f 100644 --- a/trunk/Documentation/IPMI.txt +++ b/trunk/Documentation/IPMI.txt @@ -326,12 +326,9 @@ for events, they will all receive all events that come in. For receiving commands, you have to individually register commands you want to receive. Call ipmi_register_for_cmd() and supply the netfn -and command name for each command you want to receive. You also -specify a bitmask of the channels you want to receive the command from -(or use IPMI_CHAN_ALL for all channels if you don't care). Only one -user may be registered for each netfn/cmd/channel, but different users -may register for different commands, or the same command if the -channel bitmasks do not overlap. +and command name for each command you want to receive. Only one user +may be registered for each netfn/cmd, but different users may register +for different commands. From userland, equivalent IOCTLs are provided to do these functions. @@ -364,7 +361,6 @@ You can change this at module load time (for a module) with: regspacings=,,... regsizes=,,... regshifts=,,... slave_addrs=,,... - force_kipmid=,,... Each of these except si_trydefaults is a list, the first item for the first interface, second item for the second interface, etc. @@ -410,13 +406,7 @@ The slave_addrs specifies the IPMI address of the local BMC. This is usually 0x20 and the driver defaults to that, but in case it's not, it can be specified when the driver starts up. -The force_ipmid parameter forcefully enables (if set to 1) or disables -(if set to 0) the kernel IPMI daemon. Normally this is auto-detected -by the driver, but systems with broken interrupts might need an enable, -or users that don't want the daemon (don't need the performance, don't -want the CPU hit) can disable it. - -When compiled into the kernel, the parameters can be specified on the +When compiled into the kernel, the addresses can be specified on the kernel command line as: ipmi_si.type=,... @@ -426,7 +416,6 @@ kernel command line as: ipmi_si.regsizes=,,... ipmi_si.regshifts=,,... ipmi_si.slave_addrs=,,... - ipmi_si.force_kipmid=,,... It works the same as the module parameters of the same names. @@ -468,12 +457,12 @@ BMCs specified on the smb_addr line will be detected. Setting smb_dbg_probe to 1 will enable debugging of the probing and detection process for BMCs on the SMBusses. -Discovering the IPMI compliant BMC on the SMBus can cause devices +Discovering the IPMI compilant BMC on the SMBus can cause devices on the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI message as a block write to the I2C bus and waits for a response. This action can be detrimental to some I2C devices. It is highly recommended that the known I2c address be given to the SMBus driver in the smb_addr -parameter. The default address range will not be used when a smb_addr +parameter. The default adrress range will not be used when a smb_addr parameter is provided. When compiled into the kernel, the addresses can be specified on the diff --git a/trunk/Documentation/MSI-HOWTO.txt b/trunk/Documentation/MSI-HOWTO.txt index c70306abb7b2..3ec6c720b016 100644 --- a/trunk/Documentation/MSI-HOWTO.txt +++ b/trunk/Documentation/MSI-HOWTO.txt @@ -267,7 +267,7 @@ y = The number of MSI capable devices populated in the system. vector reserved to avoid the case where some MSI-X capable drivers may attempt to claim all available vector resources. -z = The number of MSI-X capable devices populated in the system. +z = The number of MSI-X capable devices pupulated in the system. This policy ensures that maximum (x - y) is distributed evenly among MSI-X capable devices. diff --git a/trunk/Documentation/RCU/checklist.txt b/trunk/Documentation/RCU/checklist.txt index f4dffadbcb00..1d50cf0c905e 100644 --- a/trunk/Documentation/RCU/checklist.txt +++ b/trunk/Documentation/RCU/checklist.txt @@ -221,41 +221,3 @@ over a rather long period of time, but improvements are always welcome! disable irq on a given acquisition of that lock will result in deadlock as soon as the RCU callback happens to interrupt that acquisition's critical section. - -13. SRCU (srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu()) - may only be invoked from process context. Unlike other forms of - RCU, it -is- permissible to block in an SRCU read-side critical - section (demarked by srcu_read_lock() and srcu_read_unlock()), - hence the "SRCU": "sleepable RCU". Please note that if you - don't need to sleep in read-side critical sections, you should - be using RCU rather than SRCU, because RCU is almost always - faster and easier to use than is SRCU. - - Also unlike other forms of RCU, explicit initialization - and cleanup is required via init_srcu_struct() and - cleanup_srcu_struct(). These are passed a "struct srcu_struct" - that defines the scope of a given SRCU domain. Once initialized, - the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock() - and synchronize_srcu(). A given synchronize_srcu() waits only - for SRCU read-side critical sections governed by srcu_read_lock() - and srcu_read_unlock() calls that have been passd the same - srcu_struct. This property is what makes sleeping read-side - critical sections tolerable -- a given subsystem delays only - its own updates, not those of other subsystems using SRCU. - Therefore, SRCU is less prone to OOM the system than RCU would - be if RCU's read-side critical sections were permitted to - sleep. - - The ability to sleep in read-side critical sections does not - come for free. First, corresponding srcu_read_lock() and - srcu_read_unlock() calls must be passed the same srcu_struct. - Second, grace-period-detection overhead is amortized only - over those updates sharing a given srcu_struct, rather than - being globally amortized as they are for other forms of RCU. - Therefore, SRCU should be used in preference to rw_semaphore - only in extremely read-intensive situations, or in situations - requiring SRCU's read-side deadlock immunity or low read-side - realtime latency. - - Note that, rcu_assign_pointer() and rcu_dereference() relate to - SRCU just as they do to other forms of RCU. diff --git a/trunk/Documentation/RCU/rcu.txt b/trunk/Documentation/RCU/rcu.txt index f84407cba816..02e27bf1d365 100644 --- a/trunk/Documentation/RCU/rcu.txt +++ b/trunk/Documentation/RCU/rcu.txt @@ -45,8 +45,7 @@ o How can I see where RCU is currently used in the Linux kernel? Search for "rcu_read_lock", "rcu_read_unlock", "call_rcu", "rcu_read_lock_bh", "rcu_read_unlock_bh", "call_rcu_bh", - "srcu_read_lock", "srcu_read_unlock", "synchronize_rcu", - "synchronize_net", and "synchronize_srcu". + "synchronize_rcu", and "synchronize_net". o What guidelines should I follow when writing code that uses RCU? diff --git a/trunk/Documentation/RCU/torture.txt b/trunk/Documentation/RCU/torture.txt index 25a3c3f7d378..a4948591607d 100644 --- a/trunk/Documentation/RCU/torture.txt +++ b/trunk/Documentation/RCU/torture.txt @@ -28,15 +28,6 @@ nreaders This is the number of RCU reading threads supported. To properly exercise RCU implementations with preemptible read-side critical sections. -nfakewriters This is the number of RCU fake writer threads to run. Fake - writer threads repeatedly use the synchronous "wait for - current readers" function of the interface selected by - torture_type, with a delay between calls to allow for various - different numbers of writers running in parallel. - nfakewriters defaults to 4, which provides enough parallelism - to trigger special cases caused by multiple writers, such as - the synchronize_srcu() early return optimization. - stat_interval The number of seconds between output of torture statistics (via printk()). Regardless of the interval, statistics are printed when the module is unloaded. @@ -53,12 +44,9 @@ test_no_idle_hz Whether or not to test the ability of RCU to operate in a kernel that disables the scheduling-clock interrupt to idle CPUs. Boolean parameter, "1" to test, "0" otherwise. -torture_type The type of RCU to test: "rcu" for the rcu_read_lock() API, - "rcu_sync" for rcu_read_lock() with synchronous reclamation, - "rcu_bh" for the rcu_read_lock_bh() API, "rcu_bh_sync" for - rcu_read_lock_bh() with synchronous reclamation, "srcu" for - the "srcu_read_lock()" API, and "sched" for the use of - preempt_disable() together with synchronize_sched(). +torture_type The type of RCU to test: "rcu" for the rcu_read_lock() + API, "rcu_bh" for the rcu_read_lock_bh() API, and "srcu" + for the "srcu_read_lock()" API. verbose Enable debug printk()s. Default is disabled. @@ -130,21 +118,6 @@ o "Free-Block Circulation": Shows the number of torture structures as it is only incremented if a torture structure's counter somehow gets incremented farther than it should. -Different implementations of RCU can provide implementation-specific -additional information. For example, SRCU provides the following: - - srcu-torture: rtc: f8cf46a8 ver: 355 tfle: 0 rta: 356 rtaf: 0 rtf: 346 rtmbe: 0 - srcu-torture: Reader Pipe: 559738 939 0 0 0 0 0 0 0 0 0 - srcu-torture: Reader Batch: 560434 243 0 0 0 0 0 0 0 0 - srcu-torture: Free-Block Circulation: 355 354 353 352 351 350 349 348 347 346 0 - srcu-torture: per-CPU(idx=1): 0(0,1) 1(0,1) 2(0,0) 3(0,1) - -The first four lines are similar to those for RCU. The last line shows -the per-CPU counter state. The numbers in parentheses are the values -of the "old" and "current" counters for the corresponding CPU. The -"idx" value maps the "old" and "current" values to the underlying array, -and is useful for debugging. - USAGE diff --git a/trunk/Documentation/RCU/whatisRCU.txt b/trunk/Documentation/RCU/whatisRCU.txt index e0d6d99b8f9b..318df44259b3 100644 --- a/trunk/Documentation/RCU/whatisRCU.txt +++ b/trunk/Documentation/RCU/whatisRCU.txt @@ -582,7 +582,7 @@ The rcu_read_lock() and rcu_read_unlock() primitive read-acquire and release a global reader-writer lock. The synchronize_rcu() primitive write-acquires this same lock, then immediately releases it. This means that once synchronize_rcu() exits, all RCU read-side -critical sections that were in progress before synchronize_rcu() was +critical sections that were in progress before synchonize_rcu() was called are guaranteed to have completed -- there is no way that synchronize_rcu() would have been able to write-acquire the lock otherwise. @@ -750,7 +750,7 @@ Or, for those who prefer a side-by-side listing: Either way, the differences are quite small. Read-side locking moves to rcu_read_lock() and rcu_read_unlock, update-side locking moves from -a reader-writer lock to a simple spinlock, and a synchronize_rcu() +from a reader-writer lock to a simple spinlock, and a synchronize_rcu() precedes the kfree(). However, there is one potential catch: the read-side and update-side @@ -778,8 +778,6 @@ Markers for RCU read-side critical sections: rcu_read_unlock rcu_read_lock_bh rcu_read_unlock_bh - srcu_read_lock - srcu_read_unlock RCU pointer/list traversal: @@ -806,7 +804,6 @@ RCU grace period: synchronize_net synchronize_sched synchronize_rcu - synchronize_srcu call_rcu call_rcu_bh diff --git a/trunk/Documentation/SubmitChecklist b/trunk/Documentation/SubmitChecklist index 7ac61f60037a..a10bfb6ecd9f 100644 --- a/trunk/Documentation/SubmitChecklist +++ b/trunk/Documentation/SubmitChecklist @@ -61,8 +61,3 @@ kernel patches. Documentation/kernel-parameters.txt. 18: All new module parameters are documented with MODULE_PARM_DESC() - -19: All new userspace interfaces are documented in Documentation/ABI/. - See Documentation/ABI/README for more information. - -20: Check that it all passes `make headers_check'. diff --git a/trunk/Documentation/SubmittingDrivers b/trunk/Documentation/SubmittingDrivers index 58bead05eabb..6bd30fdd0786 100644 --- a/trunk/Documentation/SubmittingDrivers +++ b/trunk/Documentation/SubmittingDrivers @@ -59,11 +59,11 @@ Copyright: The copyright owner must agree to use of GPL. are the same person/entity. If not, the name of the person/entity authorizing use of GPL should be listed in case it's necessary to verify the will of - the copyright owner. + the copright owner. Interfaces: If your driver uses existing interfaces and behaves like other drivers in the same class it will be much more likely - to be accepted than if it invents gratuitous new ones. + to be accepted than if it invents gratuitous new ones. If you need to implement a common API over Linux and NT drivers do it in userspace. @@ -88,7 +88,7 @@ Clarity: It helps if anyone can see how to fix the driver. It helps it will go in the bitbucket. Control: In general if there is active maintainance of a driver by - the author then patches will be redirected to them unless + the author then patches will be redirected to them unless they are totally obvious and without need of checking. If you want to be the contact and update point for the driver it is a good idea to state this in the comments, @@ -100,7 +100,7 @@ What Criteria Do Not Determine Acceptance Vendor: Being the hardware vendor and maintaining the driver is often a good thing. If there is a stable working driver from other people already in the tree don't expect 'we are the - vendor' to get your driver chosen. Ideally work with the + vendor' to get your driver chosen. Ideally work with the existing driver author to build a single perfect driver. Author: It doesn't matter if a large Linux company wrote the driver, @@ -116,13 +116,17 @@ Linux kernel master tree: ftp.??.kernel.org:/pub/linux/kernel/... ?? == your country code, such as "us", "uk", "fr", etc. -Linux kernel mailing list: +Linux kernel mailing list: linux-kernel@vger.kernel.org [mail majordomo@vger.kernel.org to subscribe] Linux Device Drivers, Third Edition (covers 2.6.10): http://lwn.net/Kernel/LDD3/ (free version) +Kernel traffic: + Weekly summary of kernel list activity (much easier to read) + http://www.kerneltraffic.org/kernel-traffic/ + LWN.net: Weekly summary of kernel development activity - http://lwn.net/ 2.6 API changes: @@ -141,8 +145,11 @@ KernelNewbies: Linux USB project: http://www.linux-usb.org/ -How to NOT write kernel driver by Arjan van de Ven: - http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf +How to NOT write kernel driver by arjanv@redhat.com + http://people.redhat.com/arjanv/olspaper.pdf Kernel Janitor: http://janitor.kernelnewbies.org/ + +-- +Last updated on 17 Nov 2005. diff --git a/trunk/Documentation/SubmittingPatches b/trunk/Documentation/SubmittingPatches index 302d148c2e18..d42ab4c9e893 100644 --- a/trunk/Documentation/SubmittingPatches +++ b/trunk/Documentation/SubmittingPatches @@ -173,15 +173,15 @@ For small patches you may want to CC the Trivial Patch Monkey trivial@kernel.org managed by Adrian Bunk; which collects "trivial" patches. Trivial patches must qualify for one of the following rules: Spelling fixes in documentation - Spelling fixes which could break grep(1) + Spelling fixes which could break grep(1). Warning fixes (cluttering with useless warnings is bad) Compilation fixes (only if they are actually correct) Runtime fixes (only if they actually fix things) - Removing use of deprecated functions/macros (eg. check_region) + Removing use of deprecated functions/macros (eg. check_region). Contact detail and documentation fixes Non-portable code replaced by portable code (even in arch-specific, since people copy, as long as it's trivial) - Any fix by the author/maintainer of the file (ie. patch monkey + Any fix by the author/maintainer of the file. (ie. patch monkey in re-transmission mode) URL: @@ -209,19 +209,6 @@ Exception: If your mailer is mangling patches then someone may ask you to re-send them using MIME. -WARNING: Some mailers like Mozilla send your messages with ----- message header ---- -Content-Type: text/plain; charset=us-ascii; format=flowed ----- message header ---- -The problem is that "format=flowed" makes some of the mailers -on receiving side to replace TABs with spaces and do similar -changes. Thus the patches from you can look corrupted. - -To fix this just make your mozilla defaults/pref/mailnews.js file to look like: -pref("mailnews.send_plaintext_flowed", false); // RFC 2646======= -pref("mailnews.display.disable_format_flowed_support", true); - - 7) E-mail size. @@ -258,13 +245,13 @@ updated change. It is quite common for Linus to "drop" your patch without comment. That's the nature of the system. If he drops your patch, it could be due to -* Your patch did not apply cleanly to the latest kernel version. +* Your patch did not apply cleanly to the latest kernel version * Your patch was not sufficiently discussed on linux-kernel. -* A style issue (see section 2). -* An e-mail formatting issue (re-read this section). -* A technical problem with your change. -* He gets tons of e-mail, and yours got lost in the shuffle. -* You are being annoying. +* A style issue (see section 2), +* An e-mail formatting issue (re-read this section) +* A technical problem with your change +* He gets tons of e-mail, and yours got lost in the shuffle +* You are being annoying (See Figure 1) When in doubt, solicit comments on linux-kernel mailing list. @@ -489,10 +476,10 @@ SECTION 3 - REFERENCES Andrew Morton, "The perfect patch" (tpp). -Jeff Garzik, "Linux kernel patch submission format". +Jeff Garzik, "Linux kernel patch submission format." -Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". +Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer". @@ -501,9 +488,9 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! -Kernel Documentation/CodingStyle: +Kernel Documentation/CodingStyle -Linus Torvalds's mail on the canonical patch format: +Linus Torvald's mail on the canonical patch format: -- diff --git a/trunk/Documentation/accounting/getdelays.c b/trunk/Documentation/accounting/getdelays.c index b11792abd6b6..795ca3911cc5 100644 --- a/trunk/Documentation/accounting/getdelays.c +++ b/trunk/Documentation/accounting/getdelays.c @@ -285,7 +285,7 @@ int main(int argc, char *argv[]) if (maskset) { rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET, TASKSTATS_CMD_ATTR_REGISTER_CPUMASK, - &cpumask, strlen(cpumask) + 1); + &cpumask, sizeof(cpumask)); PRINTF("Sent register cpumask, retval %d\n", rc); if (rc < 0) { printf("error sending register cpumask\n"); @@ -315,8 +315,7 @@ int main(int argc, char *argv[]) } if (msg.n.nlmsg_type == NLMSG_ERROR || !NLMSG_OK((&msg.n), rep_len)) { - struct nlmsgerr *err = NLMSG_DATA(&msg); - printf("fatal reply error, errno %d\n", err->error); + printf("fatal reply error, errno %d\n", errno); goto done; } @@ -384,7 +383,7 @@ int main(int argc, char *argv[]) if (maskset) { rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET, TASKSTATS_CMD_ATTR_DEREGISTER_CPUMASK, - &cpumask, strlen(cpumask) + 1); + &cpumask, sizeof(cpumask)); printf("Sent deregister mask, retval %d\n", rc); if (rc < 0) err(rc, "error sending deregister cpumask\n"); diff --git a/trunk/Documentation/accounting/taskstats-struct.txt b/trunk/Documentation/accounting/taskstats-struct.txt deleted file mode 100644 index 661c797eaf79..000000000000 --- a/trunk/Documentation/accounting/taskstats-struct.txt +++ /dev/null @@ -1,161 +0,0 @@ -The struct taskstats --------------------- - -This document contains an explanation of the struct taskstats fields. - -There are three different groups of fields in the struct taskstats: - -1) Common and basic accounting fields - If CONFIG_TASKSTATS is set, the taskstats inteface is enabled and - the common fields and basic accounting fields are collected for - delivery at do_exit() of a task. -2) Delay accounting fields - These fields are placed between - /* Delay accounting fields start */ - and - /* Delay accounting fields end */ - Their values are collected if CONFIG_TASK_DELAY_ACCT is set. -3) Extended accounting fields - These fields are placed between - /* Extended accounting fields start */ - and - /* Extended accounting fields end */ - Their values are collected if CONFIG_TASK_XACCT is set. - -Future extension should add fields to the end of the taskstats struct, and -should not change the relative position of each field within the struct. - - -struct taskstats { - -1) Common and basic accounting fields: - /* The version number of this struct. This field is always set to - * TAKSTATS_VERSION, which is defined in . - * Each time the struct is changed, the value should be incremented. - */ - __u16 version; - - /* The exit code of a task. */ - __u32 ac_exitcode; /* Exit status */ - - /* The accounting flags of a task as defined in - * Defined values are AFORK, ASU, ACOMPAT, ACORE, and AXSIG. - */ - __u8 ac_flag; /* Record flags */ - - /* The value of task_nice() of a task. */ - __u8 ac_nice; /* task_nice */ - - /* The name of the command that started this task. */ - char ac_comm[TS_COMM_LEN]; /* Command name */ - - /* The scheduling discipline as set in task->policy field. */ - __u8 ac_sched; /* Scheduling discipline */ - - __u8 ac_pad[3]; - __u32 ac_uid; /* User ID */ - __u32 ac_gid; /* Group ID */ - __u32 ac_pid; /* Process ID */ - __u32 ac_ppid; /* Parent process ID */ - - /* The time when a task begins, in [secs] since 1970. */ - __u32 ac_btime; /* Begin time [sec since 1970] */ - - /* The elapsed time of a task, in [usec]. */ - __u64 ac_etime; /* Elapsed time [usec] */ - - /* The user CPU time of a task, in [usec]. */ - __u64 ac_utime; /* User CPU time [usec] */ - - /* The system CPU time of a task, in [usec]. */ - __u64 ac_stime; /* System CPU time [usec] */ - - /* The minor page fault count of a task, as set in task->min_flt. */ - __u64 ac_minflt; /* Minor Page Fault Count */ - - /* The major page fault count of a task, as set in task->maj_flt. */ - __u64 ac_majflt; /* Major Page Fault Count */ - - -2) Delay accounting fields: - /* Delay accounting fields start - * - * All values, until the comment "Delay accounting fields end" are - * available only if delay accounting is enabled, even though the last - * few fields are not delays - * - * xxx_count is the number of delay values recorded - * xxx_delay_total is the corresponding cumulative delay in nanoseconds - * - * xxx_delay_total wraps around to zero on overflow - * xxx_count incremented regardless of overflow - */ - - /* Delay waiting for cpu, while runnable - * count, delay_total NOT updated atomically - */ - __u64 cpu_count; - __u64 cpu_delay_total; - - /* Following four fields atomically updated using task->delays->lock */ - - /* Delay waiting for synchronous block I/O to complete - * does not account for delays in I/O submission - */ - __u64 blkio_count; - __u64 blkio_delay_total; - - /* Delay waiting for page fault I/O (swap in only) */ - __u64 swapin_count; - __u64 swapin_delay_total; - - /* cpu "wall-clock" running time - * On some architectures, value will adjust for cpu time stolen - * from the kernel in involuntary waits due to virtualization. - * Value is cumulative, in nanoseconds, without a corresponding count - * and wraps around to zero silently on overflow - */ - __u64 cpu_run_real_total; - - /* cpu "virtual" running time - * Uses time intervals seen by the kernel i.e. no adjustment - * for kernel's involuntary waits due to virtualization. - * Value is cumulative, in nanoseconds, without a corresponding count - * and wraps around to zero silently on overflow - */ - __u64 cpu_run_virtual_total; - /* Delay accounting fields end */ - /* version 1 ends here */ - - -3) Extended accounting fields - /* Extended accounting fields start */ - - /* Accumulated RSS usage in duration of a task, in MBytes-usecs. - * The current rss usage is added to this counter every time - * a tick is charged to a task's system time. So, at the end we - * will have memory usage multiplied by system time. Thus an - * average usage per system time unit can be calculated. - */ - __u64 coremem; /* accumulated RSS usage in MB-usec */ - - /* Accumulated virtual memory usage in duration of a task. - * Same as acct_rss_mem1 above except that we keep track of VM usage. - */ - __u64 virtmem; /* accumulated VM usage in MB-usec */ - - /* High watermark of RSS usage in duration of a task, in KBytes. */ - __u64 hiwater_rss; /* High-watermark of RSS usage */ - - /* High watermark of VM usage in duration of a task, in KBytes. */ - __u64 hiwater_vm; /* High-water virtual memory usage */ - - /* The following four fields are I/O statistics of a task. */ - __u64 read_char; /* bytes read */ - __u64 write_char; /* bytes written */ - __u64 read_syscalls; /* read syscalls */ - __u64 write_syscalls; /* write syscalls */ - - /* Extended accounting fields end */ - -} diff --git a/trunk/Documentation/aoe/todo.txt b/trunk/Documentation/aoe/todo.txt index c09dfad4aed8..7fee1e1165bc 100644 --- a/trunk/Documentation/aoe/todo.txt +++ b/trunk/Documentation/aoe/todo.txt @@ -7,7 +7,7 @@ not been observed, but it would be nice to eliminate any potential for deadlock under memory pressure. Because ATA over Ethernet is not fragmented by the kernel's IP code, -the destructor member of the struct sk_buff is available to the aoe +the destructore member of the struct sk_buff is available to the aoe driver. By using a mempool for allocating all but the first few sk_buffs, and by registering a destructor, we should be able to efficiently allocate sk_buffs without introducing any potential for diff --git a/trunk/Documentation/arm/SA1100/serial_UART b/trunk/Documentation/arm/SA1100/serial_UART index a63966f1d083..aea2e91ca0ef 100644 --- a/trunk/Documentation/arm/SA1100/serial_UART +++ b/trunk/Documentation/arm/SA1100/serial_UART @@ -24,8 +24,8 @@ The SA1100 serial port had its major/minor numbers officially assigned: > 7 = /dev/cusa2 Callout device for ttySA2 > -You must create those inodes in /dev on the root filesystem used -by your SA1100-based device: +If you're not using devfs, you must create those inodes in /dev +on the root filesystem used by your SA1100-based device: mknod ttySA0 c 204 5 mknod ttySA1 c 204 6 diff --git a/trunk/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt b/trunk/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt index 26422f0f9080..000e3d7a78b2 100644 --- a/trunk/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt +++ b/trunk/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt @@ -38,7 +38,7 @@ MTD --- The NAND and NOR support has been merged from the linux-mtd project. - Any problems, see http://www.linux-mtd.infradead.org/ for more + Any prolbems, see http://www.linux-mtd.infradead.org/ for more information or up-to-date versions of linux-mtd. diff --git a/trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt b/trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt index 8caea8c237ee..0822764ec270 100644 --- a/trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt +++ b/trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt @@ -24,7 +24,7 @@ Headers header include/asm-arm/arch-s3c2410/hardware.h which can be included by #include - A useful amount of documentation can be found in the hardware + A useful ammount of documentation can be found in the hardware header on how the GPIO functions (and others) work. Whilst a number of these functions do make some checks on what diff --git a/trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt b/trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt index dda7ecdde87b..3e46d2a31158 100644 --- a/trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt +++ b/trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt @@ -80,7 +80,7 @@ Machines Adding New Machines ------------------- - The architecture has been designed to support as many machines as can + The archicture has been designed to support as many machines as can be configured for it in one kernel build, and any future additions should keep this in mind before altering items outside of their own machine files. diff --git a/trunk/Documentation/arm/Samsung-S3C24XX/S3C2412.txt b/trunk/Documentation/arm/Samsung-S3C24XX/S3C2412.txt index 295d971a15ed..cb82a7fc7901 100644 --- a/trunk/Documentation/arm/Samsung-S3C24XX/S3C2412.txt +++ b/trunk/Documentation/arm/Samsung-S3C24XX/S3C2412.txt @@ -80,7 +80,7 @@ RTC Watchdog -------- - The watchdog hardware is the same as the S3C2410, and is supported by + The watchdog harware is the same as the S3C2410, and is supported by the s3c2410_wdt driver. diff --git a/trunk/Documentation/block/as-iosched.txt b/trunk/Documentation/block/as-iosched.txt index e2a66f8143c5..6f47332c883d 100644 --- a/trunk/Documentation/block/as-iosched.txt +++ b/trunk/Documentation/block/as-iosched.txt @@ -99,8 +99,8 @@ contrast, many write requests may be dispatched to the disk controller at a time during a write batch. It is this characteristic that can make the anticipatory scheduler perform anomalously with controllers supporting TCQ, or with hardware striped RAID devices. Setting the antic_expire -queue parameter (see below) to zero disables this behavior, and the -anticipatory scheduler behaves essentially like the deadline scheduler. +queue paramter (see below) to zero disables this behavior, and the anticipatory +scheduler behaves essentially like the deadline scheduler. When read anticipation is enabled (antic_expire is not zero), reads are dispatched to the disk controller one at a time. diff --git a/trunk/Documentation/block/barrier.txt b/trunk/Documentation/block/barrier.txt index a272c3db8094..03971518b222 100644 --- a/trunk/Documentation/block/barrier.txt +++ b/trunk/Documentation/block/barrier.txt @@ -25,7 +25,7 @@ of the following three ways. i. For devices which have queue depth greater than 1 (TCQ devices) and support ordered tags, block layer can just issue the barrier as an ordered request and the lower level driver, controller and drive -itself are responsible for making sure that the ordering constraint is +itself are responsible for making sure that the ordering contraint is met. Most modern SCSI controllers/drives should support this. NOTE: SCSI ordered tag isn't currently used due to limitation in the @@ -42,7 +42,7 @@ iii. Devices which have queue depth of 1. This is a degenerate case of ii. Just keeping issue order suffices. Ancient SCSI controllers/drives and IDE drives are in this category. -2. Forced flushing to physical medium +2. Forced flushing to physcial medium Again, if you're not gonna do synchronization with disk drives (dang, it sounds even more appealing now!), the reason you use I/O barriers @@ -56,7 +56,7 @@ There are four cases, i. No write-back cache. Keeping requests ordered is enough. ii. Write-back cache but no flush operation. There's no way to -guarantee physical-medium commit order. This kind of devices can't to +gurantee physical-medium commit order. This kind of devices can't to I/O barriers. iii. Write-back cache and flush operation but no FUA (forced unit diff --git a/trunk/Documentation/block/biodoc.txt b/trunk/Documentation/block/biodoc.txt index 34bf8f60d8f8..f989a9e839b4 100644 --- a/trunk/Documentation/block/biodoc.txt +++ b/trunk/Documentation/block/biodoc.txt @@ -135,7 +135,7 @@ Some new queue property settings: Sets two variables that limit the size of the request. - The request queue's max_sectors, which is a soft size in - units of 512 byte sectors, and could be dynamically varied + in units of 512 byte sectors, and could be dynamically varied by the core kernel. - The request queue's max_hw_sectors, which is a hard limit @@ -783,7 +783,7 @@ all the outstanding requests. There's a third helper to do that: blk_queue_invalidate_tags(request_queue_t *q) - Clear the internal block tag queue and re-add all the pending requests + Clear the internal block tag queue and readd all the pending requests to the request queue. The driver will receive them again on the next request_fn run, just like it did the first time it encountered them. @@ -890,7 +890,7 @@ Aside: Kvec i/o: - Ben LaHaise's aio code uses a slightly different structure instead + Ben LaHaise's aio code uses a slighly different structure instead of kiobufs, called a kvec_cb. This contains an array of tuples (very much like the networking code), together with a callback function and data pointer. This is embedded into a brw_cb structure when passed @@ -988,7 +988,7 @@ elevator_exit_fn Allocate and free any elevator specific storage for a queue. 4.2 Request flows seen by I/O schedulers -All requests seen by I/O schedulers strictly follow one of the following three +All requests seens by I/O schedulers strictly follow one of the following three flows. set_req_fn -> @@ -1203,6 +1203,6 @@ temporarily map a bio into the virtual address space. and Linus' comments - Jan 2001) 9.2 Discussions about kiobuf and bh design on lkml between sct, linus, alan et al - Feb-March 2001 (many of the initial thoughts that led to bio were -brought up in this discussion thread) +brought up in this discusion thread) 9.3 Discussions on mempool on lkml - Dec 2001. diff --git a/trunk/Documentation/block/deadline-iosched.txt b/trunk/Documentation/block/deadline-iosched.txt index be08ffd1e9b8..c918b3a6022d 100644 --- a/trunk/Documentation/block/deadline-iosched.txt +++ b/trunk/Documentation/block/deadline-iosched.txt @@ -23,11 +23,11 @@ you can do so by typing: read_expire (in ms) ----------- -The goal of the deadline io scheduler is to attempt to guarantee a start +The goal of the deadline io scheduler is to attempt to guarentee a start service time for a request. As we focus mainly on read latencies, this is tunable. When a read request first enters the io scheduler, it is assigned a deadline that is the current time + the read_expire value in units of -milliseconds. +miliseconds. write_expire (in ms) diff --git a/trunk/Documentation/cciss.txt b/trunk/Documentation/cciss.txt index f74affe5c829..9c629ffa0e58 100644 --- a/trunk/Documentation/cciss.txt +++ b/trunk/Documentation/cciss.txt @@ -80,7 +80,7 @@ the /proc filesystem entry which the "block" side of the driver creates as the SCSI core may not yet be initialized (because the driver is a block driver) and attempting to register it with the SCSI core in such a case would cause a hang. This is best done via an initialization script -(typically in /etc/init.d, but could vary depending on distribution). +(typically in /etc/init.d, but could vary depending on distibution). For example: for x in /proc/driver/cciss/cciss[0-9]* @@ -152,7 +152,7 @@ side during the SCSI error recovery process, the cciss driver only implements the first two of these actions, aborting the command, and resetting the device. Additionally, most tape drives will not oblige in aborting commands, and sometimes it appears they will not even -obey a reset command, though in most circumstances they will. In +obey a reset coommand, though in most circumstances they will. In the case that the command cannot be aborted and the device cannot be reset, the device will be set offline. diff --git a/trunk/Documentation/computone.txt b/trunk/Documentation/computone.txt index 5e2a0c76bfa0..b1cf59b84d97 100644 --- a/trunk/Documentation/computone.txt +++ b/trunk/Documentation/computone.txt @@ -199,6 +199,30 @@ boxes this will leave gaps in the sequence of device names. ip2mkdev uses Linux tty naming conventions: ttyF0 - ttyF255 for normal devices, and cuf0 - cuf255 for callout devices. +If you are using devfs, existing devices are automatically created within +the devfs name space. Normal devices will be tts/F0 - tts/F255 and callout +devices will be cua/F0 - cua/F255. With devfs installed, ip2mkdev will +create symbolic links in /dev from the old conventional names to the newer +devfs names as follows: + + /dev/ip2ipl[n] -> /dev/ip2/ipl[n] n = 0 - 3 + /dev/ip2stat[n] -> /dev/ip2/stat[n] n = 0 - 3 + /dev/ttyF[n] -> /dev/tts/F[n] n = 0 - 255 + /dev/cuf[n] -> /dev/cua/F[n] n = 0 - 255 + +Only devices for existing ports and boards will be created. + +IMPORTANT NOTE: The naming convention used for devfs by this driver +was changed from 1.2.12 to 1.2.13. The old naming convention was to +use ttf/%d for the tty device and cuf/%d for the cua device. That +has been changed to conform to an agreed-upon standard of placing +all the tty devices under tts. The device names are now tts/F%d for +the tty device and cua/F%d for the cua devices. If you were using +the older devfs names, you must update for the newer convention. + +You do not need to run ip2mkdev if you are using devfs and only want to +use the devfs native device names. + 4. USING THE DRIVERS @@ -232,15 +256,57 @@ cut out and run as "ip2mkdev" to create the necessary device files. To use the ip2mkdev script, you must have procfs enabled and the proc file system mounted on /proc. +You do not need to run ip2mkdev if you are using devfs and only want to +use the devfs native device names. + + +6. DEVFS + +DEVFS is the DEVice File System available as an add on package for the +2.2.x kernels and available as a configuration option in 2.3.46 and higher. +Devfs allows for the automatic creation and management of device names +under control of the device drivers themselves. The Devfs namespace is +hierarchical and reduces the clutter present in the normal flat /dev +namespace. Devfs names and conventional device names may be intermixed. +A userspace daemon, devfsd, exists to allow for automatic creation and +management of symbolic links from the devfs name space to the conventional +names. More details on devfs can be found on the DEVFS home site at + or in the file kernel +documentation files, .../linux/Documentation/filesystems/devfs/README. + +If you are using devfs, existing devices are automatically created within +the devfs name space. Normal devices will be tts/F0 - tts/F255 and callout +devices will be cua/F0 - cua/F255. With devfs installed, ip2mkdev will +create symbolic links in /dev from the old conventional names to the newer +devfs names as follows: + + /dev/ip2ipl[n] -> /dev/ip2/ipl[n] n = 0 - 3 + /dev/ip2stat[n] -> /dev/ip2/stat[n] n = 0 - 3 + /dev/ttyF[n] -> /dev/tts/F[n] n = 0 - 255 + /dev/cuf[n] -> /dev/cua/F[n] n = 0 - 255 + +Only devices for existing ports and boards will be created. + +IMPORTANT NOTE: The naming convention used for devfs by this driver +was changed from 1.2.12 to 1.2.13. The old naming convention was to +use ttf/%d for the tty device and cuf/%d for the cua device. That +has been changed to conform to an agreed-upon standard of placing +all the tty devices under tts. The device names are now tts/F%d for +the tty device and cua/F%d for the cua devices. If you were using +the older devfs names, you must update for the newer convention. + +You do not need to run ip2mkdev if you are using devfs and only want to +use the devfs native device names. + -6. NOTES +7. NOTES This is a release version of the driver, but it is impossible to test it in all configurations of Linux. If there is any anomalous behaviour that does not match the standard serial port's behaviour please let us know. -7. ip2mkdev shell script +8. ip2mkdev shell script Previously, this script was simply attached here. It is now attached as a shar archive to make it easier to extract the script from the documentation. diff --git a/trunk/Documentation/cpu-freq/cpufreq-stats.txt b/trunk/Documentation/cpu-freq/cpufreq-stats.txt index 53d62c1e1c94..6a82948ff4bd 100644 --- a/trunk/Documentation/cpu-freq/cpufreq-stats.txt +++ b/trunk/Documentation/cpu-freq/cpufreq-stats.txt @@ -1,5 +1,5 @@ - CPU frequency and voltage scaling statistics in the Linux(TM) kernel + CPU frequency and voltage scaling statictics in the Linux(TM) kernel L i n u x c p u f r e q - s t a t s d r i v e r @@ -18,8 +18,8 @@ Contents 1. Introduction cpufreq-stats is a driver that provices CPU frequency statistics for each CPU. -These statistics are provided in /sysfs as a bunch of read_only interfaces. This -interface (when configured) will appear in a separate directory under cpufreq +This statistics is provided in /sysfs as a bunch of read_only interfaces. This +interface (when configured) will appear in a seperate directory under cpufreq in /sysfs (/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU. Various statistics will form read_only files under this directory. @@ -53,7 +53,7 @@ drwxr-xr-x 3 root root 0 May 14 15:58 .. This gives the amount of time spent in each of the frequencies supported by this CPU. The cat output will have "