Merge git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial
* git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial: (39 commits) Add missing maintainer countries in CREDITS Fix bytes <-> kilobytes typo in Kconfig for ramdisk fix a typo in Documentation/pi-futex.txt BUG_ON conversion for fs/xfs/ BUG_ON() conversion in fs/nfsd/ BUG_ON conversion for fs/reiserfs BUG_ON cleanups in arch/i386 BUG_ON cleanup in drivers/net/tokenring/ BUG_ON cleanup for drivers/md/ kerneldoc-typo in led-class.c debugfs: spelling fix rcutorture: Fix incorrect description of default for nreaders parameter parport: Remove space in function calls Michal Wronski: update contact info Spelling fix: "control" instead of "cotrol" reboot parameter in Documentation/kernel-parameters.txt Fix copy&waste bug in comment in scripts/kernel-doc remove duplicate "until" from kernel/workqueue.c ite_gpio fix tabbage fix file specification in comments ... Fixed trivial path conflicts due to removed files: arch/mips/dec/boot/decstation.c, drivers/char/ite_gpio.c
This commit is contained in:
		
						commit
						708e16892e
					
				
							
								
								
									
										8
									
								
								CREDITS
									
									
									
									
									
								
							
							
						
						
									
										8
									
								
								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 | ||||
| @ -2009,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 | ||||
| @ -2178,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 | ||||
| @ -3658,7 +3664,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 | ||||
|  | ||||
| @ -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. | ||||
| 
 | ||||
|  | ||||
| @ -1400,7 +1400,7 @@ and other resources, etc. | ||||
| 	<listitem> | ||||
| 	<para> | ||||
| 	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. | ||||
| 	</para> | ||||
| 	</listitem> | ||||
| 
 | ||||
|  | ||||
| @ -314,8 +314,7 @@ | ||||
| 	<emphasis>usbdevfs</emphasis> although it wasn't solving what | ||||
| 	<emphasis>devfs</emphasis> 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. | ||||
| 	</para> | ||||
| 
 | ||||
| 	<sect1> | ||||
| @ -741,7 +740,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param) | ||||
| 		<title>Synchronous I/O Support</title> | ||||
| 
 | ||||
| 		<para>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 | ||||
|  | ||||
| @ -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. | ||||
|   </para> | ||||
|   <programlisting> | ||||
| /* remove our devfs node */ | ||||
| devfs_unregister(skel->devfs); | ||||
|   </programlisting> | ||||
|   <para> | ||||
|      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 | ||||
|  | ||||
| @ -468,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 | ||||
|  | ||||
| @ -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. | ||||
| 
 | ||||
|  | ||||
| @ -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 | ||||
|  | ||||
| @ -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 | ||||
|  | ||||
| @ -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 | ||||
|  | ||||
| @ -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. | ||||
| 
 | ||||
| 
 | ||||
|  | ||||
| @ -24,7 +24,7 @@ Headers | ||||
|   header include/asm-arm/arch-s3c2410/hardware.h which can be | ||||
|   included by #include <asm/arch/hardware.h> | ||||
| 
 | ||||
|   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 | ||||
|  | ||||
| @ -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. | ||||
|  | ||||
| @ -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. | ||||
| 
 | ||||
| 
 | ||||
|  | ||||
| @ -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. | ||||
|  | ||||
| @ -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 | ||||
|  | ||||
| @ -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 <page, offset, len> | ||||
|   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. | ||||
| 
 | ||||
|  | ||||
| @ -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) | ||||
|  | ||||
| @ -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. | ||||
| 
 | ||||
|  | ||||
| @ -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 | ||||
| <http://www.atnf.csiro.au/~rgooch/linux/> 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. | ||||
|  | ||||
| @ -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 (<sysfs root>/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 "<frequency> <time>" pair in each line, which | ||||
| will mean this CPU spent <time> usertime units of time at <frequency>. Output | ||||
| will have one line for each of the supported freuencies. usertime units here  | ||||
| will have one line for each of the supported frequencies. usertime units here  | ||||
| is 10mS (similar to other time exported in /proc). | ||||
| 
 | ||||
| -------------------------------------------------------------------------------- | ||||
| @ -115,7 +115,7 @@ basic statistics which includes time_in_state and total_trans. | ||||
| 
 | ||||
| "CPU frequency translation statistics details" (CONFIG_CPU_FREQ_STAT_DETAILS) | ||||
| provides fine grained cpufreq stats by trans_table. The reason for having a | ||||
| seperate config option for trans_table is: | ||||
| separate config option for trans_table is: | ||||
| - trans_table goes against the traditional /sysfs rule of one value per | ||||
|   interface. It provides a whole bunch of value in a 2 dimensional matrix | ||||
|   form. | ||||
|  | ||||
| @ -57,7 +57,7 @@ selected for each specific use. | ||||
| 
 | ||||
| Basically, it's the following flow graph: | ||||
| 
 | ||||
| CPU can be set to switch independetly	 |	   CPU can only be set | ||||
| CPU can be set to switch independently	 |	   CPU can only be set | ||||
|       within specific "limits"		 |       to specific frequencies | ||||
| 
 | ||||
|                                  "CPUfreq policy" | ||||
| @ -109,7 +109,7 @@ directory. | ||||
| 2.4 Ondemand | ||||
| ------------ | ||||
| 
 | ||||
| The CPUfreq govenor "ondemand" sets the CPU depending on the | ||||
| The CPUfreq governor "ondemand" sets the CPU depending on the | ||||
| current usage. To do this the CPU must have the capability to | ||||
| switch the frequency very quickly.  There are a number of sysfs file | ||||
| accessible parameters: | ||||
| @ -137,11 +137,11 @@ have to be made in a row before the CPU frequency is actually lower. | ||||
| If set to '1' then the frequency decreases as quickly as it increases, | ||||
| if set to '2' it decreases at half the rate of the increase. | ||||
| 
 | ||||
| ignore_nice_load: this parameter takes a value of '0' or '1', when set | ||||
| to '0' (its default) then all processes are counted towards towards the | ||||
| 'cpu utilisation' value.   When set to '1' then processes that are | ||||
| ignore_nice_load: this parameter takes a value of '0' or '1'. When | ||||
| set to '0' (its default), all processes are counted towards the | ||||
| 'cpu utilisation' value.  When set to '1', the processes that are | ||||
| run with a 'nice' value will not count (and thus be ignored) in the | ||||
| overal usage calculation.  This is useful if you are running a CPU | ||||
| overall usage calculation.  This is useful if you are running a CPU | ||||
| intensive calculation on your laptop that you do not care how long it | ||||
| takes to complete as you can 'nice' it and prevent it from taking part | ||||
| in the deciding process of whether to increase your CPU frequency. | ||||
|  | ||||
| @ -26,7 +26,7 @@ The type of **_id is int. | ||||
| The type of siblings is cpumask_t. | ||||
| 
 | ||||
| To be consistent on all architectures, the 4 attributes should have | ||||
| deafult values if their values are unavailable. Below is the rule. | ||||
| default values if their values are unavailable. Below is the rule. | ||||
| 1) physical_package_id: If cpu has no physical package id, -1 is the | ||||
| default value. | ||||
| 2) core_id: If cpu doesn't support multi-core, its core id is 0. | ||||
|  | ||||
| @ -4,7 +4,7 @@ for updating BIOS images on Dell servers and desktops. | ||||
| 
 | ||||
| Scope: | ||||
| This document discusses the functionality of the rbu driver only. | ||||
| It does not cover the support needed from aplications to enable the BIOS to | ||||
| It does not cover the support needed from applications to enable the BIOS to | ||||
| update itself with the image downloaded in to the memory. | ||||
| 
 | ||||
| Overview: | ||||
| @ -16,8 +16,8 @@ OpenManage and Dell Update packages (DUP). | ||||
| Libsmbios can also be used to update BIOS on Dell systems go to | ||||
| http://linux.dell.com/libsmbios/ for details. | ||||
| 
 | ||||
| Dell_RBU driver supports BIOS update using the monilothic image and packetized | ||||
| image methods. In case of moniolithic the driver allocates a contiguous chunk | ||||
| Dell_RBU driver supports BIOS update using the monolithic image and packetized | ||||
| image methods. In case of monolithic the driver allocates a contiguous chunk | ||||
| of physical pages having the BIOS image. In case of packetized the app | ||||
| using the driver breaks the image in to packets of fixed sizes and the driver | ||||
| would place each packet in contiguous physical memory. The driver also | ||||
| @ -41,7 +41,7 @@ The driver supports two types of update mechanism; monolithic and packetized. | ||||
| These update mechanism depends upon the BIOS currently running on the system. | ||||
| Most of the Dell systems support a monolithic update where the BIOS image is | ||||
| copied to a single contiguous block of physical memory. | ||||
| In case of packet mechanism the single memory can be broken in smaller chuks | ||||
| In case of packet mechanism the single memory can be broken in smaller chunks | ||||
| of contiguous memory and the BIOS image is scattered in these packets. | ||||
| 
 | ||||
| By default the driver uses monolithic memory for the update type. This can be | ||||
| @ -52,11 +52,11 @@ echo packet > /sys/devices/platform/dell_rbu/image_type | ||||
| In packet update mode the packet size has to be given before any packets can | ||||
| be downloaded. It is done as below | ||||
| echo XXXX > /sys/devices/platform/dell_rbu/packet_size | ||||
| In the packet update mechanism, the user neesd to create a new file having | ||||
| In the packet update mechanism, the user needs to create a new file having | ||||
| packets of data arranged back to back. It can be done as follows | ||||
| The user creates packets header, gets the chunk of the BIOS image and | ||||
| placs it next to the packetheader; now, the packetheader + BIOS image chunk | ||||
| added to geather should match the specified packet_size. This makes one | ||||
| places it next to the packetheader; now, the packetheader + BIOS image chunk | ||||
| added together should match the specified packet_size. This makes one | ||||
| packet, the user needs to create more such packets out of the entire BIOS | ||||
| image file and then arrange all these packets back to back in to one single | ||||
| file. | ||||
| @ -93,8 +93,8 @@ read back the image downloaded. | ||||
| NOTE: | ||||
| This driver requires a patch for firmware_class.c which has the modified | ||||
| request_firmware_nowait function. | ||||
| Also after updating the BIOS image an user mdoe application neeeds to execute | ||||
| code which message the BIOS update request to the BIOS. So on the next reboot | ||||
| the BIOS knows about the new image downloaded and it updates it self. | ||||
| Also don't unload the rbu drive if the image has to be updated. | ||||
| Also after updating the BIOS image a user mode application needs to execute | ||||
| code which sends the BIOS update request to the BIOS. So on the next reboot | ||||
| the BIOS knows about the new image downloaded and it updates itself. | ||||
| Also don't unload the rbu driver if the image has to be updated. | ||||
| 
 | ||||
|  | ||||
| @ -2005,7 +2005,7 @@ Your cooperation is appreciated. | ||||
| 116 char	Advanced Linux Sound Driver (ALSA) | ||||
| 
 | ||||
