mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-30 22:26:55 +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
596 changed files with 1095 additions and 1333 deletions
8
CREDITS
8
CREDITS
|
@ -34,6 +34,7 @@ E: magrawal@nortelnetworks.com
|
||||||
D: Basic Interphase 5575 driver with UBR and ABR support.
|
D: Basic Interphase 5575 driver with UBR and ABR support.
|
||||||
S: 75 Donald St, Apt 42
|
S: 75 Donald St, Apt 42
|
||||||
S: Weymouth, MA 02188
|
S: Weymouth, MA 02188
|
||||||
|
S: USA
|
||||||
|
|
||||||
N: Dave Airlie
|
N: Dave Airlie
|
||||||
E: airlied@linux.ie
|
E: airlied@linux.ie
|
||||||
|
@ -202,6 +203,7 @@ S: MS42
|
||||||
S: Hewlett-Packard
|
S: Hewlett-Packard
|
||||||
S: 3404 E Harmony Rd
|
S: 3404 E Harmony Rd
|
||||||
S: Fort Collins, CO 80525
|
S: Fort Collins, CO 80525
|
||||||
|
S: USA
|
||||||
|
|
||||||
N: Arindam Banerji
|
N: Arindam Banerji
|
||||||
E: axb@cse.nd.edu
|
E: axb@cse.nd.edu
|
||||||
|
@ -444,6 +446,7 @@ E: rbradetich@uswest.net
|
||||||
D: Linux/PA-RISC hacker
|
D: Linux/PA-RISC hacker
|
||||||
S: 1200 Goldenrod Dr.
|
S: 1200 Goldenrod Dr.
|
||||||
S: Nampa, Idaho 83686
|
S: Nampa, Idaho 83686
|
||||||
|
S: USA
|
||||||
|
|
||||||
N: Derrick J. Brashear
|
N: Derrick J. Brashear
|
||||||
E: shadow@dementia.org
|
E: shadow@dementia.org
|
||||||
|
@ -633,6 +636,7 @@ E: scole@lanl.gov
|
||||||
E: elenstev@mesatop.com
|
E: elenstev@mesatop.com
|
||||||
D: Various build fixes and kernel documentation.
|
D: Various build fixes and kernel documentation.
|
||||||
S: Los Alamos, New Mexico
|
S: Los Alamos, New Mexico
|
||||||
|
S: USA
|
||||||
|
|
||||||
N: Hamish Coleman
|
N: Hamish Coleman
|
||||||
E: hamish@zot.apana.org.au
|
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
|
D: Busmaster driver for HP 10/100 Mbit Network Adapters
|
||||||
S: University of Stuttgart, Germany and
|
S: University of Stuttgart, Germany and
|
||||||
S: Ecole Nationale Superieure des Telecommunications, Paris
|
S: Ecole Nationale Superieure des Telecommunications, Paris
|
||||||
|
S: France
|
||||||
|
|
||||||
N: Jamie Lokier
|
N: Jamie Lokier
|
||||||
E: jamie@shareable.org
|
E: jamie@shareable.org
|
||||||
|
@ -2178,6 +2183,7 @@ S: Hewlett Packard
|
||||||
S: MS 42
|
S: MS 42
|
||||||
S: 3404 E. Harmony Road
|
S: 3404 E. Harmony Road
|
||||||
S: Fort Collins, CO 80528
|
S: Fort Collins, CO 80528
|
||||||
|
S: USA
|
||||||
|
|
||||||
N: Torben Mathiasen
|
N: Torben Mathiasen
|
||||||
E: torben.mathiasen@compaq.com
|
E: torben.mathiasen@compaq.com
|
||||||
|
@ -3658,7 +3664,7 @@ S: Portland, OR
|
||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
N: Michal Wronski
|
N: Michal Wronski
|
||||||
E: Michal.Wronski@motorola.com
|
E: michal.wronski@gmail.com
|
||||||
D: POSIX message queues fs (with K. Benedyczak)
|
D: POSIX message queues fs (with K. Benedyczak)
|
||||||
S: Krakow
|
S: Krakow
|
||||||
S: Poland
|
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);
|
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():
|
pci_set_consistent_dma_mask():
|
||||||
|
|
||||||
int pci_set_consistent_dma_mask(struct pci_dev *pdev, u64 device_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
|
device supports. It returns zero if your card can perform DMA
|
||||||
properly on the machine given the address mask you provided.
|
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
|
this platform, and attempting to do so will result in undefined
|
||||||
behavior. You must either use a different mask, or not use DMA.
|
behavior. You must either use a different mask, or not use DMA.
|
||||||
|
|
||||||
|
|
|
@ -1400,7 +1400,7 @@ and other resources, etc.
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
When it's known that HBA is in ready state but ATA/ATAPI
|
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>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
|
|
|
@ -314,8 +314,7 @@
|
||||||
<emphasis>usbdevfs</emphasis> although it wasn't solving what
|
<emphasis>usbdevfs</emphasis> although it wasn't solving what
|
||||||
<emphasis>devfs</emphasis> was.
|
<emphasis>devfs</emphasis> was.
|
||||||
Every USB device will appear in usbfs, regardless of whether or
|
Every USB device will appear in usbfs, regardless of whether or
|
||||||
not it has a kernel driver; but only devices with kernel drivers
|
not it has a kernel driver.
|
||||||
show up in devfs.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<sect1>
|
<sect1>
|
||||||
|
@ -741,7 +740,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
|
||||||
<title>Synchronous I/O Support</title>
|
<title>Synchronous I/O Support</title>
|
||||||
|
|
||||||
<para>Synchronous requests involve the kernel blocking
|
<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.
|
finishing successfully or by reporting an error.
|
||||||
In most cases this is the simplest way to use usbfs,
|
In most cases this is the simplest way to use usbfs,
|
||||||
although as noted above it does prevent performing I/O
|
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
|
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
|
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
|
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
|
pending urbs that are in the USB system.
|
||||||
itself from the devfs subsystem with the call:
|
|
||||||
</para>
|
</para>
|
||||||
<programlisting>
|
|
||||||
/* remove our devfs node */
|
|
||||||
devfs_unregister(skel->devfs);
|
|
||||||
</programlisting>
|
|
||||||
<para>
|
<para>
|
||||||
Now that the device is plugged into the system and the driver is bound to
|
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
|
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
|
Setting smb_dbg_probe to 1 will enable debugging of the probing and
|
||||||
detection process for BMCs on the SMBusses.
|
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
|
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.
|
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
|
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
|
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.
|
parameter is provided.
|
||||||
|
|
||||||
When compiled into the kernel, the addresses can be specified on the
|
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
|
vector reserved to avoid the case where some MSI-X capable
|
||||||
drivers may attempt to claim all available vector resources.
|
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
|
This policy ensures that maximum (x - y) is distributed
|
||||||
evenly among MSI-X capable devices.
|
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()
|
and release a global reader-writer lock. The synchronize_rcu()
|
||||||
primitive write-acquires this same lock, then immediately releases
|
primitive write-acquires this same lock, then immediately releases
|
||||||
it. This means that once synchronize_rcu() exits, all RCU read-side
|
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
|
called are guaranteed to have completed -- there is no way that
|
||||||
synchronize_rcu() would have been able to write-acquire the lock
|
synchronize_rcu() would have been able to write-acquire the lock
|
||||||
otherwise.
|
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
|
Either way, the differences are quite small. Read-side locking moves
|
||||||
to rcu_read_lock() and rcu_read_unlock, update-side locking moves from
|
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().
|
precedes the kfree().
|
||||||
|
|
||||||
However, there is one potential catch: the read-side and update-side
|
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.
|
deadlock under memory pressure.
|
||||||
|
|
||||||
Because ATA over Ethernet is not fragmented by the kernel's IP code,
|
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
|
driver. By using a mempool for allocating all but the first few
|
||||||
sk_buffs, and by registering a destructor, we should be able to
|
sk_buffs, and by registering a destructor, we should be able to
|
||||||
efficiently allocate sk_buffs without introducing any potential for
|
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
|
> 7 = /dev/cusa2 Callout device for ttySA2
|
||||||
>
|
>
|
||||||
|
|
||||||
If you're not using devfs, you must create those inodes in /dev
|
You must create those inodes in /dev on the root filesystem used
|
||||||
on the root filesystem used by your SA1100-based device:
|
by your SA1100-based device:
|
||||||
|
|
||||||
mknod ttySA0 c 204 5
|
mknod ttySA0 c 204 5
|
||||||
mknod ttySA1 c 204 6
|
mknod ttySA1 c 204 6
|
||||||
|
|
|
@ -38,7 +38,7 @@ MTD
|
||||||
---
|
---
|
||||||
|
|
||||||
The NAND and NOR support has been merged from the linux-mtd project.
|
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.
|
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
|
header include/asm-arm/arch-s3c2410/hardware.h which can be
|
||||||
included by #include <asm/arch/hardware.h>
|
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.
|
header on how the GPIO functions (and others) work.
|
||||||
|
|
||||||
Whilst a number of these functions do make some checks on what
|
Whilst a number of these functions do make some checks on what
|
||||||
|
|
|
@ -80,7 +80,7 @@ Machines
|
||||||
Adding New 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
|
be configured for it in one kernel build, and any future additions
|
||||||
should keep this in mind before altering items outside of their own
|
should keep this in mind before altering items outside of their own
|
||||||
machine files.
|
machine files.
|
||||||
|
|
|
@ -80,7 +80,7 @@ RTC
|
||||||
Watchdog
|
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.
|
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
|
at a time during a write batch. It is this characteristic that can make
|
||||||
the anticipatory scheduler perform anomalously with controllers supporting
|
the anticipatory scheduler perform anomalously with controllers supporting
|
||||||
TCQ, or with hardware striped RAID devices. Setting the antic_expire
|
TCQ, or with hardware striped RAID devices. Setting the antic_expire
|
||||||
queue paramter (see below) to zero disables this behavior, and the anticipatory
|
queue parameter (see below) to zero disables this behavior, and the
|
||||||
scheduler behaves essentially like the deadline scheduler.
|
anticipatory scheduler behaves essentially like the deadline scheduler.
|
||||||
|
|
||||||
When read anticipation is enabled (antic_expire is not zero), reads
|
When read anticipation is enabled (antic_expire is not zero), reads
|
||||||
are dispatched to the disk controller one at a time.
|
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
|
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
|
support ordered tags, block layer can just issue the barrier as an
|
||||||
ordered request and the lower level driver, controller and drive
|
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.
|
met. Most modern SCSI controllers/drives should support this.
|
||||||
|
|
||||||
NOTE: SCSI ordered tag isn't currently used due to limitation in the
|
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
|
of ii. Just keeping issue order suffices. Ancient SCSI
|
||||||
controllers/drives and IDE drives are in this category.
|
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,
|
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
|
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.
|
i. No write-back cache. Keeping requests ordered is enough.
|
||||||
|
|
||||||
ii. Write-back cache but no flush operation. There's no way to
|
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.
|
I/O barriers.
|
||||||
|
|
||||||
iii. Write-back cache and flush operation but no FUA (forced unit
|
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.
|
Sets two variables that limit the size of the request.
|
||||||
|
|
||||||
- The request queue's max_sectors, which is a soft size in
|
- 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.
|
by the core kernel.
|
||||||
|
|
||||||
- The request queue's max_hw_sectors, which is a hard limit
|
- 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)
|
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
|
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
|
next request_fn run, just like it did the first time it encountered
|
||||||
them.
|
them.
|
||||||
|
@ -890,7 +890,7 @@ Aside:
|
||||||
|
|
||||||
Kvec i/o:
|
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>
|
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
|
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
|
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.
|
for a queue.
|
||||||
|
|
||||||
4.2 Request flows seen by I/O schedulers
|
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.
|
flows.
|
||||||
|
|
||||||
set_req_fn ->
|
set_req_fn ->
|
||||||
|
@ -1203,6 +1203,6 @@ temporarily map a bio into the virtual address space.
|
||||||
and Linus' comments - Jan 2001)
|
and Linus' comments - Jan 2001)
|
||||||
9.2 Discussions about kiobuf and bh design on lkml between sct, linus, alan
|
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
|
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.
|
9.3 Discussions on mempool on lkml - Dec 2001.
|
||||||
|
|
||||||
|
|
|
@ -23,11 +23,11 @@ you can do so by typing:
|
||||||
read_expire (in ms)
|
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
|
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
|
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
|
a deadline that is the current time + the read_expire value in units of
|
||||||
miliseconds.
|
milliseconds.
|
||||||
|
|
||||||
|
|
||||||
write_expire (in ms)
|
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
|
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
|
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
|
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 example:
|
||||||
|
|
||||||
for x in /proc/driver/cciss/cciss[0-9]*
|
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
|
implements the first two of these actions, aborting the command, and
|
||||||
resetting the device. Additionally, most tape drives will not oblige
|
resetting the device. Additionally, most tape drives will not oblige
|
||||||
in aborting commands, and sometimes it appears they will not even
|
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
|
the case that the command cannot be aborted and the device cannot be
|
||||||
reset, the device will be set offline.
|
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
|
Linux tty naming conventions: ttyF0 - ttyF255 for normal devices, and
|
||||||
cuf0 - cuf255 for callout devices.
|
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
|
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
|
use the ip2mkdev script, you must have procfs enabled and the proc file
|
||||||
system mounted on /proc.
|
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. NOTES
|
||||||
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
|
|
||||||
|
|
||||||
This is a release version of the driver, but it is impossible to test it
|
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
|
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.
|
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
|
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.
|
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
|
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
|
1. Introduction
|
||||||
|
|
||||||
cpufreq-stats is a driver that provices CPU frequency statistics for each CPU.
|
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
|
These statistics are provided in /sysfs as a bunch of read_only interfaces. This
|
||||||
interface (when configured) will appear in a seperate directory under cpufreq
|
interface (when configured) will appear in a separate directory under cpufreq
|
||||||
in /sysfs (<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU.
|
in /sysfs (<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU.
|
||||||
Various statistics will form read_only files under this directory.
|
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 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
|
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 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).
|
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)
|
"CPU frequency translation statistics details" (CONFIG_CPU_FREQ_STAT_DETAILS)
|
||||||
provides fine grained cpufreq stats by trans_table. The reason for having a
|
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
|
- 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
|
interface. It provides a whole bunch of value in a 2 dimensional matrix
|
||||||
form.
|
form.
|
||||||
|
|
|
@ -57,7 +57,7 @@ selected for each specific use.
|
||||||
|
|
||||||
Basically, it's the following flow graph:
|
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
|
within specific "limits" | to specific frequencies
|
||||||
|
|
||||||
"CPUfreq policy"
|
"CPUfreq policy"
|
||||||
|
@ -109,7 +109,7 @@ directory.
|
||||||
2.4 Ondemand
|
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
|
current usage. To do this the CPU must have the capability to
|
||||||
switch the frequency very quickly. There are a number of sysfs file
|
switch the frequency very quickly. There are a number of sysfs file
|
||||||
accessible parameters:
|
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 '1' then the frequency decreases as quickly as it increases,
|
||||||
if set to '2' it decreases at half the rate of the increase.
|
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
|
ignore_nice_load: this parameter takes a value of '0' or '1'. When
|
||||||
to '0' (its default) then all processes are counted towards towards the
|
set to '0' (its default), all processes are counted towards the
|
||||||
'cpu utilisation' value. When set to '1' then processes that are
|
'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
|
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
|
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
|
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.
|
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.
|
The type of siblings is cpumask_t.
|
||||||
|
|
||||||
To be consistent on all architectures, the 4 attributes should have
|
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
|
1) physical_package_id: If cpu has no physical package id, -1 is the
|
||||||
default value.
|
default value.
|
||||||
2) core_id: If cpu doesn't support multi-core, its core id is 0.
|
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:
|
Scope:
|
||||||
This document discusses the functionality of the rbu driver only.
|
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.
|
update itself with the image downloaded in to the memory.
|
||||||
|
|
||||||
Overview:
|
Overview:
|
||||||
|
@ -16,8 +16,8 @@ OpenManage and Dell Update packages (DUP).
|
||||||
Libsmbios can also be used to update BIOS on Dell systems go to
|
Libsmbios can also be used to update BIOS on Dell systems go to
|
||||||
http://linux.dell.com/libsmbios/ for details.
|
http://linux.dell.com/libsmbios/ for details.
|
||||||
|
|
||||||
Dell_RBU driver supports BIOS update using the monilothic image and packetized
|
Dell_RBU driver supports BIOS update using the monolithic image and packetized
|
||||||
image methods. In case of moniolithic the driver allocates a contiguous chunk
|
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
|
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
|
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
|
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.
|
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
|
Most of the Dell systems support a monolithic update where the BIOS image is
|
||||||
copied to a single contiguous block of physical memory.
|
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.
|
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
|
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
|
In packet update mode the packet size has to be given before any packets can
|
||||||
be downloaded. It is done as below
|
be downloaded. It is done as below
|
||||||
echo XXXX > /sys/devices/platform/dell_rbu/packet_size
|
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
|
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
|
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
|
places it next to the packetheader; now, the packetheader + BIOS image chunk
|
||||||
added to geather should match the specified packet_size. This makes one
|
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
|
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
|
image file and then arrange all these packets back to back in to one single
|
||||||
file.
|
file.
|
||||||
|
@ -93,8 +93,8 @@ read back the image downloaded.
|
||||||
NOTE:
|
NOTE:
|
||||||
This driver requires a patch for firmware_class.c which has the modified
|
This driver requires a patch for firmware_class.c which has the modified
|
||||||
request_firmware_nowait function.
|
request_firmware_nowait function.
|
||||||
Also after updating the BIOS image an user mdoe application neeeds to execute
|
Also after updating the BIOS image a user mode application needs to execute
|
||||||
code which message the BIOS update request to the BIOS. So on the next reboot
|
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 it self.
|
the BIOS knows about the new image downloaded and it updates itself.
|
||||||
Also don't unload the rbu drive if the image has to be updated.
|
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 char Advanced Linux Sound Driver (ALSA)
|
||||||
|
|
||||||
116 block MicroMemory battery backed RAM adapter (NVRAM)
|
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.
|
Requested by neilb at cse.unsw.edu.au.
|
||||||
|
|
||||||
0 = /dev/umem/d0 Whole of first board
|
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
|
This major is reserved to assist the expansion to a
|
||||||
larger number space. No device nodes with this major
|
larger number space. No device nodes with this major
|
||||||
should ever be created on the filesystem.
|
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)
|
for now /Torben)
|
||||||
|
|
||||||
---LARGE MAJORS!!!!!---
|
---LARGE MAJORS!!!!!---
|
||||||
|
@ -3205,7 +3205,7 @@ for a session; this includes virtual consoles, serial ports, and
|
||||||
pseudoterminals (PTYs).
|
pseudoterminals (PTYs).
|
||||||
|
|
||||||
All terminal devices share a common set of capabilities known as line
|
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.
|
as SLIP and PPP modes.
|
||||||
|
|
||||||
All terminal devices are named similarly; this section explains the
|
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 (PTYs)
|
||||||
|
|
||||||
Pseudoterminals, or PTYs, are used to create login sessions or provide
|
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
|
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
|
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
|
/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
|
Each device class defines a set of semantics and a programming interface
|
||||||
that devices of that class adhere to. Device drivers are the
|
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.
|
a particular bus.
|
||||||
|
|
||||||
Device classes are agnostic with respect to what bus a device resides
|
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
|
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
|
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);
|
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 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
|
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,
|
driver model generally do not and should not touch the fields of struct device,
|
||||||
unless there is a strong compelling reason to do so.
|
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.
|
by circuitry on the card and is often presented uncompressed.
|
||||||
For a PAL TV signal encoded at a resolution of 768x576 24-bit
|
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
|
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
|
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
|
digital data stream to be presented to the PC in an encoded
|
||||||
and compressed form - similar to the form that is used in
|
and compressed form - similar to the form that is used in
|
||||||
Digital TV.
|
Digital TV.
|
||||||
|
|
|
@ -5,7 +5,7 @@ Hardware supported by the linuxtv.org DVB drivers
|
||||||
frontends (i.e. tuner / demodulator units) used, usually without
|
frontends (i.e. tuner / demodulator units) used, usually without
|
||||||
changing the product name, revision number or specs. Some cards
|
changing the product name, revision number or specs. Some cards
|
||||||
are also available in versions with different frontends for
|
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
|
Note 1: There is no guarantee that every frontend driver works
|
||||||
out of the box with every card, because of different wiring.
|
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,
|
descrambler to function,
|
||||||
eg: $ ca_zap channels.conf "TMC"
|
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.
|
a FTA card.
|
||||||
|
|
||||||
(3) Currently ca_zap, and dst_test, both are meant for demonstration
|
(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
|
With the High Level CI approach any new card with almost any random
|
||||||
architecture can be implemented with this style, the definitions
|
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.
|
eliminating the need for any additional ioctls.
|
||||||
|
|
||||||
The disadvantage is that the driver/hardware has to manage the rest. For
|
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
|
It's not a bug, it's a feature. Because the frontends have
|
||||||
significant power requirements (and hence get very hot), they
|
significant power requirements (and hence get very hot), they
|
||||||
are powered down if they are unused (i.e. if the frontend device
|
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
|
allow you to change the timeout (default 5 seconds). Setting the
|
||||||
timeout to 0 disables the timeout feature.
|
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
|
- 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
|
applications
|
||||||
|
|
||||||
- dvb-core: DVB core module. This provides you with the
|
- 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
|
- video-buf: capture helper module for the saa7146_vv driver. This
|
||||||
one is responsible to handle capture buffers.
|
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
|
DVB-S/C/T cards
|
||||||
|
|
||||||
eof
|
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
|
- The bus code implements most of the generic code. It is shared
|
||||||
among all the architectures that the EISA code runs on. It
|
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
|
allocates I/O resources, allows fancy naming through sysfs, and
|
||||||
offers interfaces for driver to register.
|
offers interfaces for driver to register.
|
||||||
|
|
||||||
|
@ -84,7 +84,7 @@ struct eisa_driver {
|
||||||
|
|
||||||
id_table : an array of NULL terminated EISA id strings,
|
id_table : an array of NULL terminated EISA id strings,
|
||||||
followed by an empty string. Each string can
|
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_data).
|
||||||
|
|
||||||
driver : a generic driver, such as described in
|
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()).
|
function (which has since been replaced by access_ok()).
|
||||||
|
|
||||||
This function verified that the memory area starting at address
|
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
|
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
|
virtual memory area (vma) that contained the address addr. In the
|
||||||
normal case (correctly working program), this test was successful.
|
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
|
unloaded if it is still bound to the console layer. (See
|
||||||
Documentation/console/console.txt for more information).
|
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:
|
because fbcon is an intermediate layer between the console and the drivers:
|
||||||
|
|
||||||
console ---> fbcon ---> fbdev drivers ---> hardware
|
console ---> fbcon ---> fbdev drivers ---> hardware
|
||||||
|
|
|
@ -72,7 +72,7 @@ information. Additionally, "modinfo sisfb" gives an overview over all
|
||||||
supported options including some explanation.
|
supported options including some explanation.
|
||||||
|
|
||||||
The desired display mode can be specified using the keyword "mode" with
|
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
|
- XxYxDepth or
|
||||||
- XxY-Depth or
|
- XxY-Depth or
|
||||||
- XxY-Depth@Rate or
|
- XxY-Depth@Rate or
|
||||||
|
|
|
@ -48,12 +48,12 @@ Module Usage
|
||||||
|
|
||||||
Module insertion:
|
Module insertion:
|
||||||
# insmod sstfb.o
|
# 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
|
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()"...
|
"sstfb_test()"...
|
||||||
(if you don't have a second monitor, you'll have to plug your monitor
|
(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
|
# con2fb /dev/fbx /dev/ttyx
|
||||||
bind a tty to the new frame buffer. if you already have a frame
|
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,
|
buffer driver, the voodoo fb will likely be /dev/fb1. if not,
|
||||||
|
@ -72,12 +72,12 @@ Module Usage
|
||||||
|
|
||||||
Kernel/Modules Options
|
Kernel/Modules Options
|
||||||
|
|
||||||
You can pass some otions to sstfb module, and via the kernel command
|
You can pass some options to the sstfb module, and via the kernel
|
||||||
line when the driver is compiled in :
|
command line when the driver is compiled in:
|
||||||
for module : insmod sstfb.o option1=value1 option2=value2 ...
|
for module : insmod sstfb.o option1=value1 option2=value2 ...
|
||||||
in kernel : video=sstfb:option1,option2:value2,option3 ...
|
in kernel : video=sstfb:option1,option2:value2,option3 ...
|
||||||
|
|
||||||
sstfb supports the folowing options :
|
sstfb supports the following options :
|
||||||
|
|
||||||
Module Kernel Description
|
Module Kernel Description
|
||||||
|
|
||||||
|
@ -95,11 +95,11 @@ inverse=1 inverse Supposed to enable inverse console.
|
||||||
|
|
||||||
clipping=1 clipping Enable or disable clipping.
|
clipping=1 clipping Enable or disable clipping.
|
||||||
clipping=0 noclipping With clipping enabled, all offscreen
|
clipping=0 noclipping With clipping enabled, all offscreen
|
||||||
reads and writes are disgarded.
|
reads and writes are discarded.
|
||||||
Default: enable clipping.
|
Default: enable clipping.
|
||||||
|
|
||||||
gfxclk=x gfxclk:x Force graphic clock frequency (in MHz).
|
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.
|
DANGEROUS.
|
||||||
Default: auto
|
Default: auto
|
||||||
50Mhz for Voodoo 1,
|
50Mhz for Voodoo 1,
|
||||||
|
@ -137,23 +137,23 @@ Bugs
|
||||||
- The driver is 16 bpp only, 24/32 won't work.
|
- The driver is 16 bpp only, 24/32 won't work.
|
||||||
- The driver is not your_favorite_toy-safe. this includes SMP...
|
- The driver is not your_favorite_toy-safe. this includes SMP...
|
||||||
[Actually from inspection it seems to be safe - Alan]
|
[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
|
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
|
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.
|
problem.
|
||||||
- I didn't really test changing the palette, so you may find some weird
|
- I didn't really test changing the palette, so you may find some weird
|
||||||
things when playing with that.
|
things when playing with that.
|
||||||
- Sometimes the driver will not recognise the DAC , and the
|
- Sometimes the driver will not recognise the DAC, and the
|
||||||
initialisation will fail. this is specificaly true for
|
initialisation will fail. This is specifically true for
|
||||||
voodoo 2 boards , but it should be solved in recent versions. please
|
voodoo 2 boards, but it should be solved in recent versions. Please
|
||||||
contact me .
|
contact me.
|
||||||
- the 24/32 is not likely to work anytime soon , knowing that the
|
- The 24/32 is not likely to work anytime soon, knowing that the
|
||||||
hardware does ... unusual thigs in 24/32 bpp
|
hardware does ... unusual things in 24/32 bpp.
|
||||||
- When used with anther video board, current limitations of linux
|
- When used with another video board, current limitations of the linux
|
||||||
console subsystem can cause some troubles, specificaly, you should
|
console subsystem can cause some troubles, specifically, you should
|
||||||
disable software scrollback , as it can oops badly ...
|
disable software scrollback, as it can oops badly ...
|
||||||
|
|
||||||
Todo
|
Todo
|
||||||
|
|
||||||
|
@ -161,7 +161,7 @@ Todo
|
||||||
- Buy more coffee.
|
- Buy more coffee.
|
||||||
- test/port to other arch.
|
- test/port to other arch.
|
||||||
- try to add panning using tweeks with front and back buffer .
|
- 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 ...
|
lot in 2D even if it was sold as a 3D only board ...
|
||||||
|
|
||||||
ghoz.
|
ghoz.
|
||||||
|
|
|
@ -184,7 +184,7 @@ Who: Greg Kroah-Hartman <gregkh@suse.de>
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: USB driver API moves to EXPORT_SYMBOL_GPL
|
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
|
Files: include/linux/usb.h, drivers/usb/core/driver.c
|
||||||
Why: The USB subsystem has changed a lot over time, and it has been
|
Why: The USB subsystem has changed a lot over time, and it has been
|
||||||
possible to create userspace USB drivers using usbfs/libusb/gadgetfs
|
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).
|
- info on the cram filesystem for small storage (ROMs etc).
|
||||||
dentry-locking.txt
|
dentry-locking.txt
|
||||||
- info on the RCU-based dcache locking model.
|
- info on the RCU-based dcache locking model.
|
||||||
devfs/
|
|
||||||
- directory containing devfs documentation.
|
|
||||||
directory-locking
|
directory-locking
|
||||||
- info about the locking scheme used for directory operations.
|
- info about the locking scheme used for directory operations.
|
||||||
dlmfs.txt
|
dlmfs.txt
|
||||||
|
|
|
@ -7,7 +7,7 @@ WARNING
|
||||||
Make sure you understand that this is alpha software. This means that the
|
Make sure you understand that this is alpha software. This means that the
|
||||||
implementation is neither complete nor well-tested.
|
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
|
LICENSE
|
||||||
=====
|
=====
|
||||||
|
@ -22,7 +22,7 @@ He has been working on the code since Aug 13, 2001. See the changelog for
|
||||||
details.
|
details.
|
||||||
|
|
||||||
Original Author: Makoto Kato <m_kato@ga2.so-net.ne.jp>
|
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/>
|
<http://hp.vector.co.jp/authors/VA008030/bfs/>
|
||||||
Does anyone know of a more current email address for Makoto? He doesn't
|
Does anyone know of a more current email address for Makoto? He doesn't
|
||||||
respond to the address given above...
|
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".
|
Be, Inc said, "BeOS Filesystem is officially called BFS, not BeFS".
|
||||||
But Unixware Boot Filesystem is called bfs, too. And they are already in
|
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.
|
filesystem is called befs.
|
||||||
|
|
||||||
HOW TO INSTALL
|
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
|
figure it out yourself (it shouldn't be hard), or mail the maintainer
|
||||||
(Will Dyson <will_dyson@pobox.com>) for help.
|
(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
|
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
|
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>
|
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,
|
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
|
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
|
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
|
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
|
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
|
Far better would be an explicit action notifying the subsystem that the
|
||||||
config_item is ready to go. More importantly, an explicit action allows
|
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
|
initialized in a way that makes sense. configfs provides this as
|
||||||
committable items.
|
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
|
"pending" directory does allow mkdir(2) and rmdir(2). An item is
|
||||||
created in the "pending" directory. Its attributes can be modified at
|
created in the "pending" directory. Its attributes can be modified at
|
||||||
will. Userspace commits the item by renaming it into the "live"
|
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
|
callback. If all required attributes are filled to satisfaction, the
|
||||||
method returns zero and the item is moved to the "live" directory.
|
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
|
Consider the object blocking the cross-directory rename. One
|
||||||
of its descendents is locked by cross-directory rename (otherwise we
|
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
|
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.
|
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
|
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
|
call. Userspace programs are assumed to handle their own local
|
||||||
locking.
|
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.
|
Also supported is a Trylock operation.
|
||||||
|
|
||||||
For information on the libo2dlm interface, please see o2dlm.h,
|
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
|
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
|
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
|
fill up all the space available to them (this is independent of filesystem
|
||||||
quotas). It also keeps the filesystem from filling up entirely which
|
quotas). It also keeps the filesystem from filling up entirely which
|
||||||
helps combat fragmentation.
|
helps combat fragmentation.
|
||||||
|
|
|
@ -55,7 +55,7 @@ the fdtable structure -
|
||||||
2. Reading of the fdtable as described above must be protected
|
2. Reading of the fdtable as described above must be protected
|
||||||
by rcu_read_lock()/rcu_read_unlock().
|
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.
|
be held.
|
||||||
|
|
||||||
4. To look up the file structure given an fd, a reader
|
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
|
- Using NTFS volume and stripe sets
|
||||||
- The Device-Mapper driver
|
- The Device-Mapper driver
|
||||||
- The Software RAID / MD driver
|
- The Software RAID / MD driver
|
||||||
- Limitiations when using the MD driver
|
- Limitations when using the MD driver
|
||||||
- ChangeLog
|
- ChangeLog
|
||||||
|
|
||||||
|
|
||||||
|
@ -43,7 +43,7 @@ There is plenty of additional information on the linux-ntfs web site
|
||||||
at http://linux-ntfs.sourceforge.net/
|
at http://linux-ntfs.sourceforge.net/
|
||||||
|
|
||||||
The web site has a lot of additional information, such as a comprehensive
|
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.
|
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).
|
appropriately (see man 5 raidtab).
|
||||||
|
|
||||||
Linear volume sets, i.e. linear raid, as well as stripe sets, i.e. raid level
|
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).
|
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
|
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.
|
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
|
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
|
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
|
Windows by default uses a stripe chunk size of 64k, so you probably want the
|
||||||
"chunk-size 64k" option for each raid-disk, too.
|
"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.
|
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
|
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.
|
this memory, making it slower to access than lowmem.
|
||||||
LowTotal:
|
LowTotal:
|
||||||
LowFree: Lowmem is memory which can be used for everything that
|
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
|
kernel's use for its own data structures. Among many
|
||||||
other things, it is where everything from the Slab is
|
other things, it is where everything from the Slab is
|
||||||
allocated. Bad things happen when you're out of lowmem.
|
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
|
address space are refused. Used for a typical system. It
|
||||||
ensures a seriously wild allocation fails while allowing
|
ensures a seriously wild allocation fails while allowing
|
||||||
overcommit to reduce swap usage. root is allowed to
|
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.
|
default.
|
||||||
|
|
||||||
1 - Always overcommit. Appropriate for some scientific
|
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
|
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
|
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
|
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
|
tcp_syncookies
|
||||||
--------------
|
--------------
|
||||||
|
@ -1733,7 +1733,7 @@ error_burst and error_cost
|
||||||
|
|
||||||
These parameters are used to limit how many ICMP destination unreachable to
|
These parameters are used to limit how many ICMP destination unreachable to
|
||||||
send from the host in question. ICMP destination unreachable messages are
|
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
|
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
|
our ICMP redirects. The higher the error_cost factor is, the fewer
|
||||||
destination unreachable and error messages will be let through. Error_burst
|
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).
|
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
|
Determines the number of requests to send to the user level ARP daemon. Use 0
|
||||||
|
|
|
@ -84,7 +84,7 @@ FILES
|
||||||
/ibox
|
/ibox
|
||||||
The second SPU to CPU communication mailbox. This file is similar to
|
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
|
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:
|
operations on an open ibox file are:
|
||||||
|
|
||||||
read(2)
|
read(2)
|
||||||
|
@ -105,7 +105,7 @@ FILES
|
||||||
|
|
||||||
|
|
||||||
/wbox
|
/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
|
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
|
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
|
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
|
EFAULT npc is not a valid pointer or status is neither NULL nor a valid
|
||||||
pointer.
|
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.
|
has been updated to the new program counter value if necessary.
|
||||||
|
|
||||||
EINVAL fd is not a file descriptor returned from spu_create(2).
|
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
|
The sysfs directory arrangement exposes the relationship of kernel
|
||||||
data structures.
|
data structures.
|
||||||
|
|
||||||
The top level sysfs diretory looks like:
|
The top level sysfs directory looks like:
|
||||||
|
|
||||||
block/
|
block/
|
||||||
bus/
|
bus/
|
||||||
|
|
|
@ -39,7 +39,7 @@ tmpfs has the following uses:
|
||||||
tmpfs /dev/shm tmpfs defaults 0 0
|
tmpfs /dev/shm tmpfs defaults 0 0
|
||||||
|
|
||||||
Remember to create the directory that you intend to mount tmpfs on
|
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
|
This mount is _not_ needed for SYSV shared memory. The internal
|
||||||
mount is used for that. (In the 2.3 kernel versions it was
|
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_blocks: The same as size, but in blocks of PAGE_CACHE_SIZE.
|
||||||
nr_inodes: The maximum number of inodes for this instance. The default
|
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
|
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.
|
whichever is the lower.
|
||||||
|
|
||||||
These parameters accept a suffix k, m or g for kilo, mega and giga and
|
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.
|
you should consider the following option instead.
|
||||||
|
|
||||||
utf8=<bool> -- UTF-8 is the filesystem safe version of Unicode that
|
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,
|
filesystem with this option. If 'uni_xlate' gets set,
|
||||||
UTF-8 gets disabled.
|
UTF-8 gets disabled.
|
||||||
|
|
||||||
|
|
|
@ -410,7 +410,7 @@ otherwise noted.
|
||||||
|
|
||||||
put_link: called by the VFS to release resources allocated by
|
put_link: called by the VFS to release resources allocated by
|
||||||
follow_link(). The cookie returned by follow_link() is passed
|
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
|
filesystems such as NFS where page cache is not stable
|
||||||
(i.e. page that was installed when the symbolic link walk
|
(i.e. page that was installed when the symbolic link walk
|
||||||
started might not be in the page cache at the end of the
|
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.iamr[]
|
||||||
(*) __debug_mmu.damr[]
|
(*) __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 macro:
|
||||||
|
|
||||||
(gdb) _amr
|
(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.
|
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
|
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)
|
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
|
features into the existing timer framework, and after testing various
|
||||||
such high-resolution timer implementations in practice, we came to the
|
such high-resolution timer implementations in practice, we came to the
|
||||||
conclusion that the timer wheel code is fundamentally not suitable for
|
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
|
to solve this'), and spent a considerable effort trying to integrate
|
||||||
things into the timer wheel, but we failed. In hindsight, there are
|
things into the timer wheel, but we failed. In hindsight, there are
|
||||||
several reasons why such integration is hard/impossible:
|
several reasons why such integration is hard/impossible:
|
||||||
|
@ -27,7 +27,7 @@ several reasons why such integration is hard/impossible:
|
||||||
high-res timers.
|
high-res timers.
|
||||||
|
|
||||||
- the unpredictable [O(N)] overhead of cascading leads to delays which
|
- 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
|
in turn decreases robustness. Such a design still led to rather large
|
||||||
timing inaccuracies. Cascading is a fundamental property of the timer
|
timing inaccuracies. Cascading is a fundamental property of the timer
|
||||||
wheel concept, it cannot be 'designed out' without unevitably
|
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
|
The primary users of precision timers are user-space applications that
|
||||||
utilize nanosleep, posix-timers and itimer interfaces. Also, in-kernel
|
utilize nanosleep, posix-timers and itimer interfaces. Also, in-kernel
|
||||||
users like drivers and subsystems which require precise timed events
|
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.
|
high-resolution timer subsystem as well.
|
||||||
|
|
||||||
While this subsystem does not offer high-resolution clock sources just
|
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
|
with other potential users for precise timers gives another reason to
|
||||||
separate the "timeout" and "precise timer" subsystems.
|
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
|
special-purpose optimization of the existing timer wheel for the low
|
||||||
resolution and low precision use cases - once the precision-sensitive
|
resolution and low precision use cases - once the precision-sensitive
|
||||||
APIs are separated from the timer wheel and are migrated over to
|
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
|
a separate list is used to give the expiry code fast access to the
|
||||||
queued timers, without having to walk the rbtree.
|
queued timers, without having to walk the rbtree.
|
||||||
|
|
||||||
(This seperate list is also useful for later when we'll introduce
|
(This separate list is also useful for later when we'll introduce
|
||||||
high-resolution clocks, where we need seperate pending and expired
|
high-resolution clocks, where we need separate pending and expired
|
||||||
queues while keeping the time-order intact.)
|
queues while keeping the time-order intact.)
|
||||||
|
|
||||||
Time-ordered enqueueing is not purely for the purposes of
|
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
|
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
|
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
|
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
|
new ioctl()s have been introduced for things that EFI provides but not the
|
||||||
legacy.
|
legacy.
|
||||||
|
|
||||||
|
|
|
@ -165,7 +165,7 @@ complicated cases.
|
||||||
* Signal handling
|
* Signal handling
|
||||||
|
|
||||||
The delivery of (asynchronous) signals must be delayed until fsys-mode
|
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()
|
transfer trap: arch/ia64/kernel/process.c:do_notify_resume_user()
|
||||||
checks whether the interrupted task was in fsys-mode and, if so, sets
|
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
|
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
|
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.
|
if we have a choice here.
|
||||||
|
|
||||||
* MCA occurs on one cpu, usually due to a double bit memory error.
|
* 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
|
INIT is less complicated than MCA. Pressing the nmi button or using
|
||||||
the equivalent command on the management console sends INIT to all
|
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
|
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
|
time. The OS monarch prints the state of all tasks and returns, after
|
||||||
which the slaves return and the system resumes.
|
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.
|
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
|
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
|
"idex=serialize" : do not overlap operations on idex. Please note
|
||||||
that you will have to specify this option for
|
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.
|
to take effect.
|
||||||
|
|
||||||
"idex=four" : four drives on idex and ide(x^1) share same ports
|
"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
|
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.
|
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
|
addresses is shown below. Each 6 bit counter (Y7-Y2,X7-X2) is
|
||||||
clocked by 2 of the signals input from the mouse serial
|
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 |
|
| 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
|
The ikbd processor also maintains a time-of-day clock with one second
|
||||||
resolution.
|
resolution.
|
||||||
The ikbd has been designed to be general enough that it can be used with a
|
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.
|
keyswitches, mouse resolution, etc. can be accommodated.
|
||||||
The ikbd communicates with the main processor over a high speed bi-directional
|
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
|
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:
|
The special codes 0xF6 through 0xFF are reserved for use as follows:
|
||||||
0xF6 status report
|
0xF6 status report
|
||||||
0xF7 absolute mouse position record
|
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)
|
mouse button states)
|
||||||
0xFC time-of-day
|
0xFC time-of-day
|
||||||
0xFD joystick report (both sticks)
|
0xFD joystick report (both sticks)
|
||||||
|
@ -84,7 +84,7 @@ selected.
|
||||||
4.2 Absolute Position reporting
|
4.2 Absolute Position reporting
|
||||||
|
|
||||||
The ikbd can also maintain absolute mouse position. Commands exist for
|
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.
|
current mouse position.
|
||||||
|
|
||||||
4.3 Mouse Cursor Key Mode
|
4.3 Mouse Cursor Key Mode
|
||||||
|
@ -406,7 +406,7 @@ INTERROGATION MODE.
|
||||||
9.18 SET JOYSTICK MONITORING
|
9.18 SET JOYSTICK MONITORING
|
||||||
|
|
||||||
0x17
|
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)
|
Returns: (in packets of two as long as in mode)
|
||||||
%000000xy ; where y is JOYSTICK1 Fire button
|
%000000xy ; where y is JOYSTICK1 Fire button
|
||||||
; and x is JOYSTICK0 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
|
0x20 ; memory access
|
||||||
{ data } ; 6 data bytes starting at ADR
|
{ 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
|
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 or PnP ISA cards supported. AFAIK the ns558 have support for Crystal
|
||||||
ISA and PnP ISA series.
|
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.
|
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
|
There are no sound or input collisions detected. The source code have
|
||||||
comments about them; but I've found the joystick can be initialized
|
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.
|
There is an utility called fftest that will allow you to test the driver.
|
||||||
% fftest /dev/input/eventXX
|
% 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()
|
All interactions are done using the event API. That is, you can use ioctl()
|
||||||
and write() on /dev/input/eventXX.
|
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.
|
gameport generic code will take care of the rest.
|
||||||
|
|
||||||
If your hardware supports more than one io address, and your driver can
|
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
|
choose which one to program the hardware to, starting from the more exotic
|
||||||
addresses is preferred, because the likelyhood of clashing with the standard
|
addresses is preferred, because the likelihood of clashing with the standard
|
||||||
0x201 address is smaller.
|
0x201 address is smaller.
|
||||||
|
|
||||||
Eg. if your driver supports addresses 0x200, 0x208, 0x210 and 0x218, then
|
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
|
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
|
This device has to be created.
|
||||||
created automatically. The commands to do create it by hand are:
|
The commands to create it by hand are:
|
||||||
|
|
||||||
cd /dev
|
cd /dev
|
||||||
mkdir input
|
mkdir input
|
||||||
|
@ -154,7 +154,7 @@ about it.
|
||||||
|
|
||||||
3.2 Event handlers
|
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.
|
kernel, as needed.
|
||||||
|
|
||||||
3.2.1 keybdev
|
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
|
API is still evolving, but should be useable now. It's described in
|
||||||
section 5.
|
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
|
events. It allows for multihead in X without any specific multihead
|
||||||
kernel support. The event codes are the same on all architectures and
|
kernel support. The event codes are the same on all architectures and
|
||||||
are hardware independent.
|
are hardware independent.
|
||||||
|
@ -279,7 +279,7 @@ struct input_event {
|
||||||
};
|
};
|
||||||
|
|
||||||
'time' is the timestamp, it returns the time at which the event happened.
|
'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.
|
release. More types are defined in include/linux/input.h.
|
||||||
|
|
||||||
'code' is event code, for example REL_X or KEY_BACKSPACE, again a complete
|
'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
|
EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for
|
||||||
release, 1 for keypress and 2 for autorepeat.
|
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
|
8 | Sony PSX DDR controller
|
||||||
9 | SNES mouse
|
9 | SNES mouse
|
||||||
|
|
||||||
The exact type of the PSX controller type is autoprobed when used so
|
The exact type of the PSX controller type is autoprobed when used, so
|
||||||
hot swapping should work (but is not recomended).
|
hot swapping should work (but is not recommended).
|
||||||
|
|
||||||
Should you want to use more than one of parallel ports at once, you can use
|
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
|
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
|
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
|
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
|
work but you can try lowering it for better performance. If your pads don't
|
||||||
respond try raising it untill they work. Setting the type to 8 allows the
|
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
|
driver to be used with Dance Dance Revolution or similar games. Arrow keys are
|
||||||
registered as key presses instead of X and Y axes.
|
registered as key presses instead of X and Y axes.
|
||||||
|
|
||||||
|
|
|
@ -60,7 +60,7 @@ and install it before going on.
|
||||||
|
|
||||||
2.2 Device nodes
|
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:
|
you'll have to manually create these nodes in /dev:
|
||||||
|
|
||||||
cd /dev
|
cd /dev
|
||||||
|
|
|
@ -87,13 +87,13 @@ Line 3 Format : 888888888888
|
||||||
|
|
||||||
|
|
||||||
Format description:
|
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.
|
A digit can have a character set, an icon can only be ON or OFF.
|
||||||
|
|
||||||
Format specifier
|
Format specifier
|
||||||
'8' : Generic 7 segment digit with individual addressable segments
|
'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.
|
'1' : 2 segments digit only able to produce a 1.
|
||||||
'e' : Most significant day of the month digit,
|
'e' : Most significant day of the month digit,
|
||||||
able to produce at least 1 2 3.
|
able to produce at least 1 2 3.
|
||||||
|
|
|
@ -203,7 +203,7 @@ HDIO_SET_MULTCOUNT change IDE blockmode
|
||||||
|
|
||||||
Source code comments read:
|
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
|
touch. DON'T do it again until a total personality rewrite
|
||||||
is committed.
|
is committed.
|
||||||
|
|
||||||
|
|
|
@ -26,7 +26,7 @@ Structure T30_s description:
|
||||||
If the HL-driver receives ISDN_CMD_FAXCMD, all needed information
|
If the HL-driver receives ISDN_CMD_FAXCMD, all needed information
|
||||||
is in this struct set by the LL.
|
is in this struct set by the LL.
|
||||||
To signal information to the LL, the HL-driver has to set the
|
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)
|
(Please refer to INTERFACE)
|
||||||
|
|
||||||
Structure T30_s:
|
Structure T30_s:
|
||||||
|
|
|
@ -1,6 +1,6 @@
|
||||||
$Id: README.hysdn,v 1.3.6.1 2001/02/10 14:41:19 kai Exp $
|
$Id: README.hysdn,v 1.3.6.1 2001/02/10 14:41:19 kai Exp $
|
||||||
The hysdn driver has been written by
|
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
|
for Hypercope GmbH Aachen Germany. Hypercope agreed to publish this driver
|
||||||
under the GNU General Public License.
|
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.
|
the kernel (CONFIG_BINFMT_MISC) and set it up properly.
|
||||||
If you choose to compile it as a module, you will have
|
If you choose to compile it as a module, you will have
|
||||||
to insert it manually with modprobe/insmod, as kmod
|
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
|
Read the file 'binfmt_misc.txt' in this directory to know
|
||||||
more about the configuration process.
|
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
|
the indentation level, this means it ends at the first line which has
|
||||||
a smaller indentation than the first line of the help text.
|
a smaller indentation than the first line of the help text.
|
||||||
"---help---" and "help" do not differ in behaviour, "---help---" is
|
"---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.
|
the file as an aid to developers.
|
||||||
|
|
||||||
|
|
||||||
|
@ -226,7 +226,7 @@ menuconfig:
|
||||||
"menuconfig" <symbol>
|
"menuconfig" <symbol>
|
||||||
<config options>
|
<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
|
hint to front ends, that all suboptions should be displayed as a
|
||||||
separate list of options.
|
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,
|
is called inside interrupt context or die() is called and panic_on_oops is set,
|
||||||
the system will boot into the dump-capture kernel.
|
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",
|
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.
|
"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
|
Description: Very nice 92 pages GPL book on the topic of modules
|
||||||
programming. Lots of examples.
|
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"
|
* Title: "I/O Event Handling Under Linux"
|
||||||
Author: Richard Gooch.
|
Author: Richard Gooch.
|
||||||
URL: http://www.atnf.csiro.au/~rgooch/linux/docs/io-events.html
|
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.
|
clock= [BUGS=IA-32, HW] gettimeofday clocksource override.
|
||||||
[Deprecated]
|
[Deprecated]
|
||||||
Forces specified clocksource (if avaliable) to be used
|
Forces specified clocksource (if available) to be used
|
||||||
when calculating gettimeofday(). If specified
|
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 }
|
Format: { pit | tsc | cyclone | pmtmr }
|
||||||
|
|
||||||
disable_8254_timer
|
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
|
noirqbalance [IA-32,SMP,KNL] Disable kernel irq balancing
|
||||||
|
|
||||||
i8042.direct [HW] Put keyboard port into non-translated mode
|
i8042.direct [HW] Put keyboard port into non-translated mode
|
||||||
i8042.dumbkbd [HW] Pretend that controlled can only read data from
|
i8042.dumbkbd [HW] Pretend that controller can only read data from
|
||||||
keyboard and can not control its state
|
keyboard and cannot control its state
|
||||||
(Don't attempt to blink the leds)
|
(Don't attempt to blink the leds)
|
||||||
i8042.noaux [HW] Don't check for auxiliary (== mouse) port
|
i8042.noaux [HW] Don't check for auxiliary (== mouse) port
|
||||||
i8042.nokbd [HW] Don't check/create keyboard 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
|
reboot= [BUGS=IA-32,BUGS=ARM,BUGS=IA-64] Rebooting mode
|
||||||
Format: <reboot_mode>[,<reboot_mode2>[,...]]
|
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
|
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.
|
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
|
the process keyring if there is one, otherwise the session keyring if
|
||||||
there is one, otherwise the user default session keyring.
|
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.
|
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
|
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.
|
be broken down into two areas: keys and key types.
|
||||||
|
|
||||||
Dealing with keys is fairly straightforward. Firstly, the kernel service
|
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
|
almost all complex data types share. kobjects are intended to be
|
||||||
embedded in larger data structures and replace fields they duplicate.
|
embedded in larger data structures and replace fields they duplicate.
|
||||||
|
|
||||||
1.2 Defintion
|
1.2 Definition
|
||||||
|
|
||||||
struct kobject {
|
struct kobject {
|
||||||
char name[KOBJ_NAME_LEN];
|
char name[KOBJ_NAME_LEN];
|
||||||
|
|
|
@ -152,7 +152,7 @@ loaded on demand while the application executes) and sequentially accessed data
|
||||||
DO_REMOUNTS:
|
DO_REMOUNTS:
|
||||||
|
|
||||||
The control script automatically remounts any mounted journaled filesystems
|
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.
|
feature is disabled.
|
||||||
|
|
||||||
DO_REMOUNT_NOATIME:
|
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
|
(defined by the properties of the hierarchy), and the kernel grabs the
|
||||||
locks in this fixed order on each of the objects.
|
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
|
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
|
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
|
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
|
In this case the locking is done on a bdev object that is known to be a
|
||||||
partition.
|
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.
|
separate (sub)class for the purposes of validation.
|
||||||
|
|
||||||
Note: When changing code to use the _nested() primitives, be careful and
|
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.
|
you can get false positives or false negatives.
|
||||||
|
|
||||||
Proof of 100% correctness:
|
Proof of 100% correctness:
|
||||||
|
@ -170,7 +170,7 @@ Proof of 100% correctness:
|
||||||
|
|
||||||
The validator achieves perfect, mathematical 'closure' (proof of locking
|
The validator achieves perfect, mathematical 'closure' (proof of locking
|
||||||
correctness) in the sense that for every simple, standalone single-task
|
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
|
kernel, the validator proves it with a 100% certainty that no
|
||||||
combination and timing of these locking sequences can cause any class of
|
combination and timing of these locking sequences can cause any class of
|
||||||
lock related deadlock. [*]
|
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>,
|
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
|
<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
|
of colors possible. (Or, the other way round: The number of colors is
|
||||||
2^depth).
|
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
|
with clones that have a different adapter id than the original
|
||||||
NE/2.
|
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)
|
Reply Sound Blaster/SCSI (SCSI part)
|
||||||
Better support for these cards than the driver for ISA.
|
Better support for these cards than the driver for ISA.
|
||||||
Supports multiple cards with IRQ sharing.
|
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
|
For this reason, md will normally refuse to start such an array. This
|
||||||
requires the sysadmin to take action to explicitly start the array
|
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 ....
|
mdadm --assemble --force ....
|
||||||
|
|
||||||
This option is not really available if the array has the root
|
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
|
raid levels that involve striping (1,4,5,6,10). The address space
|
||||||
of the array is conceptually divided into chunks and consecutive
|
of the array is conceptually divided into chunks and consecutive
|
||||||
chunks are striped onto neighbouring devices.
|
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
|
of 2. This can only be set while assembling an array
|
||||||
|
|
||||||
component_size
|
component_size
|
||||||
|
@ -214,8 +214,8 @@ All md devices contain:
|
||||||
safe_mode_delay
|
safe_mode_delay
|
||||||
When an md array has seen no write requests for a certain period
|
When an md array has seen no write requests for a certain period
|
||||||
of time, it will be marked as 'clean'. When another write
|
of time, it will be marked as 'clean'. When another write
|
||||||
request arrive, the array is marked as 'dirty' before the write
|
request arrives, the array is marked as 'dirty' before the write
|
||||||
commenses. This is known as 'safe_mode'.
|
commences. This is known as 'safe_mode'.
|
||||||
The 'certain period' is controlled by this file which stores the
|
The 'certain period' is controlled by this file which stores the
|
||||||
period as a number of seconds. The default is 200msec (0.200).
|
period as a number of seconds. The default is 200msec (0.200).
|
||||||
Writing a value of 0 disables safemode.
|
Writing a value of 0 disables safemode.
|
||||||
|
@ -307,8 +307,8 @@ Each directory contains:
|
||||||
This applies only to raid1 arrays.
|
This applies only to raid1 arrays.
|
||||||
spare - device is working, but not a full member.
|
spare - device is working, but not a full member.
|
||||||
This includes spares that are in the process
|
This includes spares that are in the process
|
||||||
of being recoverred to
|
of being recovered to
|
||||||
This list make grow in future.
|
This list may grow in future.
|
||||||
This can be written to.
|
This can be written to.
|
||||||
Writing "faulty" simulates a failure on the device.
|
Writing "faulty" simulates a failure on the device.
|
||||||
Writing "remove" removes the device from the array.
|
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
|
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
|
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
|
(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
|
it currently fills. This can only be set while assembling an
|
||||||
array. A device for which this is set is assumed to be working.
|
array. A device for which this is set is assumed to be working.
|
||||||
|
|
||||||
|
@ -353,7 +353,7 @@ in the array. These are named
|
||||||
|
|
||||||
rdNN
|
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.
|
So for a 3 drive array there will be rd0, rd1, rd2.
|
||||||
These are symbolic links to the appropriate 'dev-XXX' entry.
|
These are symbolic links to the appropriate 'dev-XXX' entry.
|
||||||
Thus, for example,
|
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
|
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
|
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:
|
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.
|
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
|
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.
|
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.
|
the kernel (CONFIG_BINFMT_MISC) and set it up properly.
|
||||||
If you choose to compile it as a module, you will have
|
If you choose to compile it as a module, you will have
|
||||||
to insert it manually with modprobe/insmod, as kmod
|
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
|
Read the file 'binfmt_misc.txt' in this directory to know
|
||||||
more about the configuration process.
|
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:
|
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
|
- 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.
|
- some other device or device driver hogging the bus or disabling interrupts.
|
||||||
Check /proc/interrupts for excessive interrupt counts. The timer tick
|
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
|
packets out of the rx ring. Note from this that the lower the
|
||||||
load the more we could clean up the rxring
|
load the more we could clean up the rxring
|
||||||
"Ndone" == is the converse of "Done". Note again, that the higher
|
"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:
|
Observe that:
|
||||||
when the NIC receives 890Kpackets/sec only 17 rx interrupts are generated.
|
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.
|
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.
|
implied by such a connection is too high for the net to operate reliably.
|
||||||
|
|
||||||
An example of a typical ARCnet network:
|
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
|
files located in /sys/class/net/<bond name>/bonding
|
||||||
|
|
||||||
The names of these files correspond directly with the command-
|
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
|
exception of arp_ip_target, they accept the same values. To see the
|
||||||
current setting, simply cat the appropriate file.
|
current setting, simply cat the appropriate file.
|
||||||
|
|
||||||
|
|
|
@ -227,7 +227,7 @@ configuration options are available on the command line:
|
||||||
* media=rj45 - specify media type
|
* media=rj45 - specify media type
|
||||||
or media=bnc
|
or media=bnc
|
||||||
or media=aui
|
or media=aui
|
||||||
or medai=auto
|
or media=auto
|
||||||
* duplex=full - specify forced half/full/autonegotiate duplex
|
* duplex=full - specify forced half/full/autonegotiate duplex
|
||||||
or duplex=half
|
or duplex=half
|
||||||
or duplex=auto
|
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).
|
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.
|
not found" error message.
|
||||||
|
|
||||||
3.) You cannot connect to the network or the driver will not load.
|
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.
|
software-update notification.
|
||||||
|
|
||||||
Cirrus Logic maintains a web page at http://www.cirrus.com with the
|
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
|
6.4 Current maintainer
|
||||||
|
|
|
@ -56,7 +56,7 @@ FEATURES
|
||||||
|
|
||||||
ethtool -C eth0 rx-usecs 100
|
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>
|
ethtool -C <interface> adaptive-rx off rx-usecs <microseconds>
|
||||||
|
|
||||||
|
@ -172,7 +172,7 @@ PERFORMANCE
|
||||||
smaller window prevents congestion and facilitates better pacing,
|
smaller window prevents congestion and facilitates better pacing,
|
||||||
especially if/when MAC level flow control does not work well or when it is
|
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
|
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.
|
correct receive buffer size.
|
||||||
Setting the min, max, and default receive buffer (RX_WINDOW) size is
|
Setting the min, max, and default receive buffer (RX_WINDOW) size is
|
||||||
performed in the same manner as single connection.
|
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
|
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
|
/proc/net/decnet_dev). There is a utility available at the above
|
||||||
FTP sites called dn2ethaddr which can compute the correct ethernet
|
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
|
at the time the device is brought up. If you are using RedHat you can
|
||||||
add the line:
|
add the line:
|
||||||
|
|
||||||
|
|
|
@ -173,7 +173,7 @@ Installing the Driver
|
||||||
|
|
||||||
Parameter Description
|
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
|
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
|
parameter. Below is a list of the command line parameters supported by the
|
||||||
Linux device
|
Linux device
|
||||||
|
@ -222,7 +222,7 @@ rx_timeout=n - Rx DMA wait time for an interrupt.
|
||||||
reach timeout of n * 640 nano seconds.
|
reach timeout of n * 640 nano seconds.
|
||||||
Set proper rx_coalesce and rx_timeout can
|
Set proper rx_coalesce and rx_timeout can
|
||||||
reduce congestion collapse and overload which
|
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.
|
For example, rx_coalesce=10 rx_timeout=800.
|
||||||
that is, hardware assert only 1 interrupt
|
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
|
ifconfig eth0 172.22.3.18
|
||||||
^^^^^^^^^^^
|
^^^^^^^^^^^
|
||||||
Your IP Adress
|
Your IP Address
|
||||||
|
|
||||||
Then you may have to modify the default routing table with command :
|
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) &&
|
if (netif_queue_stopped(dp->dev) &&
|
||||||
TX_BUFFS_AVAIL(dp) > (MAX_SKB_FRAGS + 1))
|
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
|
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
|
(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 eth0 e1000
|
||||||
alias eth1 e1000
|
alias eth1 e1000
|
||||||
|
|
|
@ -79,7 +79,7 @@ trie_rebalance()
|
||||||
|
|
||||||
resize()
|
resize()
|
||||||
Analyzes a tnode and optimizes the child array size by either inflating
|
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
|
level compression. This part follows the original paper pretty closely
|
||||||
and there may be some room for experimentation here.
|
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
|
0) Prepare an estimator attribute. Most likely this would be in user
|
||||||
space. The value of this TLV should contain a tc_estimator structure.
|
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
|
As usual, such a TLV needs to be 32 bit aligned and therefore the
|
||||||
length needs to be appropriately set etc. The estimator interval
|
length needs to be appropriately set, etc. The estimator interval
|
||||||
and ewma log need to be converted to the appropriate values.
|
and ewma log need to be converted to the appropriate values.
|
||||||
tc_estimator.c::tc_setup_estimator() is advisable to be used as the
|
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
|
conversion routine. It does a few clever things. It takes a time
|
||||||
|
@ -103,8 +103,8 @@ In the kernel when setting up:
|
||||||
else
|
else
|
||||||
failed
|
failed
|
||||||
|
|
||||||
From now on, everytime you dump my_rate_est_stats it will contain
|
From now on, every time you dump my_rate_est_stats it will contain
|
||||||
uptodate info.
|
up-to-date info.
|
||||||
|
|
||||||
Once you are done, call gen_kill_estimator(my_basicstats,
|
Once you are done, call gen_kill_estimator(my_basicstats,
|
||||||
my_rate_est_stats) Make sure that my_basicstats and my_rate_est_stats
|
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,
|
Note that if no primary address exists for the interface selected,
|
||||||
then the primary address of the first non-loopback interface that
|
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
|
Default: 0
|
||||||
|
|
||||||
|
@ -787,7 +787,7 @@ accept_ra_defrtr - BOOLEAN
|
||||||
disabled if accept_ra is disabled.
|
disabled if accept_ra is disabled.
|
||||||
|
|
||||||
accept_ra_pinfo - BOOLEAN
|
accept_ra_pinfo - BOOLEAN
|
||||||
Learn Prefix Inforamtion in Router Advertisement.
|
Learn Prefix Information in Router Advertisement.
|
||||||
|
|
||||||
Functional default: enabled if accept_ra is enabled.
|
Functional default: enabled if accept_ra is enabled.
|
||||||
disabled if accept_ra is disabled.
|
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 a new issue