From: Linus Torvalds Date: Wed, 4 Oct 2006 16:06:16 +0000 (-0700) Subject: Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6 X-Git-Tag: v2.6.19-rc1~32 X-Git-Url: https://err.no/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4a61f17378c2cdd9bd8f34ef8bd7422861d0c1f1;hp=7ecdb70a0ea436c06540140242bfac6ac3babfc0;p=linux-2.6 Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6 * git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6: (292 commits) [GFS2] Fix endian bug for de_type [GFS2] Initialize SELinux extended attributes at inode creation time. [GFS2] Move logging code into log.c (mostly) [GFS2] Mark nlink cleared so VFS sees it happen [GFS2] Two redundant casts removed [GFS2] Remove uneeded endian conversion [GFS2] Remove duplicate sb reading code [GFS2] Mark metadata reads for blktrace [GFS2] Remove iflags.h, use FS_ [GFS2] Fix code style/indent in ops_file.c [GFS2] streamline-generic_file_-interfaces-and-filemap gfs fix [GFS2] Remove readv/writev methods and use aio_read/aio_write instead (gfs bits) [GFS2] inode-diet: Eliminate i_blksize from the inode structure [GFS2] inode_diet: Replace inode.u.generic_ip with inode.i_private (gfs) [GFS2] Fix typo in last patch [GFS2] Fix direct i/o logic in filemap.c [GFS2] Fix bug in Makefiles for lock modules [GFS2] Remove (extra) fs_subsys declaration [GFS2/DLM] Fix trailing whitespace [GFS2] Tidy up meta_io code ... --- diff --git a/CREDITS b/CREDITS index 2aa8f6d41c..5329ead9c6 100644 --- a/CREDITS +++ b/CREDITS @@ -34,6 +34,7 @@ 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 @@ -202,6 +203,7 @@ 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 @@ -444,6 +446,7 @@ 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 @@ -633,6 +636,7 @@ 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 @@ -951,6 +955,12 @@ 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 @@ -2003,6 +2013,7 @@ 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 @@ -2172,6 +2183,7 @@ 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 @@ -2228,6 +2240,12 @@ 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 @@ -2969,6 +2987,10 @@ 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. @@ -3281,6 +3303,12 @@ 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/ @@ -3652,7 +3680,7 @@ S: Portland, OR S: USA N: Michal Wronski -E: Michal.Wronski@motorola.com +E: michal.wronski@gmail.com D: POSIX message queues fs (with K. Benedyczak) S: Krakow S: Poland diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt index 63392c9132..028614cdd0 100644 --- a/Documentation/DMA-mapping.txt +++ b/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 a call to +The query for consistent allocations is performed via 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 can not perform DMA properly on +If it returns non-zero, your device cannot 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/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 6d4b1ef5b6..2b5ac60494 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -158,6 +158,7 @@ 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 @@ -325,8 +326,13 @@ X!Ekernel/module.c !Ekernel/irq/manage.c + DMA Channels +!Ekernel/dma.c + + Resources Management !Ikernel/resource.c +!Ekernel/resource.c MTRR Handling diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl index 065e8dc23e..07a635590b 100644 --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl @@ -14,7 +14,7 @@ - 2003-2005 + 2003-2006 Jeff Garzik @@ -1400,7 +1400,7 @@ and other resources, etc. When it's known that HBA is in ready state but ATA/ATAPI - device in in unknown state, reset only device. + device is in unknown state, reset only device. diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl index 3608472d7b..143e5ff7de 100644 --- a/Documentation/DocBook/usb.tmpl +++ b/Documentation/DocBook/usb.tmpl @@ -314,8 +314,7 @@ 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; but only devices with kernel drivers - show up in devfs. + not it has a kernel driver. @@ -741,7 +740,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param) Synchronous I/O Support Synchronous requests involve the kernel blocking - until until the user mode request completes, either by + 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/Documentation/DocBook/writing_usb_driver.tmpl b/Documentation/DocBook/writing_usb_driver.tmpl index 008a341234..07cd34c194 100644 --- a/Documentation/DocBook/writing_usb_driver.tmpl +++ b/Documentation/DocBook/writing_usb_driver.tmpl @@ -224,13 +224,8 @@ 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. The driver also unregisters - itself from the devfs subsystem with the call: + pending urbs that are in the USB system. - -/* 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/Documentation/IPMI.txt b/Documentation/IPMI.txt index 7756e09ea7..0e3924ecd7 100644 --- a/Documentation/IPMI.txt +++ b/Documentation/IPMI.txt @@ -364,6 +364,7 @@ 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. @@ -409,7 +410,13 @@ 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. -When compiled into the kernel, the addresses can be specified on the +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 kernel command line as: ipmi_si.type=,... @@ -419,6 +426,7 @@ 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. @@ -460,12 +468,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 compilant BMC on the SMBus can cause devices +Discovering the IPMI compliant 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 adrress range will not be used when a smb_addr +parameter. The default address 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/Documentation/MSI-HOWTO.txt b/Documentation/MSI-HOWTO.txt index 3ec6c720b0..c70306abb7 100644 --- a/Documentation/MSI-HOWTO.txt +++ b/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 pupulated in the system. +z = The number of MSI-X capable devices populated in the system. This policy ensures that maximum (x - y) is distributed evenly among MSI-X capable devices. diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 1d50cf0c90..f4dffadbcb 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -221,3 +221,41 @@ 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/Documentation/RCU/rcu.txt b/Documentation/RCU/rcu.txt index 02e27bf1d3..f84407cba8 100644 --- a/Documentation/RCU/rcu.txt +++ b/Documentation/RCU/rcu.txt @@ -45,7 +45,8 @@ 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", - "synchronize_rcu", and "synchronize_net". + "srcu_read_lock", "srcu_read_unlock", "synchronize_rcu", + "synchronize_net", and "synchronize_srcu". o What guidelines should I follow when writing code that uses RCU? diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt index a494859160..25a3c3f7d3 100644 --- a/Documentation/RCU/torture.txt +++ b/Documentation/RCU/torture.txt @@ -28,6 +28,15 @@ 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. @@ -44,9 +53,12 @@ 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_bh" for the rcu_read_lock_bh() API, and "srcu" - for the "srcu_read_lock()" API. +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(). verbose Enable debug printk()s. Default is disabled. @@ -118,6 +130,21 @@ 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/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 318df44259..e0d6d99b8f 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/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 synchonize_rcu() was +critical sections that were in progress before synchronize_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 -from a reader-writer lock to a simple spinlock, and a synchronize_rcu() +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,6 +778,8 @@ 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: @@ -804,6 +806,7 @@ RCU grace period: synchronize_net synchronize_sched synchronize_rcu + synchronize_srcu call_rcu call_rcu_bh diff --git a/Documentation/aoe/todo.txt b/Documentation/aoe/todo.txt index 7fee1e1165..c09dfad4ae 100644 --- a/Documentation/aoe/todo.txt +++ b/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 destructore member of the struct sk_buff is available to the aoe +the destructor 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/Documentation/arm/SA1100/serial_UART b/Documentation/arm/SA1100/serial_UART index aea2e91ca0..a63966f1d0 100644 --- a/Documentation/arm/SA1100/serial_UART +++ b/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 > -If you're not using devfs, you must create those inodes in /dev -on the root filesystem used by your SA1100-based device: +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/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt b/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt index 000e3d7a78..26422f0f90 100644 --- a/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt +++ b/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 prolbems, see http://www.linux-mtd.infradead.org/ for more + Any problems, see http://www.linux-mtd.infradead.org/ for more information or up-to-date versions of linux-mtd. diff --git a/Documentation/arm/Samsung-S3C24XX/GPIO.txt b/Documentation/arm/Samsung-S3C24XX/GPIO.txt index 0822764ec2..8caea8c237 100644 --- a/Documentation/arm/Samsung-S3C24XX/GPIO.txt +++ b/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 ammount of documentation can be found in the hardware + A useful amount 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/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt index 3e46d2a311..dda7ecdde8 100644 --- a/Documentation/arm/Samsung-S3C24XX/Overview.txt +++ b/Documentation/arm/Samsung-S3C24XX/Overview.txt @@ -80,7 +80,7 @@ Machines Adding New Machines ------------------- - The archicture has been designed to support as many machines as can + The architecture 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/Documentation/arm/Samsung-S3C24XX/S3C2412.txt b/Documentation/arm/Samsung-S3C24XX/S3C2412.txt index cb82a7fc79..295d971a15 100644 --- a/Documentation/arm/Samsung-S3C24XX/S3C2412.txt +++ b/Documentation/arm/Samsung-S3C24XX/S3C2412.txt @@ -80,7 +80,7 @@ RTC Watchdog -------- - The watchdog harware is the same as the S3C2410, and is supported by + The watchdog hardware is the same as the S3C2410, and is supported by the s3c2410_wdt driver. diff --git a/Documentation/block/as-iosched.txt b/Documentation/block/as-iosched.txt index 6f47332c88..e2a66f8143 100644 --- a/Documentation/block/as-iosched.txt +++ b/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 paramter (see below) to zero disables this behavior, and the anticipatory -scheduler behaves essentially like the deadline scheduler. +queue parameter (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/Documentation/block/barrier.txt b/Documentation/block/barrier.txt index 03971518b2..a272c3db80 100644 --- a/Documentation/block/barrier.txt +++ b/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 contraint is +itself are responsible for making sure that the ordering constraint 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 physcial medium +2. Forced flushing to physical 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 -gurantee physical-medium commit order. This kind of devices can't to +guarantee 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/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index f989a9e839..34bf8f60d8 100644 --- a/Documentation/block/biodoc.txt +++ b/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 - in units of 512 byte sectors, and could be dynamically varied + 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 readd all the pending requests + Clear the internal block tag queue and re-add 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 slighly different structure instead + Ben LaHaise's aio code uses a slightly 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 seens by I/O schedulers strictly follow one of the following three +All requests seen 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 discusion thread) +brought up in this discussion thread) 9.3 Discussions on mempool on lkml - Dec 2001. diff --git a/Documentation/block/deadline-iosched.txt b/Documentation/block/deadline-iosched.txt index c918b3a602..be08ffd1e9 100644 --- a/Documentation/block/deadline-iosched.txt +++ b/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 guarentee a start +The goal of the deadline io scheduler is to attempt to guarantee 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 -miliseconds. +milliseconds. write_expire (in ms) diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt index 9c629ffa0e..f74affe5c8 100644 --- a/Documentation/cciss.txt +++ b/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 distibution). +(typically in /etc/init.d, but could vary depending on distribution). 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 coommand, though in most circumstances they will. In +obey a reset command, 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/Documentation/computone.txt b/Documentation/computone.txt index b1cf59b84d..5e2a0c76bf 100644 --- a/Documentation/computone.txt +++ b/Documentation/computone.txt @@ -199,30 +199,6 @@ 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 @@ -256,57 +232,15 @@ 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. - -7. NOTES +6. 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. -8. ip2mkdev shell script +7. 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/Documentation/cpu-freq/cpufreq-stats.txt b/Documentation/cpu-freq/cpufreq-stats.txt index 6a82948ff4..53d62c1e1c 100644 --- a/Documentation/cpu-freq/cpufreq-stats.txt +++ b/Documentation/cpu-freq/cpufreq-stats.txt @@ -1,5 +1,5 @@ - CPU frequency and voltage scaling statictics in the Linux(TM) kernel + CPU frequency and voltage scaling statistics 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. -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 +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 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 "