| 116 block       MicroMemory battery backed RAM adapter (NVRAM) | ||||
|                 Supports 16 boards, 15 paritions each. | ||||
|                 Supports 16 boards, 15 partitions each. | ||||
|                 Requested by neilb at cse.unsw.edu.au. | ||||
| 
 | ||||
| 		 0 = /dev/umem/d0      Whole of first board | ||||
| @ -3094,7 +3094,7 @@ Your cooperation is appreciated. | ||||
| 		This major is reserved to assist the expansion to a | ||||
| 		larger number space.  No device nodes with this major | ||||
| 		should ever be created on the filesystem. | ||||
| 		(This is probaly not true anymore, but I'll leave it | ||||
| 		(This is probably not true anymore, but I'll leave it | ||||
| 		for now /Torben) | ||||
| 
 | ||||
| ---LARGE MAJORS!!!!!--- | ||||
| @ -3205,7 +3205,7 @@ for a session; this includes virtual consoles, serial ports, and | ||||
| pseudoterminals (PTYs). | ||||
| 
 | ||||
| All terminal devices share a common set of capabilities known as line | ||||
| diciplines; these include the common terminal line dicipline as well | ||||
| disciplines; these include the common terminal line discipline as well | ||||
| as SLIP and PPP modes. | ||||
| 
 | ||||
| All terminal devices are named similarly; this section explains the | ||||
| @ -3285,7 +3285,7 @@ port TTY, for which no alternate device would exist. | ||||
| 	Pseudoterminals (PTYs) | ||||
| 
 | ||||
| Pseudoterminals, or PTYs, are used to create login sessions or provide | ||||
| other capabilities requiring a TTY line dicipline (including SLIP or | ||||
| other capabilities requiring a TTY line discipline (including SLIP or | ||||
| PPP capability) to arbitrary data-generation processes.	 Each PTY has | ||||
| a master side, named /dev/pty[p-za-e][0-9a-f], and a slave side, named | ||||
| /dev/tty[p-za-e][0-9a-f].  The kernel arbitrates the use of PTYs by | ||||
|  | ||||
| @ -12,7 +12,7 @@ device. The following device classes have been identified: | ||||
| 
 | ||||
| Each device class defines a set of semantics and a programming interface | ||||
| that devices of that class adhere to. Device drivers are the | ||||
| implemention of that programming interface for a particular device on | ||||
| implementation of that programming interface for a particular device on | ||||
| a particular bus.  | ||||
| 
 | ||||
| Device classes are agnostic with respect to what bus a device resides | ||||
|  | ||||
| @ -178,7 +178,7 @@ the driver to that device. | ||||
| 
 | ||||
| A driver's probe() may return a negative errno value to indicate that | ||||
| the driver did not bind to this device, in which case it should have | ||||
| released all reasources it allocated. | ||||
| released all resources it allocated. | ||||
| 
 | ||||
| 	int 	(*remove)	(struct device * dev); | ||||
| 
 | ||||
|  | ||||
| @ -57,7 +57,7 @@ the two. | ||||
| 
 | ||||
| The PCI bus layer freely accesses the fields of struct device. It knows about | ||||
| the structure of struct pci_dev, and it should know the structure of struct | ||||
| device. Individual PCI device drivers that have been converted the the current | ||||
| device. Individual PCI device drivers that have been converted to the current | ||||
| driver model generally do not and should not touch the fields of struct device, | ||||
| unless there is a strong compelling reason to do so. | ||||
| 
 | ||||
|  | ||||
| @ -45,9 +45,9 @@ Assumptions and Introduction | ||||
|    by  circuitry on the card and is often presented uncompressed. | ||||
|    For  a PAL TV signal encoded at a resolution of 768x576 24-bit | ||||
|    color pixels over 25 frames per second - a fair amount of data | ||||
|    is  generated and must be proceesed by the PC before it can be | ||||
|    is  generated and must be processed by the PC before it can be | ||||
|    displayed  on the video monitor screen. Some Analogue TV cards | ||||
|    for  PC's  have  onboard  MPEG2  encoders which permit the raw | ||||
|    for  PCs  have  onboard  MPEG2  encoders  which permit the raw | ||||
|    digital  data  stream  to be presented to the PC in an encoded | ||||
|    and  compressed  form  -  similar  to the form that is used in | ||||
|    Digital TV. | ||||
|  | ||||
| @ -5,7 +5,7 @@ Hardware supported by the linuxtv.org DVB drivers | ||||
|   frontends (i.e. tuner / demodulator units) used, usually without | ||||
|   changing the product name, revision number or specs. Some cards | ||||
|   are also available in versions with different frontends for | ||||
|   DVB-S/DVB-C/DVB-T. Thus the frontend drivers are listed seperately. | ||||
|   DVB-S/DVB-C/DVB-T. Thus the frontend drivers are listed separately. | ||||
| 
 | ||||
|   Note 1: There is no guarantee that every frontend driver works | ||||
|   out of the box with every card, because of different wiring. | ||||
|  | ||||
| @ -32,7 +32,7 @@ This application requires the following to function properly as of now. | ||||
| 	  descrambler to function, | ||||
| 	  eg: $ ca_zap channels.conf "TMC" | ||||
| 
 | ||||
| 	(d) Hopeflly Enjoy your favourite subscribed channel as you do with | ||||
| 	(d) Hopefully enjoy your favourite subscribed channel as you do with | ||||
| 	  a FTA card. | ||||
| 
 | ||||
| (3) Currently ca_zap, and dst_test, both are meant for demonstration | ||||
| @ -65,7 +65,7 @@ Modules that have been tested by this driver at present are | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
| With the High Level CI approach any new card with almost any random | ||||
| architecture can be implemented with this style, the definitions | ||||
| insidethe switch statement can be easily adapted for any card, thereby | ||||
| inside the switch statement can be easily adapted for any card, thereby | ||||
| eliminating the need for any additional ioctls. | ||||
| 
 | ||||
| The disadvantage is that the driver/hardware has to manage the rest. For | ||||
|  | ||||
| @ -5,7 +5,7 @@ Some very frequently asked questions about linuxtv-dvb | ||||
| 	It's not a bug, it's a feature. Because the frontends have | ||||
| 	significant power requirements (and hence get very hot), they | ||||
| 	are powered down if they are unused (i.e. if the frontend device | ||||
| 	is closed). The dvb-core.o module paramter "dvb_shutdown_timeout" | ||||
| 	is closed). The dvb-core.o module parameter "dvb_shutdown_timeout" | ||||
| 	allow you to change the timeout (default 5 seconds). Setting the | ||||
| 	timeout to 0 disables the timeout feature. | ||||
| 
 | ||||
| @ -138,7 +138,7 @@ Some very frequently asked questions about linuxtv-dvb | ||||
| 
 | ||||
| 	- v4l2-common: common functions for Video4Linux-2 drivers | ||||
| 
 | ||||
| 	- v4l1-compat: backward compatiblity layer for Video4Linux-1 legacy | ||||
| 	- v4l1-compat: backward compatibility layer for Video4Linux-1 legacy | ||||
| 	  applications | ||||
| 
 | ||||
| 	- dvb-core: DVB core module. This provides you with the | ||||
| @ -153,7 +153,7 @@ Some very frequently asked questions about linuxtv-dvb | ||||
| 	- video-buf: capture helper module for the saa7146_vv driver. This | ||||
| 	  one is responsible to handle capture buffers. | ||||
| 
 | ||||
| 	- dvb-ttpci: The main driver for AV7110 based, full-featued | ||||
| 	- dvb-ttpci: The main driver for AV7110 based, full-featured | ||||
| 	  DVB-S/C/T cards | ||||
| 
 | ||||
| eof | ||||
|  | ||||
| @ -18,7 +18,7 @@ The EISA infrastructure is made up of three parts : | ||||
| 
 | ||||
|     - The bus code implements most of the generic code. It is shared | ||||
|     among all the architectures that the EISA code runs on. It | ||||
|     implements bus probing (detecting EISA cards avaible on the bus), | ||||
|     implements bus probing (detecting EISA cards available on the bus), | ||||
|     allocates I/O resources, allows fancy naming through sysfs, and | ||||
|     offers interfaces for driver to register. | ||||
| 
 | ||||
| @ -84,7 +84,7 @@ struct eisa_driver { | ||||
| 
 | ||||
| id_table	: an array of NULL terminated EISA id strings, | ||||
| 		  followed by an empty string. Each string can | ||||
| 		  optionnaly be paired with a driver-dependant value | ||||
| 		  optionally be paired with a driver-dependant value | ||||
| 		  (driver_data). | ||||
| 
 | ||||
| driver		: a generic driver, such as described in | ||||
|  | ||||
| @ -10,7 +10,7 @@ int verify_area(int type, const void * addr, unsigned long size) | ||||
| function (which has since been replaced by access_ok()). | ||||
| 
 | ||||
| This function verified that the memory area starting at address  | ||||
| addr and of size size was accessible for the operation specified  | ||||
| 'addr' and of size 'size' was accessible for the operation specified | ||||
| in type (read or write). To do this, verify_read had to look up the  | ||||
| virtual memory area (vma) that contained the address addr. In the  | ||||
| normal case (correctly working program), this test was successful.  | ||||
|  | ||||
| @ -163,7 +163,7 @@ from the console layer before unloading the driver.  The VGA driver cannot be | ||||
| unloaded if it is still bound to the console layer. (See | ||||
| Documentation/console/console.txt for more information). | ||||
| 
 | ||||
| This is more complicated in the case of the the framebuffer console (fbcon), | ||||
| This is more complicated in the case of the framebuffer console (fbcon), | ||||
| because fbcon is an intermediate layer between the console and the drivers: | ||||
| 
 | ||||
| console ---> fbcon ---> fbdev drivers ---> hardware | ||||
|  | ||||
| @ -72,7 +72,7 @@ information. Additionally, "modinfo sisfb" gives an overview over all | ||||
| supported options including some explanation. | ||||
| 
 | ||||
| The desired display mode can be specified using the keyword "mode" with | ||||
| a parameter in one of the follwing formats: | ||||
| a parameter in one of the following formats: | ||||
|   - XxYxDepth or | ||||
|   - XxY-Depth or | ||||
|   - XxY-Depth@Rate or | ||||
|  | ||||
| @ -48,12 +48,12 @@ Module Usage | ||||
| 
 | ||||
| 	Module insertion: | ||||
| 	# insmod sstfb.o | ||||
| 	  you should see some strange output frome the board:  | ||||
| 	  you should see some strange output from the board:  | ||||
| 	  a big blue square, a green and a red small squares and a vertical | ||||
| 	  white rectangle. why ? the function's name is self explanatory : | ||||
| 	  white rectangle. why? the function's name is self-explanatory: | ||||
| 	  "sstfb_test()"... | ||||
| 	  (if you don't have a second monitor, you'll have to plug your monitor | ||||
| 	  directely to the 2D videocard to see what you're typing) | ||||
| 	  directly to the 2D videocard to see what you're typing) | ||||
| 	# con2fb /dev/fbx /dev/ttyx | ||||
| 	  bind a tty to the new frame buffer. if you already have a frame | ||||
| 	  buffer driver, the voodoo fb will likely be /dev/fb1. if not,  | ||||
| @ -72,12 +72,12 @@ Module Usage | ||||
| 
 | ||||
| Kernel/Modules Options | ||||
| 
 | ||||
| 	You can pass some otions to sstfb module, and via the kernel command | ||||
| 	line when the driver is compiled in : | ||||
| 	You can pass some options to the sstfb module, and via the kernel  | ||||
| 	command line when the driver is compiled in: | ||||
| 	for module : insmod sstfb.o option1=value1 option2=value2 ... | ||||
| 	in kernel :  video=sstfb:option1,option2:value2,option3 ... | ||||
| 	 | ||||
| 	sstfb supports the folowing options : | ||||
| 	sstfb supports the following options : | ||||
| 
 | ||||
| Module		Kernel		Description | ||||
| 
 | ||||
| @ -95,11 +95,11 @@ inverse=1	inverse		Supposed to enable inverse console. | ||||
| 
 | ||||
| clipping=1	clipping	Enable or disable clipping. | ||||
| clipping=0	noclipping	With clipping enabled, all offscreen | ||||
| 				reads and writes are disgarded. | ||||
| 				reads and writes are discarded. | ||||
| 				Default: enable clipping. | ||||
| 
 | ||||
| gfxclk=x	gfxclk:x	Force graphic clock frequency (in MHz). | ||||
| 				Be carefull with this option, it may be | ||||
| 				Be careful with this option, it may be | ||||
| 				DANGEROUS. | ||||
| 				Default: auto  | ||||
| 					50Mhz for Voodoo 1, | ||||
| @ -137,23 +137,23 @@ Bugs | ||||
| 	- The driver is 16 bpp only, 24/32 won't work. | ||||
| 	- The driver is not your_favorite_toy-safe. this includes SMP... | ||||
|           [Actually from inspection it seems to be safe - Alan] | ||||
| 	- when using XFree86 FBdev (X over fbdev) you may see strange color | ||||
| 	- When using XFree86 FBdev (X over fbdev) you may see strange color | ||||
| 	patterns at the border of your windows (the pixels lose the lowest | ||||
| 	byte -> basicaly the blue component nd some of the green) . I'm unable | ||||
| 	byte -> basically the blue component and some of the green). I'm unable | ||||
| 	to reproduce this with XFree86-3.3, but one of the testers has this | ||||
| 	problem with XFree86-4. apparently recent Xfree86-4.x solve this | ||||
| 	problem with XFree86-4. Apparently recent Xfree86-4.x solve this | ||||
| 	problem. | ||||
| 	- I didn't really test changing the palette, so you may find some weird | ||||
| 	things when playing with that. | ||||
| 	- Sometimes the driver will not recognise the DAC , and the | ||||
|         initialisation will fail. this is specificaly true for | ||||
| 	voodoo 2 boards , but it should be solved in recent versions. please | ||||
| 	contact me . | ||||
| 	- the 24/32 is not likely to work anytime soon , knowing that the | ||||
| 	hardware does ... unusual thigs in 24/32 bpp | ||||
| 	- When used with anther video board, current limitations of linux | ||||
| 	console subsystem can cause some troubles, specificaly, you should | ||||
| 	disable software scrollback , as it can oops badly ... | ||||
| 	- Sometimes the driver will not recognise the DAC, and the | ||||
|         initialisation will fail. This is specifically true for | ||||
| 	voodoo 2 boards, but it should be solved in recent versions. Please | ||||
| 	contact me. | ||||
| 	- The 24/32 is not likely to work anytime soon, knowing that the | ||||
| 	hardware does ... unusual things in 24/32 bpp. | ||||
| 	- When used with another video board, current limitations of the linux | ||||
| 	console subsystem can cause some troubles, specifically, you should | ||||
| 	disable software scrollback, as it can oops badly ... | ||||
| 
 | ||||
| Todo | ||||
| 
 | ||||
| @ -161,7 +161,7 @@ Todo | ||||
| 	- Buy more coffee. | ||||
| 	- test/port to other arch. | ||||
| 	- try to add panning using tweeks with front and back buffer . | ||||
| 	- try to implement accel on voodoo2 , this board can actualy do a  | ||||
| 	- try to implement accel on voodoo2, this board can actually do a  | ||||
| 	  lot in 2D even if it was sold as a 3D only board ... | ||||
| 
 | ||||
| ghoz. | ||||
|  | ||||
| @ -184,7 +184,7 @@ Who:	Greg Kroah-Hartman <gregkh@suse.de> | ||||
| --------------------------- | ||||
| 
 | ||||
| What:	USB driver API moves to EXPORT_SYMBOL_GPL | ||||
| When:	Febuary 2008 | ||||
| When:	February 2008 | ||||
| Files:	include/linux/usb.h, drivers/usb/core/driver.c | ||||
| Why:	The USB subsystem has changed a lot over time, and it has been | ||||
| 	possible to create userspace USB drivers using usbfs/libusb/gadgetfs | ||||
|  | ||||
| @ -26,8 +26,6 @@ cramfs.txt | ||||
| 	- info on the cram filesystem for small storage (ROMs etc). | ||||
| dentry-locking.txt | ||||
| 	- info on the RCU-based dcache locking model. | ||||
| devfs/ | ||||
| 	- directory containing devfs documentation. | ||||
| directory-locking | ||||
| 	- info about the locking scheme used for directory operations. | ||||
| dlmfs.txt | ||||
|  | ||||
| @ -7,7 +7,7 @@ WARNING | ||||
| Make sure you understand that this is alpha software.  This means that the | ||||
| implementation is neither complete nor well-tested.  | ||||
| 
 | ||||
| I DISCLAIM ALL RESPONSIBILTY FOR ANY POSSIBLE BAD EFFECTS OF THIS CODE! | ||||
| I DISCLAIM ALL RESPONSIBILITY FOR ANY POSSIBLE BAD EFFECTS OF THIS CODE! | ||||
| 
 | ||||
| LICENSE | ||||
| ===== | ||||
| @ -22,7 +22,7 @@ He has been working on the code since Aug 13, 2001. See the changelog for | ||||
| details. | ||||
| 
 | ||||
| Original Author: Makoto Kato <m_kato@ga2.so-net.ne.jp> | ||||
| His orriginal code can still be found at: | ||||
| His original code can still be found at: | ||||
| <http://hp.vector.co.jp/authors/VA008030/bfs/> | ||||
| Does anyone know of a more current email address for Makoto? He doesn't | ||||
| respond to the address given above... | ||||
| @ -39,7 +39,7 @@ Which is it, BFS or BEFS? | ||||
| ================ | ||||
| Be, Inc said, "BeOS Filesystem is officially called BFS, not BeFS".  | ||||
| But Unixware Boot Filesystem is called bfs, too. And they are already in | ||||
| the kernel. Because of this nameing conflict, on Linux the BeOS | ||||
| the kernel. Because of this naming conflict, on Linux the BeOS | ||||
| filesystem is called befs. | ||||
| 
 | ||||
| HOW TO INSTALL | ||||
| @ -57,7 +57,7 @@ if the patching step fails (i.e. there are rejected hunks), you can try to | ||||
| figure it out yourself (it shouldn't be hard), or mail the maintainer  | ||||
| (Will Dyson <will_dyson@pobox.com>) for help. | ||||
| 
 | ||||
| step 2.  Configuretion & make kernel | ||||
| step 2.  Configuration & make kernel | ||||
| 
 | ||||
| The linux kernel has many compile-time options. Most of them are beyond the | ||||
| scope of this document. I suggest the Kernel-HOWTO document as a good general | ||||
|  | ||||
| @ -1,5 +1,5 @@ | ||||
| 
 | ||||
| configfs - Userspace-driven kernel object configuation. | ||||
| configfs - Userspace-driven kernel object configuration. | ||||
| 
 | ||||
| Joel Becker <joel.becker@oracle.com> | ||||
| 
 | ||||
| @ -254,7 +254,7 @@ using the group _init() functions on the group. | ||||
| 
 | ||||
| Finally, when userspace calls rmdir(2) on the item or group, | ||||
| ct_group_ops->drop_item() is called.  As a config_group is also a | ||||
| config_item, it is not necessary for a seperate drop_group() method. | ||||
| config_item, it is not necessary for a separate drop_group() method. | ||||
| The subsystem must config_item_put() the reference that was initialized | ||||
| upon item allocation.  If a subsystem has no work to do, it may omit | ||||
| the ct_group_ops->drop_item() method, and configfs will call | ||||
| @ -406,7 +406,7 @@ that condition is met. | ||||
| 
 | ||||
| Far better would be an explicit action notifying the subsystem that the | ||||
| config_item is ready to go.  More importantly, an explicit action allows | ||||
| the subsystem to provide feedback as to whether the attibutes are | ||||
| the subsystem to provide feedback as to whether the attributes are | ||||
| initialized in a way that makes sense.  configfs provides this as | ||||
| committable items. | ||||
| 
 | ||||
| @ -422,7 +422,7 @@ support mkdir(2) or rmdir(2) either.  It only allows rename(2).  The | ||||
| "pending" directory does allow mkdir(2) and rmdir(2).  An item is | ||||
| created in the "pending" directory.  Its attributes can be modified at | ||||
| will.  Userspace commits the item by renaming it into the "live" | ||||
| directory.  At this point, the subsystem recieves the ->commit_item() | ||||
| directory.  At this point, the subsystem receives the ->commit_item() | ||||
| callback.  If all required attributes are filled to satisfaction, the | ||||
| method returns zero and the item is moved to the "live" directory. | ||||
| 
 | ||||
|  | ||||
| @ -82,7 +82,7 @@ own descendent.  Moreover, there is exactly one cross-directory rename | ||||
| 
 | ||||
| 	Consider the object blocking the cross-directory rename.  One | ||||
| of its descendents is locked by cross-directory rename (otherwise we | ||||
| would again have an infinite set of of contended objects).  But that | ||||
| would again have an infinite set of contended objects).  But that | ||||
| means that cross-directory rename is taking locks out of order.  Due | ||||
| to (2) the order hadn't changed since we had acquired filesystem lock. | ||||
| But locking rules for cross-directory rename guarantee that we do not | ||||
|  | ||||
| @ -68,7 +68,7 @@ request for an already acquired lock will not generate another DLM | ||||
| call. Userspace programs are assumed to handle their own local | ||||
| locking. | ||||
| 
 | ||||
| Two levels of locks are supported - Shared Read, and Exlcusive. | ||||
| Two levels of locks are supported - Shared Read, and Exclusive. | ||||
| Also supported is a Trylock operation. | ||||
| 
 | ||||
| For information on the libo2dlm interface, please see o2dlm.h, | ||||
|  | ||||
| @ -205,7 +205,7 @@ Reserved Space | ||||
| 
 | ||||
| In ext2, there is a mechanism for reserving a certain number of blocks | ||||
| for a particular user (normally the super-user).  This is intended to | ||||
| allow for the system to continue functioning even if non-priveleged users | ||||
| allow for the system to continue functioning even if non-privileged users | ||||
| fill up all the space available to them (this is independent of filesystem | ||||
| quotas).  It also keeps the filesystem from filling up entirely which | ||||
| helps combat fragmentation. | ||||
|  | ||||
| @ -55,7 +55,7 @@ the fdtable structure - | ||||
| 2. Reading of the fdtable as described above must be protected | ||||
|    by rcu_read_lock()/rcu_read_unlock(). | ||||
| 
 | ||||
| 3. For any update to the the fd table, files->file_lock must | ||||
| 3. For any update to the fd table, files->file_lock must | ||||
|    be held. | ||||
| 
 | ||||
| 4. To look up the file structure given an fd, a reader | ||||
|  | ||||
| @ -13,7 +13,7 @@ Table of contents | ||||
| - Using NTFS volume and stripe sets | ||||
|   - The Device-Mapper driver | ||||
|   - The Software RAID / MD driver | ||||
|   - Limitiations when using the MD driver | ||||
|   - Limitations when using the MD driver | ||||
| - ChangeLog | ||||
| 
 | ||||
| 
 | ||||
| @ -43,7 +43,7 @@ There is plenty of additional information on the linux-ntfs web site | ||||
| at http://linux-ntfs.sourceforge.net/ | ||||
| 
 | ||||
| The web site has a lot of additional information, such as a comprehensive | ||||
| FAQ, documentation on the NTFS on-disk format, informaiton on the Linux-NTFS | ||||
| FAQ, documentation on the NTFS on-disk format, information on the Linux-NTFS | ||||
| userspace utilities, etc. | ||||
| 
 | ||||
| 
 | ||||
| @ -383,14 +383,14 @@ Software RAID / MD driver.  For which you need to set up your /etc/raidtab | ||||
| appropriately (see man 5 raidtab). | ||||
| 
 | ||||
| Linear volume sets, i.e. linear raid, as well as stripe sets, i.e. raid level | ||||
| 0, have been tested and work fine (though see section "Limitiations when using | ||||
| 0, have been tested and work fine (though see section "Limitations when using | ||||
| the MD driver with NTFS volumes" especially if you want to use linear raid). | ||||
| Even though untested, there is no reason why mirrors, i.e. raid level 1, and | ||||
| stripes with parity, i.e. raid level 5, should not work, too. | ||||
| 
 | ||||
| You have to use the "persistent-superblock 0" option for each raid-disk in the | ||||
| NTFS volume/stripe you are configuring in /etc/raidtab as the persistent | ||||
| superblock used by the MD driver would damange the NTFS volume. | ||||
| superblock used by the MD driver would damage the NTFS volume. | ||||
| 
 | ||||
| Windows by default uses a stripe chunk size of 64k, so you probably want the | ||||
| "chunk-size 64k" option for each raid-disk, too. | ||||
| @ -435,7 +435,7 @@ setup correctly to avoid the possibility of causing damage to the data on the | ||||
| ntfs volume. | ||||
| 
 | ||||
| 
 | ||||
| Limitiations when using the Software RAID / MD driver | ||||
| Limitations when using the Software RAID / MD driver | ||||
| ----------------------------------------------------- | ||||
| 
 | ||||
| Using the md driver will not work properly if any of your NTFS partitions have | ||||
|  | ||||
| @ -410,7 +410,7 @@ VmallocChunk:   111088 kB | ||||
|               this memory, making it slower to access than lowmem. | ||||
|     LowTotal: | ||||
|      LowFree: Lowmem is memory which can be used for everything that | ||||
|               highmem can be used for, but it is also availble for the | ||||
|               highmem can be used for, but it is also available for the | ||||
|               kernel's use for its own data structures.  Among many | ||||
|               other things, it is where everything from the Slab is | ||||
|               allocated.  Bad things happen when you're out of lowmem. | ||||
| @ -1255,7 +1255,7 @@ to allocate (but not use) more memory than is actually available. | ||||
| 		address space are refused. Used for a typical system. It | ||||
| 		ensures a seriously wild allocation fails while allowing | ||||
| 		overcommit to reduce swap usage.  root is allowed to | ||||
| 		allocate slighly more memory in this mode. This is the | ||||
| 		allocate slightly more memory in this mode. This is the | ||||
| 		default. | ||||
| 
 | ||||
| 1	-	Always overcommit. Appropriate for some scientific | ||||
| @ -1588,7 +1588,7 @@ Enable the  strict  RFC793 interpretation of the TCP urgent pointer field. The | ||||
| default is  to  use  the  BSD  compatible interpretation of the urgent pointer | ||||
| pointing to the first byte after the urgent data. The RFC793 interpretation is | ||||
| to have  it  point  to  the last byte of urgent data. Enabling this option may | ||||
| lead to interoperatibility problems. Disabled by default. | ||||
| lead to interoperability problems. Disabled by default. | ||||
| 
 | ||||
| tcp_syncookies | ||||
| -------------- | ||||
| @ -1733,7 +1733,7 @@ error_burst and error_cost | ||||
| 
 | ||||
| These  parameters  are used to limit how many ICMP destination unreachable to  | ||||
| send  from  the  host  in question. ICMP destination unreachable messages are  | ||||
| sent  when  we can not reach the next hop, while trying to transmit a packet.  | ||||
| sent  when  we  cannot reach  the next hop while trying to transmit a packet.  | ||||
| It  will also print some error messages to kernel logs if someone is ignoring  | ||||
| our   ICMP  redirects.  The  higher  the  error_cost  factor  is,  the  fewer  | ||||
| destination  unreachable  and error messages will be let through. Error_burst  | ||||
| @ -1857,7 +1857,7 @@ proxy_qlen | ||||
| 
 | ||||
| Maximum queue length of the delayed proxy arp timer. (see proxy_delay). | ||||
| 
 | ||||
| app_solcit | ||||
| app_solicit | ||||
| ---------- | ||||
| 
 | ||||
| Determines the  number of requests to send to the user level ARP daemon. Use 0 | ||||
|  | ||||
| @ -84,7 +84,7 @@ FILES | ||||
|    /ibox | ||||
|        The  second  SPU  to CPU communication mailbox. This file is similar to | ||||
|        the first mailbox file, but can be read in blocking I/O mode,  and  the | ||||
|        poll  familiy of system calls can be used to wait for it.  The possible | ||||
|        poll  family of system calls can be used to wait for it.  The  possible | ||||
|        operations on an open ibox file are: | ||||
| 
 | ||||
|        read(2) | ||||
| @ -105,7 +105,7 @@ FILES | ||||
| 
 | ||||
| 
 | ||||
|    /wbox | ||||
|        The CPU to SPU communation mailbox. It is write-only can can be written | ||||
|        The CPU to SPU communation mailbox. It is write-only and can be written | ||||
|        in  units  of  32  bits. If the mailbox is full, write() will block and | ||||
|        poll can be used to wait for it becoming  empty  again.   The  possible | ||||
|        operations  on  an open wbox file are: write(2) If a count smaller than | ||||
| @ -359,7 +359,7 @@ ERRORS | ||||
|        EFAULT npc is not a valid pointer or status is neither NULL nor a valid | ||||
|               pointer. | ||||
| 
 | ||||
|        EINTR  A signal occured while spu_run was in progress.  The  npc  value | ||||
|        EINTR  A signal occurred while spu_run was in progress.  The npc  value | ||||
|               has  been updated to the new program counter value if necessary. | ||||
| 
 | ||||
|        EINVAL fd is not a file descriptor returned from spu_create(2). | ||||
|  | ||||
| @ -238,7 +238,7 @@ Top Level Directory Layout | ||||
| The sysfs directory arrangement exposes the relationship of kernel | ||||
| data structures.  | ||||
| 
 | ||||
| The top level sysfs diretory looks like: | ||||
| The top level sysfs directory looks like: | ||||
| 
 | ||||
| block/ | ||||
| bus/ | ||||
|  | ||||
| @ -39,7 +39,7 @@ tmpfs has the following uses: | ||||
| 	tmpfs	/dev/shm	tmpfs	defaults	0 0 | ||||
| 
 | ||||
|    Remember to create the directory that you intend to mount tmpfs on | ||||
|    if necessary (/dev/shm is automagically created if you use devfs). | ||||
|    if necessary. | ||||
| 
 | ||||
|    This mount is _not_ needed for SYSV shared memory. The internal | ||||
|    mount is used for that. (In the 2.3 kernel versions it was | ||||
| @ -63,7 +63,7 @@ size:      The limit of allocated bytes for this tmpfs instance. The | ||||
| nr_blocks: The same as size, but in blocks of PAGE_CACHE_SIZE. | ||||
| nr_inodes: The maximum number of inodes for this instance. The default | ||||
|            is half of the number of your physical RAM pages, or (on a | ||||
|            a machine with highmem) the number of lowmem RAM pages, | ||||
|            machine with highmem) the number of lowmem RAM pages, | ||||
|            whichever is the lower. | ||||
| 
 | ||||
| These parameters accept a suffix k, m or g for kilo, mega and giga and | ||||
|  | ||||
| @ -35,7 +35,7 @@ iocharset=name -- Character set to use for converting between the | ||||
| 		 you should consider the following option instead. | ||||
| 
 | ||||
| utf8=<bool>   -- UTF-8 is the filesystem safe version of Unicode that | ||||
| 		 is used by the console.  It can be be enabled for the | ||||
| 		 is used by the console.  It can be enabled for the | ||||
| 		 filesystem with this option. If 'uni_xlate' gets set, | ||||
| 		 UTF-8 gets disabled. | ||||
| 
 | ||||
|  | ||||
| @ -410,7 +410,7 @@ otherwise noted. | ||||
| 
 | ||||
|   put_link: called by the VFS to release resources allocated by | ||||
|   	follow_link().  The cookie returned by follow_link() is passed | ||||
|   	to to this method as the last parameter.  It is used by | ||||
|   	to this method as the last parameter.  It is used by | ||||
|   	filesystems such as NFS where page cache is not stable | ||||
|   	(i.e. page that was installed when the symbolic link walk | ||||
|   	started might not be in the page cache at the end of the | ||||
|  | ||||
| @ -233,7 +233,7 @@ related kernel services: | ||||
|      (*) __debug_mmu.iamr[] | ||||
|      (*) __debug_mmu.damr[] | ||||
| 
 | ||||
| 	 These receive the current IAMR and DAMR contents. These can be viewed with with the _amr | ||||
| 	 These receive the current IAMR and DAMR contents. These can be viewed with the _amr | ||||
| 	 GDB macro: | ||||
| 
 | ||||
| 		(gdb) _amr | ||||
|  | ||||
| @ -57,7 +57,7 @@ What's left to be done for 32-bit UIDs on all Linux architectures: | ||||
| 
 | ||||
|   Other filesystems have not been checked yet. | ||||
| 
 | ||||
| - The ncpfs and smpfs filesystems can not presently use 32-bit UIDs in | ||||
| - The ncpfs and smpfs filesystems cannot presently use 32-bit UIDs in | ||||
|   all ioctl()s. Some new ioctl()s have been added with 32-bit UIDs, but | ||||
|   more are needed. (as well as new user<->kernel data structures) | ||||
| 
 | ||||
|  | ||||
| @ -10,7 +10,7 @@ back and forth trying to integrate high-resolution and high-precision | ||||
| features into the existing timer framework, and after testing various | ||||
| such high-resolution timer implementations in practice, we came to the | ||||
| conclusion that the timer wheel code is fundamentally not suitable for | ||||
| such an approach. We initially didnt believe this ('there must be a way | ||||
| such an approach. We initially didn't believe this ('there must be a way | ||||
| to solve this'), and spent a considerable effort trying to integrate | ||||
| things into the timer wheel, but we failed. In hindsight, there are | ||||
| several reasons why such integration is hard/impossible: | ||||
| @ -27,7 +27,7 @@ several reasons why such integration is hard/impossible: | ||||
|   high-res timers. | ||||
| 
 | ||||
| - the unpredictable [O(N)] overhead of cascading leads to delays which | ||||
|   necessiate a more complex handling of high resolution timers, which | ||||
|   necessitate a more complex handling of high resolution timers, which | ||||
|   in turn decreases robustness. Such a design still led to rather large | ||||
|   timing inaccuracies. Cascading is a fundamental property of the timer | ||||
|   wheel concept, it cannot be 'designed out' without unevitably | ||||
| @ -58,7 +58,7 @@ several reasons why such integration is hard/impossible: | ||||
| The primary users of precision timers are user-space applications that | ||||
| utilize nanosleep, posix-timers and itimer interfaces. Also, in-kernel | ||||
| users like drivers and subsystems which require precise timed events | ||||
| (e.g. multimedia) can benefit from the availability of a seperate | ||||
| (e.g. multimedia) can benefit from the availability of a separate | ||||
| high-resolution timer subsystem as well. | ||||
| 
 | ||||
| While this subsystem does not offer high-resolution clock sources just | ||||
| @ -68,7 +68,7 @@ The increasing demand for realtime and multimedia applications along | ||||
| with other potential users for precise timers gives another reason to | ||||
| separate the "timeout" and "precise timer" subsystems. | ||||
| 
 | ||||
| Another potential benefit is that such a seperation allows even more | ||||
| Another potential benefit is that such a separation allows even more | ||||
| special-purpose optimization of the existing timer wheel for the low | ||||
| resolution and low precision use cases - once the precision-sensitive | ||||
| APIs are separated from the timer wheel and are migrated over to | ||||
| @ -96,8 +96,8 @@ file systems. The rbtree is solely used for time sorted ordering, while | ||||
| a separate list is used to give the expiry code fast access to the | ||||
| queued timers, without having to walk the rbtree. | ||||
| 
 | ||||
| (This seperate list is also useful for later when we'll introduce | ||||
| high-resolution clocks, where we need seperate pending and expired | ||||
| (This separate list is also useful for later when we'll introduce | ||||
| high-resolution clocks, where we need separate pending and expired | ||||
| queues while keeping the time-order intact.) | ||||
| 
 | ||||
| Time-ordered enqueueing is not purely for the purposes of | ||||
|  | ||||
| @ -26,7 +26,7 @@ to initialize the system view of the time during boot. | ||||
| Because we wanted to minimize the impact on existing user-level apps using | ||||
| the CMOS clock, we decided to expose an API that was very similar to the one | ||||
| used today with the legacy RTC driver (driver/char/rtc.c). However, because  | ||||
| EFI provides a simpler services, not all all ioctl() are available. Also | ||||
| EFI provides a simpler services, not all ioctl() are available. Also | ||||
| new ioctl()s have been introduced for things that EFI provides but not the  | ||||
| legacy. | ||||
| 
 | ||||
|  | ||||
| @ -165,7 +165,7 @@ complicated cases. | ||||
| * Signal handling | ||||
| 
 | ||||
| The delivery of (asynchronous) signals must be delayed until fsys-mode | ||||
| is exited.  This is acomplished with the help of the lower-privilege | ||||
| is exited.  This is accomplished with the help of the lower-privilege | ||||
| transfer trap: arch/ia64/kernel/process.c:do_notify_resume_user() | ||||
| checks whether the interrupted task was in fsys-mode and, if so, sets | ||||
| PSR.lp and returns immediately.  When fsys-mode is exited via the | ||||
|  | ||||
| @ -12,7 +12,7 @@ by locks is indeterminate, including linked lists. | ||||
| --- | ||||
| 
 | ||||
| The complicated ia64 MCA process.  All of this is mandated by Intel's | ||||
| specification for ia64 SAL, error recovery and and unwind, it is not as | ||||
| specification for ia64 SAL, error recovery and unwind, it is not as | ||||
| if we have a choice here. | ||||
| 
 | ||||
| * MCA occurs on one cpu, usually due to a double bit memory error. | ||||
| @ -94,7 +94,7 @@ if we have a choice here. | ||||
| 
 | ||||
| INIT is less complicated than MCA.  Pressing the nmi button or using | ||||
| the equivalent command on the management console sends INIT to all | ||||
| cpus.  SAL picks one one of the cpus as the monarch and the rest are | ||||
| cpus.  SAL picks one of the cpus as the monarch and the rest are | ||||
| slaves.  All the OS INIT handlers are entered at approximately the same | ||||
| time.  The OS monarch prints the state of all tasks and returns, after | ||||
| which the slaves return and the system resumes. | ||||
|  | ||||
| @ -450,7 +450,7 @@ his laptop (the location of sensors may vary on other models): | ||||
| 
 | ||||
| No commands can be written to this file. | ||||
| 
 | ||||
| EXPERIMENTAL: Embedded controller reigster dump -- /proc/acpi/ibm/ecdump | ||||
| EXPERIMENTAL: Embedded controller register dump -- /proc/acpi/ibm/ecdump | ||||
| ------------------------------------------------------------------------ | ||||
| 
 | ||||
| This feature is marked EXPERIMENTAL because the implementation | ||||
|  | ||||
| @ -281,7 +281,7 @@ Summary of ide driver parameters for kernel command line | ||||
| 
 | ||||
|  "idex=serialize"	: do not overlap operations on idex. Please note | ||||
| 			  that you will have to specify this option for | ||||
| 			  both the respecitve primary and secondary channel | ||||
| 			  both the respective primary and secondary channel | ||||
| 			  to take effect. | ||||
| 
 | ||||
|  "idex=four"		: four drives on idex and ide(x^1) share same ports | ||||
|  | ||||
| @ -79,10 +79,10 @@ JOY0DAT   Y7  Y6  Y5  Y4  Y3  Y2  Y1  Y0     X7  X6  X5  X4  X3  X2  X1  X0 | ||||
| JOY1DAT   Y7  Y6  Y5  Y4  Y3  Y2  Y1  Y0     X7  X6  X5  X4  X3  X2  X1  X0 | ||||
| 
 | ||||
|         0=LEFT CONTROLLER PAIR, 1=RIGHT CONTROLLER PAIR. | ||||
|         (4 counters total).The bit usage for both left and right | ||||
|         (4 counters total). The bit usage for both left and right | ||||
|         addresses is shown below. Each 6 bit counter (Y7-Y2,X7-X2) is | ||||
|         clocked by 2 of the signals input from the mouse serial | ||||
|         stream. Starting with first bit recived: | ||||
|         stream. Starting with first bit received: | ||||
| 
 | ||||
|          +-------------------+-----------------------------------------+ | ||||
|          | Serial | Bit Name | Description                             | | ||||
|  | ||||
| @ -10,7 +10,7 @@ provides a convenient connection point for a mouse and switch-type joysticks. | ||||
| The ikbd processor also maintains a time-of-day clock with one second | ||||
| resolution. | ||||
| The ikbd has been designed to be general enough that it can be used with a | ||||
| ariety of new computer products. Product variations in a number of | ||||
| variety of new computer products. Product variations in a number of | ||||
| keyswitches, mouse resolution, etc. can be accommodated. | ||||
| The ikbd communicates with the main processor over a high speed bi-directional | ||||
| serial interface. It can function in a variety of modes to facilitate | ||||
| @ -30,7 +30,7 @@ is obtained by ORing 0x80 with the make code. | ||||
| The special codes 0xF6 through 0xFF are reserved for use as follows: | ||||
|     0xF6            status report | ||||
|     0xF7            absolute mouse position record | ||||
|     0xF8-0xFB       relative mouse position records(lsbs determind by | ||||
|     0xF8-0xFB       relative mouse position records (lsbs determined by | ||||
|                      mouse button states) | ||||
|     0xFC            time-of-day | ||||
|     0xFD            joystick report (both sticks) | ||||
| @ -84,7 +84,7 @@ selected. | ||||
| 4.2 Absolute Position reporting | ||||
| 
 | ||||
| The ikbd can also maintain absolute mouse position. Commands exist for | ||||
| reseting the mouse position, setting X/Y scaling, and interrogating the | ||||
| resetting the mouse position, setting X/Y scaling, and interrogating the | ||||
| current mouse position. | ||||
| 
 | ||||
| 4.3 Mouse Cursor Key Mode | ||||
| @ -406,7 +406,7 @@ INTERROGATION MODE. | ||||
| 9.18 SET JOYSTICK MONITORING | ||||
| 
 | ||||
|     0x17 | ||||
|     rate                ; time between samples in hundreths of a second | ||||
|     rate                ; time between samples in hundredths of a second | ||||
|     Returns: (in packets of two as long as in mode) | ||||
|             %000000xy   ; where y is JOYSTICK1 Fire button | ||||
|                         ; and x is JOYSTICK0 Fire button | ||||
| @ -522,7 +522,7 @@ controller memory. The time between data bytes must be less than 20ms. | ||||
|             0x20        ; memory access | ||||
|             { data }    ; 6 data bytes starting at ADR | ||||
| 
 | ||||
| This comand permits the host to read from the ikbd controller memory. | ||||
| This command permits the host to read from the ikbd controller memory. | ||||
| 
 | ||||
| 9.26 CONTROLLER EXECUTE | ||||
| 
 | ||||
|  | ||||
| @ -27,7 +27,7 @@ This driver have the basic support for PCI devices only; there is no | ||||
| ISA or PnP ISA cards supported. AFAIK the ns558 have support for Crystal  | ||||
| ISA and PnP ISA series. | ||||
| 
 | ||||
| The driver works witn ALSA drivers simultaneously. For exmple, the xracer | ||||
| The driver works with ALSA drivers simultaneously. For example, the xracer | ||||
| uses joystick as input device and PCM device as sound output in one time. | ||||
| There are no sound or input collisions detected. The source code have | ||||
| comments about them; but I've found the joystick can be initialized  | ||||
|  | ||||
| @ -38,7 +38,7 @@ joystick.txt for details. | ||||
| There is an utility called fftest that will allow you to test the driver. | ||||
| % fftest /dev/input/eventXX | ||||
| 
 | ||||
| 3. Instructions to the developper | ||||
| 3. Instructions to the developer | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
| All interactions are done using the event API. That is, you can use ioctl() | ||||
| and write() on /dev/input/eventXX. | ||||
|  | ||||
| @ -18,8 +18,8 @@ Make sure struct gameport is initialized to 0 in all other fields. The | ||||
| gameport generic code will take care of the rest. | ||||
| 
 | ||||
| If your hardware supports more than one io address, and your driver can | ||||
| choose which one program the hardware to, starting from the more exotic | ||||
| addresses is preferred, because the likelyhood of clashing with the standard | ||||
| choose which one to program the hardware to, starting from the more exotic | ||||
| addresses is preferred, because the likelihood of clashing with the standard | ||||
| 0x201 address is smaller. | ||||
| 
 | ||||
| Eg. if your driver supports addresses 0x200, 0x208, 0x210 and 0x218, then | ||||
|  | ||||
| @ -68,8 +68,8 @@ will be available as a character device on major 13, minor 63: | ||||
| 
 | ||||
| 	crw-r--r--   1 root     root      13,  63 Mar 28 22:45 mice | ||||
| 
 | ||||
|   This device has to be created, unless you use devfs, in which case it's | ||||
| created automatically. The commands to do create it by hand are: | ||||
|   This device has to be created. | ||||
|   The commands to create it by hand are: | ||||
| 
 | ||||
| 	cd /dev | ||||
| 	mkdir input | ||||
| @ -154,7 +154,7 @@ about it. | ||||
| 
 | ||||
| 3.2 Event handlers | ||||
| ~~~~~~~~~~~~~~~~~~ | ||||
|   Event handlers distrubite the events from the devices to userland and | ||||
|   Event handlers distribute the events from the devices to userland and | ||||
| kernel, as needed. | ||||
| 
 | ||||
| 3.2.1 keybdev | ||||
| @ -230,7 +230,7 @@ generated in the kernel straight to the program, with timestamps. The | ||||
| API is still evolving, but should be useable now. It's described in | ||||
| section 5.  | ||||
| 
 | ||||
|   This should be the way for GPM and X to get keyboard and mouse mouse | ||||
|   This should be the way for GPM and X to get keyboard and mouse | ||||
| events. It allows for multihead in X without any specific multihead | ||||
| kernel support. The event codes are the same on all architectures and | ||||
| are hardware independent. | ||||
| @ -279,7 +279,7 @@ struct input_event { | ||||
| }; | ||||
| 
 | ||||
|   'time' is the timestamp, it returns the time at which the event happened. | ||||
| Type is for example EV_REL for relative momement, REL_KEY for a keypress or | ||||
| Type is for example EV_REL for relative moment, REL_KEY for a keypress or | ||||
| release. More types are defined in include/linux/input.h. | ||||
| 
 | ||||
|   'code' is event code, for example REL_X or KEY_BACKSPACE, again a complete | ||||
| @ -289,24 +289,3 @@ list is in include/linux/input.h. | ||||
| EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for | ||||
| release, 1 for keypress and 2 for autorepeat. | ||||
| 
 | ||||
| 6. Contacts | ||||
| ~~~~~~~~~~~ | ||||
|   This effort has its home page at: | ||||
| 
 | ||||
| 	http://www.suse.cz/development/input/ | ||||
| 
 | ||||
| You'll find both the latest HID driver and the complete Input driver | ||||
| there as well as information how to access the CVS repository for | ||||
| latest revisions of the drivers. | ||||
| 
 | ||||
|   There is also a mailing list for this: | ||||
| 
 | ||||
| 	majordomo@atrey.karlin.mff.cuni.cz | ||||
| 
 | ||||
| Send "subscribe linux-input" to subscribe to it. | ||||
| 
 | ||||
| The input changes are also being worked on as part of the LinuxConsole | ||||
| project, see: | ||||
| 
 | ||||
| 	 http://sourceforge.net/projects/linuxconsole/ | ||||
| 
 | ||||
|  | ||||
| @ -456,8 +456,8 @@ uses the following kernel/module command line: | ||||
| 	  8  | Sony PSX DDR controller | ||||
| 	  9  | SNES mouse | ||||
| 
 | ||||
|   The exact type of the PSX controller type is autoprobed when used so | ||||
| hot swapping should work (but is not recomended). | ||||
|   The exact type of the PSX controller type is autoprobed when used, so | ||||
| hot swapping should work (but is not recommended). | ||||
| 
 | ||||
|   Should you want to use more than one of parallel ports at once, you can use | ||||
| gamecon.map2 and gamecon.map3 as additional command line parameters for two | ||||
| @ -465,8 +465,8 @@ more parallel ports. | ||||
| 
 | ||||
|   There are two options specific to PSX driver portion.  gamecon.psx_delay sets | ||||
| the command delay when talking to the controllers. The default of 25 should | ||||
| work but you can try lowering it for better performace. If your pads don't | ||||
| respond try raising it untill they work. Setting the type to 8 allows the | ||||
| work but you can try lowering it for better performance. If your pads don't | ||||
| respond try raising it until they work. Setting the type to 8 allows the | ||||
| driver to be used with Dance Dance Revolution or similar games. Arrow keys are | ||||
| registered as key presses instead of X and Y axes. | ||||
| 
 | ||||
|  | ||||
| @ -60,7 +60,7 @@ and install it before going on. | ||||
| 
 | ||||
| 2.2 Device nodes | ||||
| ~~~~~~~~~~~~~~~~ | ||||
| For applications to be able to use the joysticks, in you don't use devfs, | ||||
| For applications to be able to use the joysticks, | ||||
| you'll have to manually create these nodes in /dev: | ||||
| 
 | ||||
| cd /dev | ||||
|  | ||||
| @ -87,13 +87,13 @@ Line 3  Format			: 888888888888 | ||||
| 
 | ||||
| 
 | ||||
| Format description: | ||||
|   From a user space perspective the world is seperated in "digits" and "icons". | ||||
|   From a userspace perspective the world is separated into "digits" and "icons". | ||||
|   A digit can have a character set, an icon can only be ON or OFF. | ||||
| 
 | ||||
|   Format specifier | ||||
|     '8' :  Generic 7 segment digit with individual addressable segments | ||||
| 
 | ||||
|     Reduced capabillity 7 segm digit, when segments are hard wired together. | ||||
|     Reduced capability 7 segm digit, when segments are hard wired together. | ||||
|     '1' : 2 segments digit only able to produce a 1. | ||||
|     'e' : Most significant day of the month digit, | ||||
|           able to produce at least 1 2 3. | ||||
|  | ||||
| @ -203,7 +203,7 @@ HDIO_SET_MULTCOUNT		change IDE blockmode | ||||
| 
 | ||||
| 	  Source code comments read: | ||||
| 
 | ||||
| 	    This is tightly woven into the driver->do_special can not | ||||
| 	    This is tightly woven into the driver->do_special cannot | ||||
| 	    touch.  DON'T do it again until a total personality rewrite | ||||
| 	    is committed. | ||||
| 
 | ||||
|  | ||||
| @ -26,7 +26,7 @@ Structure T30_s description: | ||||
|   If the HL-driver receives ISDN_CMD_FAXCMD, all needed information | ||||
|   is in this struct set by the LL. | ||||
|   To signal information to the LL, the HL-driver has to set the  | ||||
|   the parameters and use ISDN_STAT_FAXIND. | ||||
|   parameters and use ISDN_STAT_FAXIND. | ||||
|   (Please refer to INTERFACE) | ||||
| 
 | ||||
| Structure T30_s: | ||||
|  | ||||
| @ -1,6 +1,6 @@ | ||||
| $Id: README.hysdn,v 1.3.6.1 2001/02/10 14:41:19 kai Exp $ | ||||
| The hysdn driver has been written by | ||||
| by Werner Cornelius (werner@isdn4linux.de or werner@titro.de)  | ||||
| Werner Cornelius (werner@isdn4linux.de or werner@titro.de) | ||||
| for Hypercope GmbH Aachen Germany. Hypercope agreed to publish this driver | ||||
| under the GNU General Public License. | ||||
| 
 | ||||
|  | ||||
| @ -22,7 +22,7 @@ other program after you have done the following: | ||||
|    the kernel (CONFIG_BINFMT_MISC) and set it up properly. | ||||
|    If you choose to compile it as a module, you will have | ||||
|    to insert it manually with modprobe/insmod, as kmod | ||||
|    can not easily be supported with binfmt_misc.  | ||||
|    cannot easily be supported with binfmt_misc.  | ||||
|    Read the file 'binfmt_misc.txt' in this directory to know | ||||
|    more about the configuration process. | ||||
| 
 | ||||
|  | ||||
| @ -110,7 +110,7 @@ applicable everywhere (see syntax). | ||||
|   the indentation level, this means it ends at the first line which has | ||||
|   a smaller indentation than the first line of the help text. | ||||
|   "---help---" and "help" do not differ in behaviour, "---help---" is | ||||
|   used to help visually seperate configuration logic from help within | ||||
|   used to help visually separate configuration logic from help within | ||||
|   the file as an aid to developers. | ||||
| 
 | ||||
| 
 | ||||
| @ -226,7 +226,7 @@ menuconfig: | ||||
| 	"menuconfig" <symbol> | ||||
| 	<config options> | ||||
| 
 | ||||
| This is similiar to the simple config entry above, but it also gives a | ||||
| This is similar to the simple config entry above, but it also gives a | ||||
| hint to front ends, that all suboptions should be displayed as a | ||||
| separate list of options. | ||||
| 
 | ||||
|  | ||||
| @ -249,7 +249,7 @@ If die() is called, and it happens to be a thread with pid 0 or 1, or die() | ||||
| is called inside interrupt context or die() is called and panic_on_oops is set, | ||||
| the system will boot into the dump-capture kernel. | ||||
| 
 | ||||
| On powererpc systems when a soft-reset is generated, die() is called by all cpus and the system system will boot into the dump-capture kernel. | ||||
| On powererpc systems when a soft-reset is generated, die() is called by all cpus and the system will boot into the dump-capture kernel. | ||||
| 
 | ||||
| For testing purposes, you can trigger a crash by using "ALT-SysRq-c", | ||||
| "echo c > /proc/sysrq-trigger or write a module to force the panic. | ||||
|  | ||||
| @ -290,17 +290,6 @@ | ||||
|        Description: Very nice 92 pages GPL book on the topic of modules | ||||
|        programming. Lots of examples. | ||||
|         | ||||
|      * Title: "Device File System (devfs) Overview" | ||||
|        Author: Richard Gooch. | ||||
|        URL: http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html | ||||
|        Keywords: filesystem, /dev, devfs, dynamic devices, major/minor | ||||
|        allocation, device management. | ||||
|        Description: Document describing Richard Gooch's controversial | ||||
|        devfs, which allows for dynamic devices, only shows present | ||||
|        devices in /dev, gets rid of major/minor numbers allocation | ||||
|        problems, and allows for hundreds of identical devices (which some | ||||
|        USB systems might demand soon). | ||||
|         | ||||
|      * Title: "I/O Event Handling Under Linux" | ||||
|        Author: Richard Gooch. | ||||
|        URL: http://www.atnf.csiro.au/~rgooch/linux/docs/io-events.html | ||||
|  | ||||
| @ -355,9 +355,9 @@ and is between 256 and 4096 characters. It is defined in the file | ||||
| 
 | ||||
| 	clock=		[BUGS=IA-32, HW] gettimeofday clocksource override. | ||||
| 			[Deprecated] | ||||
| 			Forces specified clocksource (if avaliable) to be used | ||||
| 			Forces specified clocksource (if available) to be used | ||||
| 			when calculating gettimeofday(). If specified | ||||
| 			clocksource is not avalible, it defaults to PIT. | ||||
| 			clocksource is not available, it defaults to PIT. | ||||
| 			Format: { pit | tsc | cyclone | pmtmr } | ||||
| 
 | ||||
| 	disable_8254_timer | ||||
| @ -611,8 +611,8 @@ and is between 256 and 4096 characters. It is defined in the file | ||||
| 	noirqbalance	[IA-32,SMP,KNL] Disable kernel irq balancing | ||||
| 
 | ||||
| 	i8042.direct	[HW] Put keyboard port into non-translated mode | ||||
| 	i8042.dumbkbd	[HW] Pretend that controlled can only read data from | ||||
| 			     keyboard and can not control its state | ||||
| 	i8042.dumbkbd	[HW] Pretend that controller can only read data from | ||||
| 			     keyboard and cannot control its state | ||||
| 			     (Don't attempt to blink the leds) | ||||
| 	i8042.noaux	[HW] Don't check for auxiliary (== mouse) port | ||||
| 	i8042.nokbd	[HW] Don't check/create keyboard port | ||||
| @ -1368,7 +1368,7 @@ and is between 256 and 4096 characters. It is defined in the file | ||||
| 
 | ||||
| 	reboot=		[BUGS=IA-32,BUGS=ARM,BUGS=IA-64] Rebooting mode | ||||
| 			Format: <reboot_mode>[,<reboot_mode2>[,...]] | ||||
| 			See arch/*/kernel/reboot.c. | ||||
| 			See arch/*/kernel/reboot.c or arch/*/kernel/process.c			 | ||||
| 
 | ||||
| 	reserve=	[KNL,BUGS] Force the kernel to ignore some iomem area | ||||
| 
 | ||||
|  | ||||
| @ -671,7 +671,7 @@ The keyctl syscall functions are: | ||||
| 
 | ||||
|      Note that this setting is inherited across fork/exec. | ||||
| 
 | ||||
|      [1] The default default is: the thread keyring if there is one, otherwise | ||||
|      [1] The default is: the thread keyring if there is one, otherwise | ||||
|      the process keyring if there is one, otherwise the session keyring if | ||||
|      there is one, otherwise the user default session keyring. | ||||
| 
 | ||||
| @ -708,14 +708,14 @@ The keyctl syscall functions are: | ||||
| 
 | ||||
|      If the specified key is 0, then any assumed authority will be divested. | ||||
| 
 | ||||
|      The assumed authorititive key is inherited across fork and exec. | ||||
|      The assumed authoritative key is inherited across fork and exec. | ||||
| 
 | ||||
| 
 | ||||
| =============== | ||||
| KERNEL SERVICES | ||||
| =============== | ||||
| 
 | ||||
| The kernel services for key managment are fairly simple to deal with. They can | ||||
| The kernel services for key management are fairly simple to deal with. They can | ||||
| be broken down into two areas: keys and key types. | ||||
| 
 | ||||
| Dealing with keys is fairly straightforward. Firstly, the kernel service | ||||
|  | ||||
| @ -51,7 +51,7 @@ more complex object types. It provides a set of basic fields that | ||||
| almost all complex data types share. kobjects are intended to be | ||||
| embedded in larger data structures and replace fields they duplicate.  | ||||
| 
 | ||||
| 1.2 Defintion | ||||
| 1.2 Definition | ||||
| 
 | ||||
| struct kobject { | ||||
| 	char			name[KOBJ_NAME_LEN]; | ||||
|  | ||||
| @ -152,7 +152,7 @@ loaded on demand while the application executes) and sequentially accessed data | ||||
| DO_REMOUNTS: | ||||
| 
 | ||||
| The control script automatically remounts any mounted journaled filesystems | ||||
| with approriate commit interval options. When this option is set to 0, this | ||||
| with appropriate commit interval options. When this option is set to 0, this | ||||
| feature is disabled. | ||||
| 
 | ||||
| DO_REMOUNT_NOATIME: | ||||
|  | ||||
| @ -133,7 +133,7 @@ cases there is an inherent "natural" ordering between the two objects | ||||
| (defined by the properties of the hierarchy), and the kernel grabs the | ||||
| locks in this fixed order on each of the objects. | ||||
| 
 | ||||
| An example of such an object hieararchy that results in "nested locking" | ||||
| An example of such an object hierarchy that results in "nested locking" | ||||
| is that of a "whole disk" block-dev object and a "partition" block-dev | ||||
| object; the partition is "part of" the whole device and as long as one | ||||
| always takes the whole disk lock as a higher lock than the partition | ||||
| @ -158,11 +158,11 @@ enum bdev_bd_mutex_lock_class | ||||
| In this case the locking is done on a bdev object that is known to be a | ||||
| partition. | ||||
| 
 | ||||
| The validator treats a lock that is taken in such a nested fasion as a | ||||
| The validator treats a lock that is taken in such a nested fashion as a | ||||
| separate (sub)class for the purposes of validation. | ||||
| 
 | ||||
| Note: When changing code to use the _nested() primitives, be careful and | ||||
| check really thoroughly that the hiearchy is correctly mapped; otherwise | ||||
| check really thoroughly that the hierarchy is correctly mapped; otherwise | ||||
| you can get false positives or false negatives. | ||||
| 
 | ||||
| Proof of 100% correctness: | ||||
| @ -170,7 +170,7 @@ Proof of 100% correctness: | ||||
| 
 | ||||
| The validator achieves perfect, mathematical 'closure' (proof of locking | ||||
| correctness) in the sense that for every simple, standalone single-task | ||||
| locking sequence that occured at least once during the lifetime of the | ||||
| locking sequence that occurred at least once during the lifetime of the | ||||
| kernel, the validator proves it with a 100% certainty that no | ||||
| combination and timing of these locking sequences can cause any class of | ||||
| lock related deadlock. [*] | ||||
|  | ||||
| @ -415,7 +415,7 @@ switch to another mode once Linux has started. | ||||
| 
 | ||||
|   The first 3 parameters of this sub-option should be obvious: <xres>, | ||||
| <yres> and <depth> give the dimensions of the screen and the number of | ||||
| planes (depth). The depth is is the logarithm to base 2 of the number | ||||
| planes (depth). The depth is the logarithm to base 2 of the number | ||||
| of colors possible. (Or, the other way round: The number of colors is | ||||
| 2^depth). | ||||
| 
 | ||||
|  | ||||
| @ -177,7 +177,7 @@ Currently, there are a number of MCA-specific device drivers. | ||||
| 	with clones that have a different adapter id than the original | ||||
| 	NE/2. | ||||
| 
 | ||||
| 6) Future Domain MCS-600/700, OEM'd IBM Fast SCSI Aapter/A and | ||||
| 6) Future Domain MCS-600/700, OEM'd IBM Fast SCSI Adapter/A and | ||||
|    Reply Sound Blaster/SCSI (SCSI part) | ||||
| 	Better support for these cards than the driver for ISA. | ||||
|    Supports multiple cards with IRQ sharing. | ||||
|  | ||||
| @ -62,7 +62,7 @@ be reconstructed (due to no parity). | ||||
| 
 | ||||
| For this reason, md will normally refuse to start such an array.  This | ||||
| requires the sysadmin to take action to explicitly start the array | ||||
| desipite possible corruption.  This is normally done with | ||||
| despite possible corruption.  This is normally done with | ||||
|    mdadm --assemble --force .... | ||||
| 
 | ||||
| This option is not really available if the array has the root | ||||
| @ -175,7 +175,7 @@ All md devices contain: | ||||
|      raid levels that involve striping (1,4,5,6,10). The address space | ||||
|      of the array is conceptually divided into chunks and consecutive | ||||
|      chunks are striped onto neighbouring devices. | ||||
|      The size should be atleast PAGE_SIZE (4k) and should be a power | ||||
|      The size should be at least PAGE_SIZE (4k) and should be a power | ||||
|      of 2.  This can only be set while assembling an array | ||||
| 
 | ||||
|   component_size | ||||
| @ -214,8 +214,8 @@ All md devices contain: | ||||
|    safe_mode_delay | ||||
|      When an md array has seen no write requests for a certain period | ||||
|      of time, it will be marked as 'clean'.  When another write | ||||
|      request arrive, the array is marked as 'dirty' before the write | ||||
|      commenses.  This is known as 'safe_mode'. | ||||
|      request arrives, the array is marked as 'dirty' before the write | ||||
|      commences.  This is known as 'safe_mode'. | ||||
|      The 'certain period' is controlled by this file which stores the | ||||
|      period as a number of seconds.  The default is 200msec (0.200). | ||||
|      Writing a value of 0 disables safemode. | ||||
| @ -307,8 +307,8 @@ Each directory contains: | ||||
| 			 This applies only to raid1 arrays. | ||||
| 	      spare    - device is working, but not a full member. | ||||
| 			 This includes spares that are in the process | ||||
| 			 of being recoverred to | ||||
| 	This list make grow in future. | ||||
| 			 of being recovered to | ||||
| 	This list may grow in future. | ||||
| 	This can be written to. | ||||
| 	Writing "faulty"  simulates a failure on the device. | ||||
| 	Writing "remove" removes the device from the array. | ||||
| @ -330,7 +330,7 @@ Each directory contains: | ||||
|         This gives the role that the device has in the array.  It will | ||||
| 	either be 'none' if the device is not active in the array | ||||
|         (i.e. is a spare or has failed) or an integer less than the | ||||
| 	'raid_disks' number for the array indicating which possition | ||||
| 	'raid_disks' number for the array indicating which position | ||||
| 	it currently fills.  This can only be set while assembling an | ||||
| 	array.  A device for which this is set is assumed to be working. | ||||
| 
 | ||||
| @ -353,7 +353,7 @@ in the array.  These are named | ||||
| 
 | ||||
|     rdNN | ||||
| 
 | ||||
| where 'NN' is the possition in the array, starting from 0. | ||||
| where 'NN' is the position in the array, starting from 0. | ||||
| So for a 3 drive array there will be rd0, rd1, rd2. | ||||
| These are symbolic links to the appropriate 'dev-XXX' entry. | ||||
| Thus, for example, | ||||
|  | ||||
| @ -670,7 +670,7 @@ effectively random order, despite the write barrier issued by CPU 1: | ||||
| 
 | ||||
| 
 | ||||
| In the above example, CPU 2 perceives that B is 7, despite the load of *C | ||||
| (which would be B) coming after the the LOAD of C. | ||||
| (which would be B) coming after the LOAD of C. | ||||
| 
 | ||||
| If, however, a data dependency barrier were to be placed between the load of C | ||||
| and the load of *C (ie: B) on CPU 2: | ||||
| @ -1915,7 +1915,7 @@ Whilst most CPUs do imply a data dependency barrier on the read when a memory | ||||
| access depends on a read, not all do, so it may not be relied on. | ||||
| 
 | ||||
| Other CPUs may also have split caches, but must coordinate between the various | ||||
| cachelets for normal memory accesss.  The semantics of the Alpha removes the | ||||
| cachelets for normal memory accesses.  The semantics of the Alpha removes the | ||||
| need for coordination in absence of memory barriers. | ||||
| 
 | ||||
| 
 | ||||
|  | ||||
| @ -26,7 +26,7 @@ other program after you have done the following: | ||||
|    the kernel (CONFIG_BINFMT_MISC) and set it up properly. | ||||
|    If you choose to compile it as a module, you will have | ||||
|    to insert it manually with modprobe/insmod, as kmod | ||||
|    can not be easily supported with binfmt_misc.  | ||||
|    cannot be easily supported with binfmt_misc.  | ||||
|    Read the file 'binfmt_misc.txt' in this directory to know | ||||
|    more about the configuration process. | ||||
| 
 | ||||
|  | ||||
| @ -126,7 +126,7 @@ packets faster than they can be removed from the card. This should be rare | ||||
| or impossible in normal operation. Possible causes of this error report are: | ||||
|   | ||||
|    - a "green" mode enabled that slows the processor down when there is no | ||||
|      keyboard activitiy.  | ||||
|      keyboard activity.  | ||||
| 
 | ||||
|    - some other device or device driver hogging the bus or disabling interrupts. | ||||
|      Check /proc/interrupts for excessive interrupt counts. The timer tick | ||||
|  | ||||
| @ -35,7 +35,7 @@ Legend: | ||||
| packets out of the rx ring. Note from this that the lower the | ||||
| load the more we could clean up the rxring | ||||
| "Ndone" == is the converse of "Done". Note again, that the higher | ||||
| the load the more times we couldnt clean up the rxring. | ||||
| the load the more times we couldn't clean up the rxring. | ||||
| 
 | ||||
| Observe that: | ||||
| when the NIC receives 890Kpackets/sec only 17 rx interrupts are generated.  | ||||
|  | ||||
| @ -139,7 +139,7 @@ And now to the cabling.  What you can connect together: | ||||
| 
 | ||||
| 5. An active hub to passive hub. | ||||
| 
 | ||||
| Remember, that you can not connect two passive hubs together.  The power loss | ||||
| Remember that you cannot connect two passive hubs together.  The power loss | ||||
| implied by such a connection is too high for the net to operate reliably. | ||||
| 
 | ||||
| An example of a typical ARCnet network: | ||||
|  | ||||
| @ -1023,7 +1023,7 @@ Changing a Bond's Configuration | ||||
| files located in /sys/class/net/<bond name>/bonding | ||||
| 
 | ||||
| 	The names of these files correspond directly with the command- | ||||
| line parameters described elsewhere in in this file, and, with the | ||||
| line parameters described elsewhere in this file, and, with the | ||||
| exception of arp_ip_target, they accept the same values.  To see the | ||||
| current setting, simply cat the appropriate file. | ||||
| 
 | ||||
|  | ||||
| @ -227,7 +227,7 @@ configuration options are available on the command line: | ||||
| * media=rj45           - specify media type | ||||
|    or media=bnc | ||||
|    or media=aui | ||||
|    or medai=auto | ||||
|    or media=auto | ||||
| * duplex=full          - specify forced half/full/autonegotiate duplex | ||||
|    or duplex=half | ||||
|    or duplex=auto | ||||
| @ -584,7 +584,7 @@ of four ways after installing and or configuring the CS8900/20-based adapter: | ||||
| 
 | ||||
|     1.) The system does not boot properly (or at all). | ||||
| 
 | ||||
|     2.) The driver can not communicate with the adapter, reporting an "Adapter | ||||
|     2.) The driver cannot communicate with the adapter, reporting an "Adapter | ||||
|         not found" error message. | ||||
| 
 | ||||
|     3.) You cannot connect to the network or the driver will not load. | ||||
| @ -684,7 +684,7 @@ ethernet@crystal.cirrus.com) and request that you be registered for automatic | ||||
| software-update notification. | ||||
| 
 | ||||
| Cirrus Logic maintains a web page at http://www.cirrus.com with the | ||||
| the latest drivers and technical publications. | ||||
| latest drivers and technical publications. | ||||
| 
 | ||||
| 
 | ||||
| 6.4 Current maintainer | ||||
|  | ||||
| @ -56,7 +56,7 @@ FEATURES | ||||
| 
 | ||||
|       ethtool -C eth0 rx-usecs 100 | ||||
| 
 | ||||
|   You may also provide a timer latency value while disabling adpative-rx: | ||||
|   You may also provide a timer latency value while disabling adaptive-rx: | ||||
| 
 | ||||
|       ethtool -C <interface> adaptive-rx off rx-usecs <microseconds> | ||||
| 
 | ||||
| @ -172,7 +172,7 @@ PERFORMANCE | ||||
|    smaller window prevents congestion and facilitates better pacing, | ||||
|    especially if/when MAC level flow control does not work well or when it is | ||||
|    not supported on the machine. Experimentation may be necessary to attain | ||||
|    the correct value. This method is provided as a starting point fot the | ||||
|    the correct value. This method is provided as a starting point for the | ||||
|    correct receive buffer size. | ||||
|    Setting the min, max, and default receive buffer (RX_WINDOW) size is | ||||
|    performed in the same manner as single connection. | ||||
|  | ||||
| @ -82,7 +82,7 @@ ethernet address of your ethernet card has to be set according to the DECnet | ||||
| address of the node in order for it to be autoconfigured (and then appear in | ||||
| /proc/net/decnet_dev). There is a utility available at the above | ||||
| FTP sites called dn2ethaddr which can compute the correct ethernet | ||||
| address to use. The address can be set by ifconfig either before at | ||||
| address to use. The address can be set by ifconfig either before or | ||||
| at the time the device is brought up. If you are using RedHat you can | ||||
| add the line: | ||||
| 
 | ||||
|  | ||||
| @ -173,7 +173,7 @@ Installing the Driver | ||||
| 
 | ||||
| Parameter Description | ||||
| ===================== | ||||
| You can install this driver without any addtional parameter. However, if you | ||||
| You can install this driver without any additional parameter. However, if you | ||||
| are going to have extensive functions then it is necessary to set extra | ||||
| parameter. Below is a list of the command line parameters supported by the | ||||
| Linux device | ||||
| @ -222,7 +222,7 @@ rx_timeout=n			- Rx DMA wait time for an interrupt. | ||||
| 				  reach timeout of n * 640 nano seconds.  | ||||
| 				  Set proper rx_coalesce and rx_timeout can  | ||||
| 				  reduce congestion collapse and overload which | ||||
| 				  has been a bottlenect for high speed network. | ||||
| 				  has been a bottleneck for high speed network. | ||||
| 				   | ||||
| 				  For example, rx_coalesce=10 rx_timeout=800. | ||||
| 				  that is, hardware assert only 1 interrupt  | ||||
|  | ||||
| @ -34,7 +34,7 @@ Next you should configure your network interface with a command similar to : | ||||
| 
 | ||||
| 	ifconfig eth0 172.22.3.18 | ||||
|                       ^^^^^^^^^^^ | ||||
| 		     Your IP Adress | ||||
| 		     Your IP Address | ||||
| 
 | ||||
| Then you may have to modify the default routing table with command : | ||||
| 
 | ||||
|  | ||||
| @ -37,7 +37,7 @@ Transmit path guidelines: | ||||
| 		... | ||||
| 	} | ||||
| 
 | ||||
|    And then at the end of your TX reclaimation event handling: | ||||
|    And then at the end of your TX reclamation event handling: | ||||
| 
 | ||||
| 	if (netif_queue_stopped(dp->dev) && | ||||
|             TX_BUFFS_AVAIL(dp) > (MAX_SKB_FRAGS + 1)) | ||||
|  | ||||
| @ -350,7 +350,7 @@ Additional Configurations | ||||
| 
 | ||||
|   As an example, if you install the e1000 driver for two PRO/1000 adapters | ||||
|   (eth0 and eth1) and set the speed and duplex to 10full and 100half, add | ||||
|   the following to modules.conf or or modprobe.conf: | ||||
|   the following to modules.conf or modprobe.conf: | ||||
| 
 | ||||
|        alias eth0 e1000 | ||||
|        alias eth1 e1000 | ||||
|  | ||||
| @ -79,7 +79,7 @@ trie_rebalance() | ||||
| 
 | ||||
| resize() | ||||
| 	Analyzes a tnode and optimizes the child array size by either inflating | ||||
| 	or shrinking it repeatedly until it fullfills the criteria for optimal | ||||
| 	or shrinking it repeatedly until it fulfills the criteria for optimal | ||||
| 	level compression. This part follows the original paper pretty closely | ||||
| 	and there may be some room for experimentation here. | ||||
| 
 | ||||
|  | ||||
| @ -79,8 +79,8 @@ Rate Estimator: | ||||
| 
 | ||||
| 0) Prepare an estimator attribute. Most likely this would be in user | ||||
|    space. The value of this TLV should contain a tc_estimator structure. | ||||
|    As usual, such a TLV nees to be 32 bit aligned and therefore the | ||||
|    length needs to be appropriately set etc. The estimator interval | ||||
|    As usual, such a TLV needs to be 32 bit aligned and therefore the | ||||
|    length needs to be appropriately set, etc. The estimator interval | ||||
|    and ewma log need to be converted to the appropriate values. | ||||
|    tc_estimator.c::tc_setup_estimator() is advisable to be used as the | ||||
|    conversion routine. It does a few clever things. It takes a time | ||||
| @ -103,8 +103,8 @@ In the kernel when setting up: | ||||
|    else | ||||
|        failed | ||||
| 
 | ||||
| From now on, everytime you dump my_rate_est_stats it will contain | ||||
| uptodate info. | ||||
| From now on, every time you dump my_rate_est_stats it will contain | ||||
| up-to-date info. | ||||
| 
 | ||||
| Once you are done, call gen_kill_estimator(my_basicstats, | ||||
| my_rate_est_stats) Make sure that my_basicstats and my_rate_est_stats | ||||
|  | ||||
| @ -495,7 +495,7 @@ icmp_errors_use_inbound_ifaddr - BOOLEAN | ||||
| 
 | ||||
| 	Note that if no primary address exists for the interface selected, | ||||
| 	then the primary address of the first non-loopback interface that | ||||
| 	has one will be used regarldess of this setting. | ||||
| 	has one will be used regardless of this setting. | ||||
| 
 | ||||
| 	Default: 0 | ||||
| 
 | ||||
| @ -787,7 +787,7 @@ accept_ra_defrtr - BOOLEAN | ||||
| 			    disabled if accept_ra is disabled. | ||||
| 
 | ||||
| accept_ra_pinfo - BOOLEAN | ||||
| 	Learn Prefix Inforamtion in Router Advertisement. | ||||
| 	Learn Prefix Information in Router Advertisement. | ||||
| 
 | ||||
| 	Functional default: enabled if accept_ra is enabled. | ||||
| 			    disabled if accept_ra is disabled. | ||||
|  | ||||
Some files were not shown because too many files have changed in this diff Show More
		Loading…
	
		Reference in New Issue
	
	Block a user