mirror of
https://github.com/torvalds/linux.git
synced 2024-12-26 12:52:30 +00:00
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