提交 bd45ac0c 编写于 作者: P Paul Mackerras

Merge branch 'linux-2.6'

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
...@@ -17,6 +17,7 @@ ...@@ -17,6 +17,7 @@
*.i *.i
*.lst *.lst
*.symtypes *.symtypes
*.order
# #
# Top-level generic files # Top-level generic files
......
...@@ -1353,6 +1353,14 @@ S: Gen Stedmanstraat 212 ...@@ -1353,6 +1353,14 @@ S: Gen Stedmanstraat 212
S: 5623 HZ Eindhoven S: 5623 HZ Eindhoven
S: The Netherlands S: The Netherlands
N: Oliver Hartkopp
E: oliver.hartkopp@volkswagen.de
W: http://www.volkswagen.de
D: Controller Area Network (network layer core)
S: Brieffach 1776
S: 38436 Wolfsburg
S: Germany
N: Andrew Haylett N: Andrew Haylett
E: ajh@primag.co.uk E: ajh@primag.co.uk
D: Selection mechanism D: Selection mechanism
...@@ -3306,6 +3314,14 @@ S: Universit=E9 de Rennes I ...@@ -3306,6 +3314,14 @@ S: Universit=E9 de Rennes I
S: F-35042 Rennes Cedex S: F-35042 Rennes Cedex
S: France S: France
N: Urs Thuermann
E: urs.thuermann@volkswagen.de
W: http://www.volkswagen.de
D: Controller Area Network (network layer core)
S: Brieffach 1776
S: 38436 Wolfsburg
S: Germany
N: Jon Tombs N: Jon Tombs
E: jon@gte.esi.us.es E: jon@gte.esi.us.es
W: http://www.esi.us.es/~jon W: http://www.esi.us.es/~jon
......
...@@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ ...@@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
procfs-guide.xml writing_usb_driver.xml \ procfs-guide.xml writing_usb_driver.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml s390-drivers.xml uio-howto.xml genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml
### ###
# The build process is as follows (targets): # The build process is as follows (targets):
......
...@@ -419,7 +419,13 @@ X!Edrivers/pnp/system.c ...@@ -419,7 +419,13 @@ X!Edrivers/pnp/system.c
<chapter id="blkdev"> <chapter id="blkdev">
<title>Block Devices</title> <title>Block Devices</title>
!Eblock/ll_rw_blk.c !Eblock/blk-core.c
!Eblock/blk-map.c
!Iblock/blk-sysfs.c
!Eblock/blk-settings.c
!Eblock/blk-exec.c
!Eblock/blk-barrier.c
!Eblock/blk-tag.c
</chapter> </chapter>
<chapter id="chrdev"> <chapter id="chrdev">
......
...@@ -116,6 +116,7 @@ ...@@ -116,6 +116,7 @@
!Iinclude/asm-s390/ccwdev.h !Iinclude/asm-s390/ccwdev.h
!Edrivers/s390/cio/device.c !Edrivers/s390/cio/device.c
!Edrivers/s390/cio/device_ops.c !Edrivers/s390/cio/device_ops.c
!Edrivers/s390/cio/airq.c
</sect1> </sect1>
<sect1 id="cmf"> <sect1 id="cmf">
<title>The channel-measurement facility</title> <title>The channel-measurement facility</title>
......
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="scsimid">
<bookinfo>
<title>SCSI Interfaces Guide</title>
<authorgroup>
<author>
<firstname>James</firstname>
<surname>Bottomley</surname>
<affiliation>
<address>
<email>James.Bottomley@steeleye.com</email>
</address>
</affiliation>
</author>
<author>
<firstname>Rob</firstname>
<surname>Landley</surname>
<affiliation>
<address>
<email>rob@landley.net</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2007</year>
<holder>Linux Foundation</holder>
</copyright>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License version 2.
</para>
<para>
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
</bookinfo>
<toc></toc>
<chapter id="intro">
<title>Introduction</title>
<sect1 id="protocol_vs_bus">
<title>Protocol vs bus</title>
<para>
Once upon a time, the Small Computer Systems Interface defined both
a parallel I/O bus and a data protocol to connect a wide variety of
peripherals (disk drives, tape drives, modems, printers, scanners,
optical drives, test equipment, and medical devices) to a host
computer.
</para>
<para>
Although the old parallel (fast/wide/ultra) SCSI bus has largely
fallen out of use, the SCSI command set is more widely used than ever
to communicate with devices over a number of different busses.
</para>
<para>
The <ulink url='http://www.t10.org/scsi-3.htm'>SCSI protocol</ulink>
is a big-endian peer-to-peer packet based protocol. SCSI commands
are 6, 10, 12, or 16 bytes long, often followed by an associated data
payload.
</para>
<para>
SCSI commands can be transported over just about any kind of bus, and
are the default protocol for storage devices attached to USB, SATA,
SAS, Fibre Channel, FireWire, and ATAPI devices. SCSI packets are
also commonly exchanged over Infiniband,
<ulink url='http://i2o.shadowconnect.com/faq.php'>I20</ulink>, TCP/IP
(<ulink url='http://en.wikipedia.org/wiki/ISCSI'>iSCSI</ulink>), even
<ulink url='http://cyberelk.net/tim/parport/parscsi.html'>Parallel
ports</ulink>.
</para>
</sect1>
<sect1 id="subsystem_design">
<title>Design of the Linux SCSI subsystem</title>
<para>
The SCSI subsystem uses a three layer design, with upper, mid, and low
layers. Every operation involving the SCSI subsystem (such as reading
a sector from a disk) uses one driver at each of the 3 levels: one
upper layer driver, one lower layer driver, and the SCSI midlayer.
</para>
<para>
The SCSI upper layer provides the interface between userspace and the
kernel, in the form of block and char device nodes for I/O and
ioctl(). The SCSI lower layer contains drivers for specific hardware
devices.
</para>
<para>
In between is the SCSI mid-layer, analogous to a network routing
layer such as the IPv4 stack. The SCSI mid-layer routes a packet
based data protocol between the upper layer's /dev nodes and the
corresponding devices in the lower layer. It manages command queues,
provides error handling and power management functions, and responds
to ioctl() requests.
</para>
</sect1>
</chapter>
<chapter id="upper_layer">
<title>SCSI upper layer</title>
<para>
The upper layer supports the user-kernel interface by providing
device nodes.
</para>
<sect1 id="sd">
<title>sd (SCSI Disk)</title>
<para>sd (sd_mod.o)</para>
<!-- !Idrivers/scsi/sd.c -->
</sect1>
<sect1 id="sr">
<title>sr (SCSI CD-ROM)</title>
<para>sr (sr_mod.o)</para>
</sect1>
<sect1 id="st">
<title>st (SCSI Tape)</title>
<para>st (st.o)</para>
</sect1>
<sect1 id="sg">
<title>sg (SCSI Generic)</title>
<para>sg (sg.o)</para>
</sect1>
<sect1 id="ch">
<title>ch (SCSI Media Changer)</title>
<para>ch (ch.c)</para>
</sect1>
</chapter>
<chapter id="mid_layer">
<title>SCSI mid layer</title>
<sect1 id="midlayer_implementation">
<title>SCSI midlayer implementation</title>
<sect2 id="scsi_device.h">
<title>include/scsi/scsi_device.h</title>
<para>
</para>
!Iinclude/scsi/scsi_device.h
</sect2>
<sect2 id="scsi.c">
<title>drivers/scsi/scsi.c</title>
<para>Main file for the SCSI midlayer.</para>
!Edrivers/scsi/scsi.c
</sect2>
<sect2 id="scsicam.c">
<title>drivers/scsi/scsicam.c</title>
<para>
<ulink url='http://www.t10.org/ftp/t10/drafts/cam/cam-r12b.pdf'>SCSI
Common Access Method</ulink> support functions, for use with
HDIO_GETGEO, etc.
</para>
!Edrivers/scsi/scsicam.c
</sect2>
<sect2 id="scsi_error.c">
<title>drivers/scsi/scsi_error.c</title>
<para>Common SCSI error/timeout handling routines.</para>
!Edrivers/scsi/scsi_error.c
</sect2>
<sect2 id="scsi_devinfo.c">
<title>drivers/scsi/scsi_devinfo.c</title>
<para>
Manage scsi_dev_info_list, which tracks blacklisted and whitelisted
devices.
</para>
!Idrivers/scsi/scsi_devinfo.c
</sect2>
<sect2 id="scsi_ioctl.c">
<title>drivers/scsi/scsi_ioctl.c</title>
<para>
Handle ioctl() calls for SCSI devices.
</para>
!Edrivers/scsi/scsi_ioctl.c
</sect2>
<sect2 id="scsi_lib.c">
<title>drivers/scsi/scsi_lib.c</title>
<para>
SCSI queuing library.
</para>
!Edrivers/scsi/scsi_lib.c
</sect2>
<sect2 id="scsi_lib_dma.c">
<title>drivers/scsi/scsi_lib_dma.c</title>
<para>
SCSI library functions depending on DMA
(map and unmap scatter-gather lists).
</para>
!Edrivers/scsi/scsi_lib_dma.c
</sect2>
<sect2 id="scsi_module.c">
<title>drivers/scsi/scsi_module.c</title>
<para>
The file drivers/scsi/scsi_module.c contains legacy support for
old-style host templates. It should never be used by any new driver.
</para>
</sect2>
<sect2 id="scsi_proc.c">
<title>drivers/scsi/scsi_proc.c</title>
<para>
The functions in this file provide an interface between
the PROC file system and the SCSI device drivers
It is mainly used for debugging, statistics and to pass
information directly to the lowlevel driver.
I.E. plumbing to manage /proc/scsi/*
</para>
!Idrivers/scsi/scsi_proc.c
</sect2>
<sect2 id="scsi_netlink.c">
<title>drivers/scsi/scsi_netlink.c</title>
<para>
Infrastructure to provide async events from transports to userspace
via netlink, using a single NETLINK_SCSITRANSPORT protocol for all
transports.
See <ulink url='http://marc.info/?l=linux-scsi&amp;m=115507374832500&amp;w=2'>the
original patch submission</ulink> for more details.
</para>
!Idrivers/scsi/scsi_netlink.c
</sect2>
<sect2 id="scsi_scan.c">
<title>drivers/scsi/scsi_scan.c</title>
<para>
Scan a host to determine which (if any) devices are attached.
The general scanning/probing algorithm is as follows, exceptions are
made to it depending on device specific flags, compilation options,
and global variable (boot or module load time) settings.
A specific LUN is scanned via an INQUIRY command; if the LUN has a
device attached, a scsi_device is allocated and setup for it.
For every id of every channel on the given host, start by scanning
LUN 0. Skip hosts that don't respond at all to a scan of LUN 0.
Otherwise, if LUN 0 has a device attached, allocate and setup a
scsi_device for it. If target is SCSI-3 or up, issue a REPORT LUN,
and scan all of the LUNs returned by the REPORT LUN; else,
sequentially scan LUNs up until some maximum is reached, or a LUN is
seen that cannot have a device attached to it.
</para>
!Idrivers/scsi/scsi_scan.c
</sect2>
<sect2 id="scsi_sysctl.c">
<title>drivers/scsi/scsi_sysctl.c</title>
<para>
Set up the sysctl entry: "/dev/scsi/logging_level"
(DEV_SCSI_LOGGING_LEVEL) which sets/returns scsi_logging_level.
</para>
</sect2>
<sect2 id="scsi_sysfs.c">
<title>drivers/scsi/scsi_sysfs.c</title>
<para>
SCSI sysfs interface routines.
</para>
!Edrivers/scsi/scsi_sysfs.c
</sect2>
<sect2 id="hosts.c">
<title>drivers/scsi/hosts.c</title>
<para>
mid to lowlevel SCSI driver interface
</para>
!Edrivers/scsi/hosts.c
</sect2>
<sect2 id="constants.c">
<title>drivers/scsi/constants.c</title>
<para>
mid to lowlevel SCSI driver interface
</para>
!Edrivers/scsi/constants.c
</sect2>
</sect1>
<sect1 id="Transport_classes">
<title>Transport classes</title>
<para>
Transport classes are service libraries for drivers in the SCSI
lower layer, which expose transport attributes in sysfs.
</para>
<sect2 id="Fibre_Channel_transport">
<title>Fibre Channel transport</title>
<para>
The file drivers/scsi/scsi_transport_fc.c defines transport attributes
for Fibre Channel.
</para>
!Edrivers/scsi/scsi_transport_fc.c
</sect2>
<sect2 id="iSCSI_transport">
<title>iSCSI transport class</title>
<para>
The file drivers/scsi/scsi_transport_iscsi.c defines transport
attributes for the iSCSI class, which sends SCSI packets over TCP/IP
connections.
</para>
!Edrivers/scsi/scsi_transport_iscsi.c
</sect2>
<sect2 id="SAS_transport">
<title>Serial Attached SCSI (SAS) transport class</title>
<para>
The file drivers/scsi/scsi_transport_sas.c defines transport
attributes for Serial Attached SCSI, a variant of SATA aimed at
large high-end systems.
</para>
<para>
The SAS transport class contains common code to deal with SAS HBAs,
an aproximated representation of SAS topologies in the driver model,
and various sysfs attributes to expose these topologies and managment
interfaces to userspace.
</para>
<para>
In addition to the basic SCSI core objects this transport class
introduces two additional intermediate objects: The SAS PHY
as represented by struct sas_phy defines an "outgoing" PHY on
a SAS HBA or Expander, and the SAS remote PHY represented by
struct sas_rphy defines an "incoming" PHY on a SAS Expander or
end device. Note that this is purely a software concept, the
underlying hardware for a PHY and a remote PHY is the exactly
the same.
</para>
<para>
There is no concept of a SAS port in this code, users can see
what PHYs form a wide port based on the port_identifier attribute,
which is the same for all PHYs in a port.
</para>
!Edrivers/scsi/scsi_transport_sas.c
</sect2>
<sect2 id="SATA_transport">
<title>SATA transport class</title>
<para>
The SATA transport is handled by libata, which has its own book of
documentation in this directory.
</para>
</sect2>
<sect2 id="SPI_transport">
<title>Parallel SCSI (SPI) transport class</title>
<para>
The file drivers/scsi/scsi_transport_spi.c defines transport
attributes for traditional (fast/wide/ultra) SCSI busses.
</para>
!Edrivers/scsi/scsi_transport_spi.c
</sect2>
<sect2 id="SRP_transport">
<title>SCSI RDMA (SRP) transport class</title>
<para>
The file drivers/scsi/scsi_transport_srp.c defines transport
attributes for SCSI over Remote Direct Memory Access.
</para>
!Edrivers/scsi/scsi_transport_srp.c
</sect2>
</sect1>
</chapter>
<chapter id="lower_layer">
<title>SCSI lower layer</title>
<sect1 id="hba_drivers">
<title>Host Bus Adapter transport types</title>
<para>
Many modern device controllers use the SCSI command set as a protocol to
communicate with their devices through many different types of physical
connections.
</para>
<para>
In SCSI language a bus capable of carrying SCSI commands is
called a "transport", and a controller connecting to such a bus is
called a "host bus adapter" (HBA).
</para>
<sect2 id="scsi_debug.c">
<title>Debug transport</title>
<para>
The file drivers/scsi/scsi_debug.c simulates a host adapter with a
variable number of disks (or disk like devices) attached, sharing a
common amount of RAM. Does a lot of checking to make sure that we are
not getting blocks mixed up, and panics the kernel if anything out of
the ordinary is seen.
</para>
<para>
To be more realistic, the simulated devices have the transport
attributes of SAS disks.
</para>
<para>
For documentation see
<ulink url='http://www.torque.net/sg/sdebug26.html'>http://www.torque.net/sg/sdebug26.html</ulink>
</para>
<!-- !Edrivers/scsi/scsi_debug.c -->
</sect2>
<sect2 id="todo">
<title>todo</title>
<para>Parallel (fast/wide/ultra) SCSI, USB, SATA,
SAS, Fibre Channel, FireWire, ATAPI devices, Infiniband,
I20, iSCSI, Parallel ports, netlink...
</para>
</sect2>
</sect1>
</chapter>
</book>
...@@ -96,7 +96,6 @@ static struct video_device my_radio ...@@ -96,7 +96,6 @@ static struct video_device my_radio
{ {
"My radio", "My radio",
VID_TYPE_TUNER, VID_TYPE_TUNER,
VID_HARDWARE_MYRADIO,
radio_open. radio_open.
radio_close, radio_close,
NULL, /* no read */ NULL, /* no read */
...@@ -118,13 +117,6 @@ static struct video_device my_radio ...@@ -118,13 +117,6 @@ static struct video_device my_radio
indicates that the device can be tuned. Clearly our radio is going to have some indicates that the device can be tuned. Clearly our radio is going to have some
way to change channel so it is tuneable. way to change channel so it is tuneable.
</para> </para>
<para>
The VID_HARDWARE_ types are unique to each device. Numbers are assigned by
<email>alan@redhat.com</email> when device drivers are going to be released. Until then you
can pull a suitably large number out of your hat and use it. 10000 should be
safe for a very long time even allowing for the huge number of vendors
making new and different radio cards at the moment.
</para>
<para> <para>
We declare an open and close routine, but we do not need read or write, We declare an open and close routine, but we do not need read or write,
which are used to read and write video data to or from the card itself. As which are used to read and write video data to or from the card itself. As
...@@ -844,7 +836,6 @@ static struct video_device my_camera ...@@ -844,7 +836,6 @@ static struct video_device my_camera
"My Camera", "My Camera",
VID_TYPE_OVERLAY|VID_TYPE_SCALES|\ VID_TYPE_OVERLAY|VID_TYPE_SCALES|\
VID_TYPE_CAPTURE|VID_TYPE_CHROMAKEY, VID_TYPE_CAPTURE|VID_TYPE_CHROMAKEY,
VID_HARDWARE_MYCAMERA,
camera_open. camera_open.
camera_close, camera_close,
camera_read, /* no read */ camera_read, /* no read */
......
...@@ -9,8 +9,8 @@ The first thing resembling RCU was published in 1980, when Kung and Lehman ...@@ -9,8 +9,8 @@ The first thing resembling RCU was published in 1980, when Kung and Lehman
[Kung80] recommended use of a garbage collector to defer destruction [Kung80] recommended use of a garbage collector to defer destruction
of nodes in a parallel binary search tree in order to simplify its of nodes in a parallel binary search tree in order to simplify its
implementation. This works well in environments that have garbage implementation. This works well in environments that have garbage
collectors, but current production garbage collectors incur significant collectors, but most production garbage collectors incur significant
read-side overhead. overhead.
In 1982, Manber and Ladner [Manber82,Manber84] recommended deferring In 1982, Manber and Ladner [Manber82,Manber84] recommended deferring
destruction until all threads running at that time have terminated, again destruction until all threads running at that time have terminated, again
...@@ -99,16 +99,25 @@ locking, reduces contention, reduces memory latency for readers, and ...@@ -99,16 +99,25 @@ locking, reduces contention, reduces memory latency for readers, and
parallelizes pipeline stalls and memory latency for writers. However, parallelizes pipeline stalls and memory latency for writers. However,
these techniques still impose significant read-side overhead in the these techniques still impose significant read-side overhead in the
form of memory barriers. Researchers at Sun worked along similar lines form of memory barriers. Researchers at Sun worked along similar lines
in the same timeframe [HerlihyLM02,HerlihyLMS03]. These techniques in the same timeframe [HerlihyLM02]. These techniques can be thought
can be thought of as inside-out reference counts, where the count is of as inside-out reference counts, where the count is represented by the
represented by the number of hazard pointers referencing a given data number of hazard pointers referencing a given data structure (rather than
structure (rather than the more conventional counter field within the the more conventional counter field within the data structure itself).
data structure itself).
By the same token, RCU can be thought of as a "bulk reference count",
where some form of reference counter covers all reference by a given CPU
or thread during a set timeframe. This timeframe is related to, but
not necessarily exactly the same as, an RCU grace period. In classic
RCU, the reference counter is the per-CPU bit in the "bitmask" field,
and each such bit covers all references that might have been made by
the corresponding CPU during the prior grace period. Of course, RCU
can be thought of in other terms as well.
In 2003, the K42 group described how RCU could be used to create In 2003, the K42 group described how RCU could be used to create
hot-pluggable implementations of operating-system functions. Later that hot-pluggable implementations of operating-system functions [Appavoo03a].
year saw a paper describing an RCU implementation of System V IPC Later that year saw a paper describing an RCU implementation of System
[Arcangeli03], and an introduction to RCU in Linux Journal [McKenney03a]. V IPC [Arcangeli03], and an introduction to RCU in Linux Journal
[McKenney03a].
2004 has seen a Linux-Journal article on use of RCU in dcache 2004 has seen a Linux-Journal article on use of RCU in dcache
[McKenney04a], a performance comparison of locking to RCU on several [McKenney04a], a performance comparison of locking to RCU on several
...@@ -117,10 +126,19 @@ number of operating-system kernels [PaulEdwardMcKenneyPhD], a paper ...@@ -117,10 +126,19 @@ number of operating-system kernels [PaulEdwardMcKenneyPhD], a paper
describing how to make RCU safe for soft-realtime applications [Sarma04c], describing how to make RCU safe for soft-realtime applications [Sarma04c],
and a paper describing SELinux performance with RCU [JamesMorris04b]. and a paper describing SELinux performance with RCU [JamesMorris04b].
2005 has seen further adaptation of RCU to realtime use, permitting 2005 brought further adaptation of RCU to realtime use, permitting
preemption of RCU realtime critical sections [PaulMcKenney05a, preemption of RCU realtime critical sections [PaulMcKenney05a,
PaulMcKenney05b]. PaulMcKenney05b].
2006 saw the first best-paper award for an RCU paper [ThomasEHart2006a],
as well as further work on efficient implementations of preemptible
RCU [PaulEMcKenney2006b], but priority-boosting of RCU read-side critical
sections proved elusive. An RCU implementation permitting general
blocking in read-side critical sections appeared [PaulEMcKenney2006c],
Robert Olsson described an RCU-protected trie-hash combination
[RobertOlsson2006a].
Bibtex Entries Bibtex Entries
@article{Kung80 @article{Kung80
...@@ -203,6 +221,41 @@ Bibtex Entries ...@@ -203,6 +221,41 @@ Bibtex Entries
,Address="New Orleans, LA" ,Address="New Orleans, LA"
} }
@conference{Pu95a,
Author = "Calton Pu and Tito Autrey and Andrew Black and Charles Consel and
Crispin Cowan and Jon Inouye and Lakshmi Kethana and Jonathan Walpole and
Ke Zhang",
Title = "Optimistic Incremental Specialization: Streamlining a Commercial
Operating System",
Booktitle = "15\textsuperscript{th} ACM Symposium on
Operating Systems Principles (SOSP'95)",
address = "Copper Mountain, CO",
month="December",
year="1995",
pages="314-321",
annotation="
Uses a replugger, but with a flag to signal when people are
using the resource at hand. Only one reader at a time.
"
}
@conference{Cowan96a,
Author = "Crispin Cowan and Tito Autrey and Charles Krasic and
Calton Pu and Jonathan Walpole",
Title = "Fast Concurrent Dynamic Linking for an Adaptive Operating System",
Booktitle = "International Conference on Configurable Distributed Systems
(ICCDS'96)",
address = "Annapolis, MD",
month="May",
year="1996",
pages="108",
isbn="0-8186-7395-8",
annotation="
Uses a replugger, but with a counter to signal when people are
using the resource at hand. Allows multiple readers.
"
}
@techreport{Slingwine95 @techreport{Slingwine95
,author="John D. Slingwine and Paul E. McKenney" ,author="John D. Slingwine and Paul E. McKenney"
,title="Apparatus and Method for Achieving Reduced Overhead Mutual ,title="Apparatus and Method for Achieving Reduced Overhead Mutual
...@@ -312,6 +365,49 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell" ...@@ -312,6 +365,49 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell"
[Viewed June 23, 2004]" [Viewed June 23, 2004]"
} }
@conference{Michael02a
,author="Maged M. Michael"
,title="Safe Memory Reclamation for Dynamic Lock-Free Objects Using Atomic
Reads and Writes"
,Year="2002"
,Month="August"
,booktitle="{Proceedings of the 21\textsuperscript{st} Annual ACM
Symposium on Principles of Distributed Computing}"
,pages="21-30"
,annotation="
Each thread keeps an array of pointers to items that it is
currently referencing. Sort of an inside-out garbage collection
mechanism, but one that requires the accessing code to explicitly
state its needs. Also requires read-side memory barriers on
most architectures.
"
}
@conference{Michael02b
,author="Maged M. Michael"
,title="High Performance Dynamic Lock-Free Hash Tables and List-Based Sets"
,Year="2002"
,Month="August"
,booktitle="{Proceedings of the 14\textsuperscript{th} Annual ACM
Symposium on Parallel
Algorithms and Architecture}"
,pages="73-82"
,annotation="
Like the title says...
"
}
@InProceedings{HerlihyLM02
,author={Maurice Herlihy and Victor Luchangco and Mark Moir}
,title="The Repeat Offender Problem: A Mechanism for Supporting Dynamic-Sized,
Lock-Free Data Structures"
,booktitle={Proceedings of 16\textsuperscript{th} International
Symposium on Distributed Computing}
,year=2002
,month="October"
,pages="339-353"
}
@article{Appavoo03a @article{Appavoo03a
,author="J. Appavoo and K. Hui and C. A. N. Soules and R. W. Wisniewski and ,author="J. Appavoo and K. Hui and C. A. N. Soules and R. W. Wisniewski and
D. M. {Da Silva} and O. Krieger and M. A. Auslander and D. J. Edelsohn and D. M. {Da Silva} and O. Krieger and M. A. Auslander and D. J. Edelsohn and
...@@ -447,3 +543,95 @@ Oregon Health and Sciences University" ...@@ -447,3 +543,95 @@ Oregon Health and Sciences University"
Realtime turns into making RCU yet more realtime friendly. Realtime turns into making RCU yet more realtime friendly.
" "
} }
@conference{ThomasEHart2006a
,Author="Thomas E. Hart and Paul E. McKenney and Angela Demke Brown"
,Title="Making Lockless Synchronization Fast: Performance Implications
of Memory Reclamation"
,Booktitle="20\textsuperscript{th} {IEEE} International Parallel and
Distributed Processing Symposium"
,month="April"
,year="2006"
,day="25-29"
,address="Rhodes, Greece"
,annotation="
Compares QSBR (AKA "classic RCU"), HPBR, EBR, and lock-free
reference counting.
"
}
@Conference{PaulEMcKenney2006b
,Author="Paul E. McKenney and Dipankar Sarma and Ingo Molnar and
Suparna Bhattacharya"
,Title="Extending RCU for Realtime and Embedded Workloads"
,Booktitle="{Ottawa Linux Symposium}"
,Month="July"
,Year="2006"
,pages="v2 123-138"
,note="Available:
\url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184}
\url{http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf}
[Viewed January 1, 2007]"
,annotation="
Described how to improve the -rt implementation of realtime RCU.
"
}
@unpublished{PaulEMcKenney2006c
,Author="Paul E. McKenney"
,Title="Sleepable {RCU}"
,month="October"
,day="9"
,year="2006"
,note="Available:
\url{http://lwn.net/Articles/202847/}
Revised:
\url{http://www.rdrop.com/users/paulmck/RCU/srcu.2007.01.14a.pdf}
[Viewed August 21, 2006]"
,annotation="
LWN article introducing SRCU.
"
}
@unpublished{RobertOlsson2006a
,Author="Robert Olsson and Stefan Nilsson"
,Title="{TRASH}: A dynamic {LC}-trie and hash data structure"
,month="August"
,day="18"
,year="2006"
,note="Available:
\url{http://www.nada.kth.se/~snilsson/public/papers/trash/trash.pdf}
[Viewed February 24, 2007]"
,annotation="
RCU-protected dynamic trie-hash combination.
"
}
@unpublished{ThomasEHart2007a
,Author="Thomas E. Hart and Paul E. McKenney and Angela Demke Brown and Jonathan Walpole"
,Title="Performance of memory reclamation for lockless synchronization"
,journal="J. Parallel Distrib. Comput."
,year="2007"
,note="To appear in J. Parallel Distrib. Comput.
\url{doi=10.1016/j.jpdc.2007.04.010}"
,annotation={
Compares QSBR (AKA "classic RCU"), HPBR, EBR, and lock-free
reference counting. Journal version of ThomasEHart2006a.
}
}
@unpublished{PaulEMcKenney2007QRCUspin
,Author="Paul E. McKenney"
,Title="Using Promela and Spin to verify parallel algorithms"
,month="August"
,day="1"
,year="2007"
,note="Available:
\url{http://lwn.net/Articles/243851/}
[Viewed September 8, 2007]"
,annotation="
LWN article describing Promela and spin, and also using Oleg
Nesterov's QRCU as an example (with Paul McKenney's fastpath).
"
}
...@@ -36,6 +36,14 @@ o How can the updater tell when a grace period has completed ...@@ -36,6 +36,14 @@ o How can the updater tell when a grace period has completed
executed in user mode, or executed in the idle loop, we can executed in user mode, or executed in the idle loop, we can
safely free up that item. safely free up that item.
Preemptible variants of RCU (CONFIG_PREEMPT_RCU) get the
same effect, but require that the readers manipulate CPU-local
counters. These counters allow limited types of blocking
within RCU read-side critical sections. SRCU also uses
CPU-local counters, and permits general blocking within
RCU read-side critical sections. These two variants of
RCU detect grace periods by sampling these counters.
o If I am running on a uniprocessor kernel, which can only do one o If I am running on a uniprocessor kernel, which can only do one
thing at a time, why should I wait for a grace period? thing at a time, why should I wait for a grace period?
...@@ -46,7 +54,10 @@ o How can I see where RCU is currently used in the Linux kernel? ...@@ -46,7 +54,10 @@ o How can I see where RCU is currently used in the Linux kernel?
Search for "rcu_read_lock", "rcu_read_unlock", "call_rcu", Search for "rcu_read_lock", "rcu_read_unlock", "call_rcu",
"rcu_read_lock_bh", "rcu_read_unlock_bh", "call_rcu_bh", "rcu_read_lock_bh", "rcu_read_unlock_bh", "call_rcu_bh",
"srcu_read_lock", "srcu_read_unlock", "synchronize_rcu", "srcu_read_lock", "srcu_read_unlock", "synchronize_rcu",
"synchronize_net", and "synchronize_srcu". "synchronize_net", "synchronize_srcu", and the other RCU
primitives. Or grab one of the cscope databases from:
http://www.rdrop.com/users/paulmck/RCU/linuxusage/rculocktab.html
o What guidelines should I follow when writing code that uses RCU? o What guidelines should I follow when writing code that uses RCU?
...@@ -67,7 +78,11 @@ o I hear that RCU is patented? What is with that? ...@@ -67,7 +78,11 @@ o I hear that RCU is patented? What is with that?
o I hear that RCU needs work in order to support realtime kernels? o I hear that RCU needs work in order to support realtime kernels?
Yes, work in progress. This work is largely completed. Realtime-friendly RCU can be
enabled via the CONFIG_PREEMPT_RCU kernel configuration parameter.
However, work is in progress for enabling priority boosting of
preempted RCU read-side critical sections.This is needed if you
have CPU-bound realtime threads.
o Where can I find more information on RCU? o Where can I find more information on RCU?
......
...@@ -46,12 +46,13 @@ stat_interval The number of seconds between output of torture ...@@ -46,12 +46,13 @@ stat_interval The number of seconds between output of torture
shuffle_interval shuffle_interval
The number of seconds to keep the test threads affinitied The number of seconds to keep the test threads affinitied
to a particular subset of the CPUs. Used in conjunction to a particular subset of the CPUs, defaults to 5 seconds.
with test_no_idle_hz. Used in conjunction with test_no_idle_hz.
test_no_idle_hz Whether or not to test the ability of RCU to operate in test_no_idle_hz Whether or not to test the ability of RCU to operate in
a kernel that disables the scheduling-clock interrupt to a kernel that disables the scheduling-clock interrupt to
idle CPUs. Boolean parameter, "1" to test, "0" otherwise. idle CPUs. Boolean parameter, "1" to test, "0" otherwise.
Defaults to omitting this test.
torture_type The type of RCU to test: "rcu" for the rcu_read_lock() API, torture_type The type of RCU to test: "rcu" for the rcu_read_lock() API,
"rcu_sync" for rcu_read_lock() with synchronous reclamation, "rcu_sync" for rcu_read_lock() with synchronous reclamation,
...@@ -82,8 +83,6 @@ be evident. ;-) ...@@ -82,8 +83,6 @@ be evident. ;-)
The entries are as follows: The entries are as follows:
o "ggp": The number of counter flips (or batches) since boot.
o "rtc": The hexadecimal address of the structure currently visible o "rtc": The hexadecimal address of the structure currently visible
to readers. to readers.
...@@ -117,8 +116,8 @@ o "Reader Pipe": Histogram of "ages" of structures seen by readers. ...@@ -117,8 +116,8 @@ o "Reader Pipe": Histogram of "ages" of structures seen by readers.
o "Reader Batch": Another histogram of "ages" of structures seen o "Reader Batch": Another histogram of "ages" of structures seen
by readers, but in terms of counter flips (or batches) rather by readers, but in terms of counter flips (or batches) rather
than in terms of grace periods. The legal number of non-zero than in terms of grace periods. The legal number of non-zero
entries is again two. The reason for this separate view is entries is again two. The reason for this separate view is that
that it is easier to get the third entry to show up in the it is sometimes easier to get the third entry to show up in the
"Reader Batch" list than in the "Reader Pipe" list. "Reader Batch" list than in the "Reader Pipe" list.
o "Free-Block Circulation": Shows the number of torture structures o "Free-Block Circulation": Shows the number of torture structures
......
...@@ -45,6 +45,7 @@ The following ARM processors are supported by cpufreq: ...@@ -45,6 +45,7 @@ The following ARM processors are supported by cpufreq:
ARM Integrator ARM Integrator
ARM-SA1100 ARM-SA1100
ARM-SA1110 ARM-SA1110
Intel PXA
1.2 x86 1.2 x86
......
...@@ -50,7 +50,7 @@ additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets ...@@ -50,7 +50,7 @@ additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets
cpu_possible_map = cpu_present_map + additional_cpus cpu_possible_map = cpu_present_map + additional_cpus
(*) Option valid only for following architectures (*) Option valid only for following architectures
- x86_64, ia64, s390 - x86_64, ia64
ia64 and x86_64 use the number of disabled local apics in ACPI tables MADT ia64 and x86_64 use the number of disabled local apics in ACPI tables MADT
to determine the number of potentially hot-pluggable cpus. The implementation to determine the number of potentially hot-pluggable cpus. The implementation
...@@ -109,12 +109,13 @@ Never use anything other than cpumask_t to represent bitmap of CPUs. ...@@ -109,12 +109,13 @@ Never use anything other than cpumask_t to represent bitmap of CPUs.
for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask. for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.
#include <linux/cpu.h> #include <linux/cpu.h>
lock_cpu_hotplug() and unlock_cpu_hotplug(): get_online_cpus() and put_online_cpus():
The above calls are used to inhibit cpu hotplug operations. While holding the The above calls are used to inhibit cpu hotplug operations. While the
cpucontrol mutex, cpu_online_map will not change. If you merely need to avoid cpu_hotplug.refcount is non zero, the cpu_online_map will not change.
cpus going away, you could also use preempt_disable() and preempt_enable() If you merely need to avoid cpus going away, you could also use
for those sections. Just remember the critical section cannot call any preempt_disable() and preempt_enable() for those sections.
Just remember the critical section cannot call any
function that can sleep or schedule this process away. The preempt_disable() function that can sleep or schedule this process away. The preempt_disable()
will work as long as stop_machine_run() is used to take a cpu down. will work as long as stop_machine_run() is used to take a cpu down.
......
...@@ -33,9 +33,16 @@ The idea is to make the user interface and algorithm registration API ...@@ -33,9 +33,16 @@ The idea is to make the user interface and algorithm registration API
very simple, while hiding the core logic from both. Many good ideas very simple, while hiding the core logic from both. Many good ideas
from existing APIs such as Cryptoapi and Nettle have been adapted for this. from existing APIs such as Cryptoapi and Nettle have been adapted for this.
The API currently supports three types of transforms: Ciphers, Digests and The API currently supports five main types of transforms: AEAD (Authenticated
Compressors. The compression algorithms especially seem to be performing Encryption with Associated Data), Block Ciphers, Ciphers, Compressors and
very well so far. Hashes.
Please note that Block Ciphers is somewhat of a misnomer. It is in fact
meant to support all ciphers including stream ciphers. The difference
between Block Ciphers and Ciphers is that the latter operates on exactly
one block while the former can operate on an arbitrary amount of data,
subject to block size requirements (i.e., non-stream ciphers can only
process multiples of blocks).
Support for hardware crypto devices via an asynchronous interface is Support for hardware crypto devices via an asynchronous interface is
under development. under development.
...@@ -69,29 +76,12 @@ Here's an example of how to use the API: ...@@ -69,29 +76,12 @@ Here's an example of how to use the API:
Many real examples are available in the regression test module (tcrypt.c). Many real examples are available in the regression test module (tcrypt.c).
CONFIGURATION NOTES
As Triple DES is part of the DES module, for those using modular builds,
add the following line to /etc/modprobe.conf:
alias des3_ede des
The Null algorithms reside in the crypto_null module, so these lines
should also be added:
alias cipher_null crypto_null
alias digest_null crypto_null
alias compress_null crypto_null
The SHA384 algorithm shares code within the SHA512 module, so you'll
also need:
alias sha384 sha512
DEVELOPER NOTES DEVELOPER NOTES
Transforms may only be allocated in user context, and cryptographic Transforms may only be allocated in user context, and cryptographic
methods may only be called from softirq and user contexts. methods may only be called from softirq and user contexts. For
transforms with a setkey method it too should only be called from
user context.
When using the API for ciphers, performance will be optimal if each When using the API for ciphers, performance will be optimal if each
scatterlist contains data which is a multiple of the cipher's block scatterlist contains data which is a multiple of the cipher's block
...@@ -130,8 +120,9 @@ might already be working on. ...@@ -130,8 +120,9 @@ might already be working on.
BUGS BUGS
Send bug reports to: Send bug reports to:
Herbert Xu <herbert@gondor.apana.org.au> linux-crypto@vger.kernel.org
Cc: David S. Miller <davem@redhat.com> Cc: Herbert Xu <herbert@gondor.apana.org.au>,
David S. Miller <davem@redhat.com>
FURTHER INFORMATION FURTHER INFORMATION
......
Using physical DMA provided by OHCI-1394 FireWire controllers for debugging
---------------------------------------------------------------------------
Introduction
------------
Basically all FireWire controllers which are in use today are compliant
to the OHCI-1394 specification which defines the controller to be a PCI
bus master which uses DMA to offload data transfers from the CPU and has
a "Physical Response Unit" which executes specific requests by employing
PCI-Bus master DMA after applying filters defined by the OHCI-1394 driver.
Once properly configured, remote machines can send these requests to
ask the OHCI-1394 controller to perform read and write requests on
physical system memory and, for read requests, send the result of
the physical memory read back to the requester.
With that, it is possible to debug issues by reading interesting memory
locations such as buffers like the printk buffer or the process table.
Retrieving a full system memory dump is also possible over the FireWire,
using data transfer rates in the order of 10MB/s or more.
Memory access is currently limited to the low 4G of physical address
space which can be a problem on IA64 machines where memory is located
mostly above that limit, but it is rarely a problem on more common
hardware such as hardware based on x86, x86-64 and PowerPC.
Together with a early initialization of the OHCI-1394 controller for debugging,
this facility proved most useful for examining long debugs logs in the printk
buffer on to debug early boot problems in areas like ACPI where the system
fails to boot and other means for debugging (serial port) are either not
available (notebooks) or too slow for extensive debug information (like ACPI).
Drivers
-------
The OHCI-1394 drivers in drivers/firewire and drivers/ieee1394 initialize
the OHCI-1394 controllers to a working state and can be used to enable
physical DMA. By default you only have to load the driver, and physical
DMA access will be granted to all remote nodes, but it can be turned off
when using the ohci1394 driver.
Because these drivers depend on the PCI enumeration to be completed, an
initialization routine which can runs pretty early (long before console_init(),
which makes the printk buffer appear on the console can be called) was written.
To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
Provide code for enabling DMA over FireWire early on boot) and pass the
parameter "ohci1394_dma=early" to the recompiled kernel on boot.
Tools
-----
firescope - Originally developed by Benjamin Herrenschmidt, Andi Kleen ported
it from PowerPC to x86 and x86_64 and added functionality, firescope can now
be used to view the printk buffer of a remote machine, even with live update.
Bernhard Kaindl enhanced firescope to support accessing 64-bit machines
from 32-bit firescope and vice versa:
- ftp://ftp.suse.de/private/bk/firewire/tools/firescope-0.2.2.tar.bz2
and he implemented fast system dump (alpha version - read README.txt):
- ftp://ftp.suse.de/private/bk/firewire/tools/firedump-0.1.tar.bz2
There is also a gdb proxy for firewire which allows to use gdb to access
data which can be referenced from symbols found by gdb in vmlinux:
- ftp://ftp.suse.de/private/bk/firewire/tools/fireproxy-0.33.tar.bz2
The latest version of this gdb proxy (fireproxy-0.34) can communicate (not
yet stable) with kgdb over an memory-based communication module (kgdbom).
Getting Started
---------------
The OHCI-1394 specification regulates that the OHCI-1394 controller must
disable all physical DMA on each bus reset.
This means that if you want to debug an issue in a system state where
interrupts are disabled and where no polling of the OHCI-1394 controller
for bus resets takes place, you have to establish any FireWire cable
connections and fully initialize all FireWire hardware __before__ the
system enters such state.
Step-by-step instructions for using firescope with early OHCI initialization:
1) Verify that your hardware is supported:
Load the ohci1394 or the fw-ohci module and check your kernel logs.
You should see a line similar to
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18] MMIO=[fe9ff800-fe9fffff]
... Max Packet=[2048] IR/IT contexts=[4/8]
when loading the driver. If you have no supported controller, many PCI,
CardBus and even some Express cards which are fully compliant to OHCI-1394
specification are available. If it requires no driver for Windows operating
systems, it most likely is. Only specialized shops have cards which are not
compliant, they are based on TI PCILynx chips and require drivers for Win-
dows operating systems.
2) Establish a working FireWire cable connection:
Any FireWire cable, as long at it provides electrically and mechanically
stable connection and has matching connectors (there are small 4-pin and
large 6-pin FireWire ports) will do.
If an driver is running on both machines you should see a line like
ieee1394: Node added: ID:BUS[0-01:1023] GUID[0090270001b84bba]
on both machines in the kernel log when the cable is plugged in
and connects the two machines.
3) Test physical DMA using firescope:
On the debug host,
- load the raw1394 module,
- make sure that /dev/raw1394 is accessible,
then start firescope:
$ firescope
Port 0 (ohci1394) opened, 2 nodes detected
FireScope
---------
Target : <unspecified>
Gen : 1
[Ctrl-T] choose target
[Ctrl-H] this menu
[Ctrl-Q] quit
------> Press Ctrl-T now, the output should be similar to:
2 nodes available, local node is: 0
0: ffc0, uuid: 00000000 00000000 [LOCAL]
1: ffc1, uuid: 00279000 ba4bb801
Besides the [LOCAL] node, it must show another node without error message.
4) Prepare for debugging with early OHCI-1394 initialization:
4.1) Kernel compilation and installation on debug target
Compile the kernel to be debugged with CONFIG_PROVIDE_OHCI1394_DMA_INIT
(Kernel hacking: Provide code for enabling DMA over FireWire early on boot)
enabled and install it on the machine to be debugged (debug target).
4.2) Transfer the System.map of the debugged kernel to the debug host
Copy the System.map of the kernel be debugged to the debug host (the host
which is connected to the debugged machine over the FireWire cable).
5) Retrieving the printk buffer contents:
With the FireWire cable connected, the OHCI-1394 driver on the debugging
host loaded, reboot the debugged machine, booting the kernel which has
CONFIG_PROVIDE_OHCI1394_DMA_INIT enabled, with the option ohci1394_dma=early.
Then, on the debugging host, run firescope, for example by using -A:
firescope -A System.map-of-debug-target-kernel
Note: -A automatically attaches to the first non-local node. It only works
reliably if only connected two machines are connected using FireWire.
After having attached to the debug target, press Ctrl-D to view the
complete printk buffer or Ctrl-U to enter auto update mode and get an
updated live view of recent kernel messages logged on the debug target.
Call "firescope -h" to get more information on firescope's options.
Notes
-----
Documentation and specifications: ftp://ftp.suse.de/private/bk/firewire/docs
FireWire is a trademark of Apple Inc. - for more information please refer to:
http://en.wikipedia.org/wiki/FireWire
...@@ -46,8 +46,6 @@ ...@@ -46,8 +46,6 @@
.mailmap .mailmap
.mm .mm
53c700_d.h 53c700_d.h
53c7xx_d.h
53c7xx_u.h
53c8xx_d.h* 53c8xx_d.h*
BitKeeper BitKeeper
COPYING COPYING
......
...@@ -78,6 +78,18 @@ Example: ...@@ -78,6 +78,18 @@ Example:
For a full list of card ID's please see Documentation/video4linux/CARDLIST.bttv. For a full list of card ID's please see Documentation/video4linux/CARDLIST.bttv.
In case of further problems please subscribe and send questions to the mailing list: linux-dvb@linuxtv.org. In case of further problems please subscribe and send questions to the mailing list: linux-dvb@linuxtv.org.
2c) Probing the cards with broken PCI subsystem ID
--------------------------------------------------
There are some TwinHan cards that the EEPROM has become corrupted for some
reason. The cards do not have correct PCI subsystem ID. But we can force
probing the cards with broken PCI subsystem ID
$ echo 109e 0878 $subvendor $subdevice > \
/sys/bus/pci/drivers/bt878/new_id
109e: PCI_VENDOR_ID_BROOKTREE
0878: PCI_DEVICE_ID_BROOKTREE_878
Authors: Richard Walker, Authors: Richard Walker,
Jamie Honan, Jamie Honan,
Michael Hunold, Michael Hunold,
......
...@@ -191,15 +191,6 @@ Who: Kay Sievers <kay.sievers@suse.de> ...@@ -191,15 +191,6 @@ Who: Kay Sievers <kay.sievers@suse.de>
--------------------------- ---------------------------
What: i2c_adapter.list
When: July 2007
Why: Superfluous, this list duplicates the one maintained by the driver
core.
Who: Jean Delvare <khali@linux-fr.org>,
David Brownell <dbrownell@users.sourceforge.net>
---------------------------
What: ACPI procfs interface What: ACPI procfs interface
When: July 2008 When: July 2008
Why: ACPI sysfs conversion should be finished by January 2008. Why: ACPI sysfs conversion should be finished by January 2008.
...@@ -225,14 +216,6 @@ Who: Len Brown <len.brown@intel.com> ...@@ -225,14 +216,6 @@ Who: Len Brown <len.brown@intel.com>
--------------------------- ---------------------------
What: i2c-ixp2000, i2c-ixp4xx and scx200_i2c drivers
When: September 2007
Why: Obsolete. The new i2c-gpio driver replaces all hardware-specific
I2C-over-GPIO drivers.
Who: Jean Delvare <khali@linux-fr.org>
---------------------------
What: 'time' kernel boot parameter What: 'time' kernel boot parameter
When: January 2008 When: January 2008
Why: replaced by 'printk.time=<value>' so that printk timestamps can be Why: replaced by 'printk.time=<value>' so that printk timestamps can be
...@@ -266,22 +249,6 @@ Who: Tejun Heo <htejun@gmail.com> ...@@ -266,22 +249,6 @@ Who: Tejun Heo <htejun@gmail.com>
--------------------------- ---------------------------
What: Legacy RTC drivers (under drivers/i2c/chips)
When: November 2007
Why: Obsolete. We have a RTC subsystem with better drivers.
Who: Jean Delvare <khali@linux-fr.org>
---------------------------
What: iptables SAME target
When: 1.1. 2008
Files: net/ipv4/netfilter/ipt_SAME.c, include/linux/netfilter_ipv4/ipt_SAME.h
Why: Obsolete for multiple years now, NAT core provides the same behaviour.
Unfixable broken wrt. 32/64 bit cleanness.
Who: Patrick McHardy <kaber@trash.net>
---------------------------
What: The arch/ppc and include/asm-ppc directories What: The arch/ppc and include/asm-ppc directories
When: Jun 2008 When: Jun 2008
Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64 Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64
...@@ -295,16 +262,6 @@ Who: linuxppc-dev@ozlabs.org ...@@ -295,16 +262,6 @@ Who: linuxppc-dev@ozlabs.org
--------------------------- ---------------------------
What: mthca driver's MSI support
When: January 2008
Files: drivers/infiniband/hw/mthca/*.[ch]
Why: All mthca hardware also supports MSI-X, which provides
strictly more functionality than MSI. So there is no point in
having both MSI-X and MSI support in the driver.
Who: Roland Dreier <rolandd@cisco.com>
---------------------------
What: sk98lin network driver What: sk98lin network driver
When: Feburary 2008 When: Feburary 2008
Why: In kernel tree version of driver is unmaintained. Sk98lin driver Why: In kernel tree version of driver is unmaintained. Sk98lin driver
...@@ -323,13 +280,77 @@ Who: Thomas Gleixner <tglx@linutronix.de> ...@@ -323,13 +280,77 @@ Who: Thomas Gleixner <tglx@linutronix.de>
--------------------------- ---------------------------
What: shaper network driver ---------------------------
When: January 2008
Files: drivers/net/shaper.c, include/linux/if_shaper.h What: i2c-i810, i2c-prosavage and i2c-savage4
Why: This driver has been marked obsolete for many years. When: May 2008
It was only designed to work on lower speed links and has design Why: These drivers are superseded by i810fb, intelfb and savagefb.
flaws that lead to machine crashes. The qdisc infrastructure in Who: Jean Delvare <khali@linux-fr.org>
2.4 or later kernels, provides richer features and is more robust.
Who: Stephen Hemminger <shemminger@linux-foundation.org>
--------------------------- ---------------------------
What: bcm43xx wireless network driver
When: 2.6.26
Files: drivers/net/wireless/bcm43xx
Why: This driver's functionality has been replaced by the
mac80211-based b43 and b43legacy drivers.
Who: John W. Linville <linville@tuxdriver.com>
---------------------------
What: ieee80211 softmac wireless networking component
When: 2.6.26 (or after removal of bcm43xx and port of zd1211rw to mac80211)
Files: net/ieee80211/softmac
Why: No in-kernel drivers will depend on it any longer.
Who: John W. Linville <linville@tuxdriver.com>
---------------------------
What: rc80211-simple rate control algorithm for mac80211
When: 2.6.26
Files: net/mac80211/rc80211-simple.c
Why: This algorithm was provided for reference but always exhibited bad
responsiveness and performance and has some serious flaws. It has been
replaced by rc80211-pid.
Who: Stefano Brivio <stefano.brivio@polimi.it>
---------------------------
What (Why):
- include/linux/netfilter_ipv4/ipt_TOS.h ipt_tos.h header files
(superseded by xt_TOS/xt_tos target & match)
- "forwarding" header files like ipt_mac.h in
include/linux/netfilter_ipv4/ and include/linux/netfilter_ipv6/
- xt_CONNMARK match revision 0
(superseded by xt_CONNMARK match revision 1)
- xt_MARK target revisions 0 and 1
(superseded by xt_MARK match revision 2)
- xt_connmark match revision 0
(superseded by xt_connmark match revision 1)
- xt_conntrack match revision 0
(superseded by xt_conntrack match revision 1)
- xt_iprange match revision 0,
include/linux/netfilter_ipv4/ipt_iprange.h
(superseded by xt_iprange match revision 1)
- xt_mark match revision 0
(superseded by xt_mark match revision 1)
When: January 2009 or Linux 2.7.0, whichever comes first
Why: Superseded by newer revisions or modules
Who: Jan Engelhardt <jengelh@computergmbh.de>
---------------------------
What: b43 support for firmware revision < 410
When: July 2008
Why: The support code for the old firmware hurts code readability/maintainability
and slightly hurts runtime performance. Bugfixes for the old firmware
are not provided by Broadcom anymore.
Who: Michael Buesch <mb@bu3sch.de>
...@@ -86,9 +86,21 @@ Alex is working on a new set of patches right now. ...@@ -86,9 +86,21 @@ Alex is working on a new set of patches right now.
When mounting an ext4 filesystem, the following option are accepted: When mounting an ext4 filesystem, the following option are accepted:
(*) == default (*) == default
extents ext4 will use extents to address file data. The extents (*) ext4 will use extents to address file data. The
file system will no longer be mountable by ext3. file system will no longer be mountable by ext3.
noextents ext4 will not use extents for newly created files
journal_checksum Enable checksumming of the journal transactions.
This will allow the recovery code in e2fsck and the
kernel to detect corruption in the kernel. It is a
compatible change and will be ignored by older kernels.
journal_async_commit Commit block can be written to disk without waiting
for descriptor blocks. If enabled older kernels cannot
mount the device. This will enable 'journal_checksum'
internally.
journal=update Update the ext4 file system's journal to the current journal=update Update the ext4 file system's journal to the current
format. format.
...@@ -196,6 +208,12 @@ nobh (a) cache disk block mapping information ...@@ -196,6 +208,12 @@ nobh (a) cache disk block mapping information
"nobh" option tries to avoid associating buffer "nobh" option tries to avoid associating buffer
heads (supported only for "writeback" mode). heads (supported only for "writeback" mode).
mballoc (*) Use the multiple block allocator for block allocation
nomballoc disabled multiple block allocator for block allocation.
stripe=n Number of filesystem blocks that mballoc will try
to use for allocation size and alignment. For RAID5/6
systems this should be the number of data
disks * RAID chunk size in file system blocks.
Data Mode Data Mode
--------- ---------
......
...@@ -35,7 +35,6 @@ Features which OCFS2 does not support yet: ...@@ -35,7 +35,6 @@ Features which OCFS2 does not support yet:
- Directory change notification (F_NOTIFY) - Directory change notification (F_NOTIFY)
- Distributed Caching (F_SETLEASE/F_GETLEASE/break_lease) - Distributed Caching (F_SETLEASE/F_GETLEASE/break_lease)
- POSIX ACLs - POSIX ACLs
- readpages / writepages (not user visible)
Mount options Mount options
============= =============
...@@ -62,3 +61,18 @@ data=writeback Data ordering is not preserved, data may be written ...@@ -62,3 +61,18 @@ data=writeback Data ordering is not preserved, data may be written
preferred_slot=0(*) During mount, try to use this filesystem slot first. If preferred_slot=0(*) During mount, try to use this filesystem slot first. If
it is in use by another node, the first empty one found it is in use by another node, the first empty one found
will be chosen. Invalid values will be ignored. will be chosen. Invalid values will be ignored.
commit=nrsec (*) Ocfs2 can be told to sync all its data and metadata
every 'nrsec' seconds. The default value is 5 seconds.
This means that if you lose your power, you will lose
as much as the latest 5 seconds of work (your
filesystem will not be damaged though, thanks to the
journaling). This default value (or any low value)
will hurt performance, but it's good for data-safety.
Setting it to 0 will have the same effect as leaving
it at the default (5 seconds).
Setting it to very large values will improve
performance.
localalloc=8(*) Allows custom localalloc size in MB. If the value is too
large, the fs will silently revert it to the default.
Localalloc is not enabled for local mounts.
localflocks This disables cluster aware flock.
...@@ -857,6 +857,45 @@ CPUs. ...@@ -857,6 +857,45 @@ CPUs.
The "procs_blocked" line gives the number of processes currently blocked, The "procs_blocked" line gives the number of processes currently blocked,
waiting for I/O to complete. waiting for I/O to complete.
1.9 Ext4 file system parameters
------------------------------
Ext4 file system have one directory per partition under /proc/fs/ext4/
# ls /proc/fs/ext4/hdc/
group_prealloc max_to_scan mb_groups mb_history min_to_scan order2_req
stats stream_req
mb_groups:
This file gives the details of mutiblock allocator buddy cache of free blocks
mb_history:
Multiblock allocation history.
stats:
This file indicate whether the multiblock allocator should start collecting
statistics. The statistics are shown during unmount
group_prealloc:
The multiblock allocator normalize the block allocation request to
group_prealloc filesystem blocks if we don't have strip value set.
The stripe value can be specified at mount time or during mke2fs.
max_to_scan:
How long multiblock allocator can look for a best extent (in found extents)
min_to_scan:
How long multiblock allocator must look for a best extent
order2_req:
Multiblock allocator use 2^N search using buddies only for requests greater
than or equal to order2_req. The request size is specfied in file system
blocks. A value of 2 indicate only if the requests are greater than or equal
to 4 blocks.
stream_req:
Files smaller than stream_req are served by the stream allocator, whose
purpose is to pack requests as close each to other as possible to
produce smooth I/O traffic. Avalue of 16 indicate that file smaller than 16
filesystem block size will use group based preallocation.
------------------------------------------------------------------------------ ------------------------------------------------------------------------------
Summary Summary
......
...@@ -17,9 +17,8 @@ Supported adapters: ...@@ -17,9 +17,8 @@ Supported adapters:
Datasheets: Publicly available at the Intel website Datasheets: Publicly available at the Intel website
Authors: Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Mark Studebaker <mdsxyz123@yahoo.com> Mark Studebaker <mdsxyz123@yahoo.com>
Jean Delvare <khali@linux-fr.org>
Module Parameters Module Parameters
...@@ -62,7 +61,7 @@ Not supported. ...@@ -62,7 +61,7 @@ Not supported.
I2C Block Read Support I2C Block Read Support
---------------------- ----------------------
Not supported at the moment. I2C block read is supported on the 82801EB (ICH5) and later chips.
SMBus 2.0 Support SMBus 2.0 Support
......
...@@ -10,7 +10,7 @@ Supported adapters: ...@@ -10,7 +10,7 @@ Supported adapters:
* VIA Technologies, Inc. VT8231, VT8233, VT8233A * VIA Technologies, Inc. VT8231, VT8233, VT8233A
Datasheet: available on request from VIA Datasheet: available on request from VIA
* VIA Technologies, Inc. VT8235, VT8237R, VT8237A, VT8251 * VIA Technologies, Inc. VT8235, VT8237R, VT8237A, VT8237S, VT8251
Datasheet: available on request and under NDA from VIA Datasheet: available on request and under NDA from VIA
* VIA Technologies, Inc. CX700 * VIA Technologies, Inc. CX700
...@@ -46,6 +46,7 @@ Your lspci -n listing must show one of these : ...@@ -46,6 +46,7 @@ Your lspci -n listing must show one of these :
device 1106:3177 (VT8235) device 1106:3177 (VT8235)
device 1106:3227 (VT8237R) device 1106:3227 (VT8237R)
device 1106:3337 (VT8237A) device 1106:3337 (VT8237A)
device 1106:3372 (VT8237S)
device 1106:3287 (VT8251) device 1106:3287 (VT8251)
device 1106:8324 (CX700) device 1106:8324 (CX700)
......
About the PCF8575 chip and the pcf8575 kernel driver
====================================================
The PCF8575 chip is produced by the following manufacturers:
* Philips NXP
http://www.nxp.com/#/pip/cb=[type=product,path=50807/41735/41850,final=PCF8575_3]|pip=[pip=PCF8575_3][0]
* Texas Instruments
http://focus.ti.com/docs/prod/folders/print/pcf8575.html
Some vendors sell small PCB's with the PCF8575 mounted on it. You can connect
such a board to a Linux host via e.g. an USB to I2C interface. Examples of
PCB boards with a PCF8575:
* SFE Breakout Board for PCF8575 I2C Expander by RobotShop
http://www.robotshop.ca/home/products/robot-parts/electronics/adapters-converters/sfe-pcf8575-i2c-expander-board.html
* Breakout Board for PCF8575 I2C Expander by Spark Fun Electronics
http://www.sparkfun.com/commerce/product_info.php?products_id=8130
Description
-----------
The PCF8575 chip is a 16-bit I/O expander for the I2C bus. Up to eight of
these chips can be connected to the same I2C bus. You can find this
chip on some custom designed hardware, but you won't find it on PC
motherboards.
The PCF8575 chip consists of a 16-bit quasi-bidirectional port and an I2C-bus
interface. Each of the sixteen I/O's can be independently used as an input or
an output. To set up an I/O pin as an input, you have to write a 1 to the
corresponding output.
For more information please see the datasheet.
Detection
---------
There is no method known to detect whether a chip on a given I2C address is
a PCF8575 or whether it is any other I2C device. So there are two alternatives
to let the driver find the installed PCF8575 devices:
- Load this driver after any other I2C driver for I2C devices with addresses
in the range 0x20 .. 0x27.
- Pass the I2C bus and address of the installed PCF8575 devices explicitly to
the driver at load time via the probe=... or force=... parameters.
/sys interface
--------------
For each address on which a PCF8575 chip was found or forced the following
files will be created under /sys:
* /sys/bus/i2c/devices/<bus>-<address>/read
* /sys/bus/i2c/devices/<bus>-<address>/write
where bus is the I2C bus number (0, 1, ...) and address is the four-digit
hexadecimal representation of the 7-bit I2C address of the PCF8575
(0020 .. 0027).
The read file is read-only. Reading it will trigger an I2C read and will hence
report the current input state for the pins configured as inputs, and the
current output value for the pins configured as outputs.
The write file is read-write. Writing a value to it will configure all pins
as output for which the corresponding bit is zero. Reading the write file will
return the value last written, or -EAGAIN if no value has yet been written to
the write file.
On module initialization the configuration of the chip is not changed -- the
chip is left in the state it was already configured in through either power-up
or through previous I2C write actions.
...@@ -25,6 +25,9 @@ The typical use-case is like this: ...@@ -25,6 +25,9 @@ The typical use-case is like this:
3. load the target sensors chip driver module 3. load the target sensors chip driver module
4. observe its behavior in the kernel log 4. observe its behavior in the kernel log
There's a script named i2c-stub-from-dump in the i2c-tools package which
can load register values automatically from a chip dump.
PARAMETERS: PARAMETERS:
int chip_addr[10]: int chip_addr[10]:
...@@ -32,9 +35,6 @@ int chip_addr[10]: ...@@ -32,9 +35,6 @@ int chip_addr[10]:
CAVEATS: CAVEATS:
There are independent arrays for byte/data and word/data commands. Depending
on if/how a target driver mixes them, you'll need to be careful.
If your target driver polls some byte or word waiting for it to change, the If your target driver polls some byte or word waiting for it to change, the
stub could lock it up. Use i2cset to unlock it. stub could lock it up. Use i2cset to unlock it.
......
...@@ -267,9 +267,9 @@ insmod parameter of the form force_<kind>. ...@@ -267,9 +267,9 @@ insmod parameter of the form force_<kind>.
Fortunately, as a module writer, you just have to define the `normal_i2c' Fortunately, as a module writer, you just have to define the `normal_i2c'
parameter. The complete declaration could look like this: parameter. The complete declaration could look like this:
/* Scan 0x37, and 0x48 to 0x4f */ /* Scan 0x4c to 0x4f */
static unsigned short normal_i2c[] = { 0x37, 0x48, 0x49, 0x4a, 0x4b, 0x4c, static const unsigned short normal_i2c[] = { 0x4c, 0x4d, 0x4e, 0x4f,
0x4d, 0x4e, 0x4f, I2C_CLIENT_END }; I2C_CLIENT_END };
/* Magic definition of all other variables and things */ /* Magic definition of all other variables and things */
I2C_CLIENT_INSMOD; I2C_CLIENT_INSMOD;
......
...@@ -30,7 +30,7 @@ ...@@ -30,7 +30,7 @@
*** ***
*** The CMD640 is also used on some Vesa Local Bus (VLB) cards, and is *NOT* *** The CMD640 is also used on some Vesa Local Bus (VLB) cards, and is *NOT*
*** automatically detected by Linux. For safe, reliable operation with such *** automatically detected by Linux. For safe, reliable operation with such
*** interfaces, one *MUST* use the "ide0=cmd640_vlb" kernel option. *** interfaces, one *MUST* use the "cmd640.probe_vlb" kernel option.
*** ***
*** Use of the "serialize" option is no longer necessary. *** Use of the "serialize" option is no longer necessary.
...@@ -244,10 +244,6 @@ Summary of ide driver parameters for kernel command line ...@@ -244,10 +244,6 @@ Summary of ide driver parameters for kernel command line
"hdx=nodma" : disallow DMA "hdx=nodma" : disallow DMA
"hdx=swapdata" : when the drive is a disk, byte swap all data
"hdx=bswap" : same as above..........
"hdx=scsi" : the return of the ide-scsi flag, this is useful for "hdx=scsi" : the return of the ide-scsi flag, this is useful for
allowing ide-floppy, ide-tape, and ide-cdrom|writers allowing ide-floppy, ide-tape, and ide-cdrom|writers
to use ide-scsi emulation on a device specific option. to use ide-scsi emulation on a device specific option.
...@@ -292,9 +288,6 @@ The following are valid ONLY on ide0, which usually corresponds ...@@ -292,9 +288,6 @@ The following are valid ONLY on ide0, which usually corresponds
to the first ATA interface found on the particular host, and the defaults for to the first ATA interface found on the particular host, and the defaults for
the base,ctl ports must not be altered. the base,ctl ports must not be altered.
"ide0=cmd640_vlb" : *REQUIRED* for VLB cards with the CMD640 chip
(not for PCI -- automatically detected)
"ide=doubler" : probe/support IDE doublers on Amiga "ide=doubler" : probe/support IDE doublers on Amiga
There may be more options than shown -- use the source, Luke! There may be more options than shown -- use the source, Luke!
...@@ -310,6 +303,10 @@ i.e. to enable probing for ALI M14xx chipsets (ali14xx host driver) use: ...@@ -310,6 +303,10 @@ i.e. to enable probing for ALI M14xx chipsets (ali14xx host driver) use:
* "probe" module parameter when ali14xx driver is compiled as module * "probe" module parameter when ali14xx driver is compiled as module
("modprobe ali14xx probe") ("modprobe ali14xx probe")
Also for legacy CMD640 host driver (cmd640) you need to use "probe_vlb"
kernel paremeter to enable probing for VLB version of the chipset (PCI ones
are detected automatically).
================================================================================ ================================================================================
IDE ATAPI streaming tape driver IDE ATAPI streaming tape driver
......
...@@ -138,6 +138,7 @@ Code Seq# Include File Comments ...@@ -138,6 +138,7 @@ Code Seq# Include File Comments
'm' 00-1F net/irda/irmod.h conflict! 'm' 00-1F net/irda/irmod.h conflict!
'n' 00-7F linux/ncp_fs.h 'n' 00-7F linux/ncp_fs.h
'n' E0-FF video/matrox.h matroxfb 'n' E0-FF video/matrox.h matroxfb
'o' 00-1F fs/ocfs2/ocfs2_fs.h OCFS2
'p' 00-0F linux/phantom.h conflict! (OpenHaptics needs this) 'p' 00-0F linux/phantom.h conflict! (OpenHaptics needs this)
'p' 00-3F linux/mc146818rtc.h conflict! 'p' 00-3F linux/mc146818rtc.h conflict!
'p' 40-7F linux/nvram.h 'p' 40-7F linux/nvram.h
......
...@@ -24,7 +24,7 @@ visible if its parent entry is also visible. ...@@ -24,7 +24,7 @@ visible if its parent entry is also visible.
Menu entries Menu entries
------------ ------------
Most entries define a config option, all other entries help to organize Most entries define a config option; all other entries help to organize
them. A single configuration option is defined like this: them. A single configuration option is defined like this:
config MODVERSIONS config MODVERSIONS
...@@ -50,7 +50,7 @@ applicable everywhere (see syntax). ...@@ -50,7 +50,7 @@ applicable everywhere (see syntax).
- type definition: "bool"/"tristate"/"string"/"hex"/"int" - type definition: "bool"/"tristate"/"string"/"hex"/"int"
Every config option must have a type. There are only two basic types: Every config option must have a type. There are only two basic types:
tristate and string, the other types are based on these two. The type tristate and string; the other types are based on these two. The type
definition optionally accepts an input prompt, so these two examples definition optionally accepts an input prompt, so these two examples
are equivalent: are equivalent:
...@@ -108,7 +108,7 @@ applicable everywhere (see syntax). ...@@ -108,7 +108,7 @@ applicable everywhere (see syntax).
equal to 'y' without visiting the dependencies. So abusing equal to 'y' without visiting the dependencies. So abusing
select you are able to select a symbol FOO even if FOO depends select you are able to select a symbol FOO even if FOO depends
on BAR that is not set. In general use select only for on BAR that is not set. In general use select only for
non-visible symbols (no promts anywhere) and for symbols with non-visible symbols (no prompts anywhere) and for symbols with
no dependencies. That will limit the usefulness but on the no dependencies. That will limit the usefulness but on the
other hand avoid the illegal configurations all over. kconfig other hand avoid the illegal configurations all over. kconfig
should one day warn about such things. should one day warn about such things.
...@@ -127,6 +127,27 @@ applicable everywhere (see syntax). ...@@ -127,6 +127,27 @@ applicable everywhere (see syntax).
used to help visually separate 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.
- misc options: "option" <symbol>[=<value>]
Various less common options can be defined via this option syntax,
which can modify the behaviour of the menu entry and its config
symbol. These options are currently possible:
- "defconfig_list"
This declares a list of default entries which can be used when
looking for the default configuration (which is used when the main
.config doesn't exists yet.)
- "modules"
This declares the symbol to be used as the MODULES symbol, which
enables the third modular state for all config symbols.
- "env"=<value>
This imports the environment variable into Kconfig. It behaves like
a default, except that the value comes from the environment, this
also means that the behaviour when mixing it with normal defaults is
undefined at this point. The symbol is currently not exported back
to the build environment (if this is desired, it can be done via
another symbol).
Menu dependencies Menu dependencies
----------------- -----------------
...@@ -162,9 +183,9 @@ An expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2 ...@@ -162,9 +183,9 @@ An expression can have a value of 'n', 'm' or 'y' (or 0, 1, 2
respectively for calculations). A menu entry becomes visible when it's respectively for calculations). A menu entry becomes visible when it's
expression evaluates to 'm' or 'y'. expression evaluates to 'm' or 'y'.
There are two types of symbols: constant and nonconstant symbols. There are two types of symbols: constant and non-constant symbols.
Nonconstant symbols are the most common ones and are defined with the Non-constant symbols are the most common ones and are defined with the
'config' statement. Nonconstant symbols consist entirely of alphanumeric 'config' statement. Non-constant symbols consist entirely of alphanumeric
characters or underscores. characters or underscores.
Constant symbols are only part of expressions. Constant symbols are Constant symbols are only part of expressions. Constant symbols are
always surrounded by single or double quotes. Within the quote, any always surrounded by single or double quotes. Within the quote, any
...@@ -301,3 +322,81 @@ mainmenu: ...@@ -301,3 +322,81 @@ mainmenu:
This sets the config program's title bar if the config program chooses This sets the config program's title bar if the config program chooses
to use it. to use it.
Kconfig hints
-------------
This is a collection of Kconfig tips, most of which aren't obvious at
first glance and most of which have become idioms in several Kconfig
files.
Adding common features and make the usage configurable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is a common idiom to implement a feature/functionality that are
relevant for some architectures but not all.
The recommended way to do so is to use a config variable named HAVE_*
that is defined in a common Kconfig file and selected by the relevant
architectures.
An example is the generic IOMAP functionality.
We would in lib/Kconfig see:
# Generic IOMAP is used to ...
config HAVE_GENERIC_IOMAP
config GENERIC_IOMAP
depends on HAVE_GENERIC_IOMAP && FOO
And in lib/Makefile we would see:
obj-$(CONFIG_GENERIC_IOMAP) += iomap.o
For each architecture using the generic IOMAP functionality we would see:
config X86
select ...
select HAVE_GENERIC_IOMAP
select ...
Note: we use the existing config option and avoid creating a new
config variable to select HAVE_GENERIC_IOMAP.
Note: the use of the internal config variable HAVE_GENERIC_IOMAP, it is
introduced to overcome the limitation of select which will force a
config option to 'y' no matter the dependencies.
The dependencies are moved to the symbol GENERIC_IOMAP and we avoid the
situation where select forces a symbol equals to 'y'.
Build as module only
~~~~~~~~~~~~~~~~~~~~
To restrict a component build to module-only, qualify its config symbol
with "depends on m". E.g.:
config FOO
depends on BAR && m
limits FOO to module (=m) or disabled (=n).
Build limited by a third config symbol which may be =y or =m
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A common idiom that we see (and sometimes have problems with) is this:
When option C in B (module or subsystem) uses interfaces from A (module
or subsystem), and both A and B are tristate (could be =y or =m if they
were independent of each other, but they aren't), then we need to limit
C such that it cannot be built statically if A is built as a loadable
module. (C already depends on B, so there is no dependency issue to
take care of here.)
If A is linked statically into the kernel image, C can be built
statically or as loadable module(s). However, if A is built as loadable
module(s), then C must be restricted to loadable module(s) also. This
can be expressed in kconfig language as:
config C
depends on A = y || A = B
or for real examples, use this command in a kernel tree:
$ find . -name Kconfig\* | xargs grep -ns "depends on.*=.*||.*=" | grep -v orig
...@@ -34,6 +34,7 @@ parameter is applicable: ...@@ -34,6 +34,7 @@ parameter is applicable:
ALSA ALSA sound support is enabled. ALSA ALSA sound support is enabled.
APIC APIC support is enabled. APIC APIC support is enabled.
APM Advanced Power Management support is enabled. APM Advanced Power Management support is enabled.
AVR32 AVR32 architecture is enabled.
AX25 Appropriate AX.25 support is enabled. AX25 Appropriate AX.25 support is enabled.
BLACKFIN Blackfin architecture is enabled. BLACKFIN Blackfin architecture is enabled.
DRM Direct Rendering Management support is enabled. DRM Direct Rendering Management support is enabled.
...@@ -369,7 +370,8 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -369,7 +370,8 @@ and is between 256 and 4096 characters. It is defined in the file
configured. Potentially dangerous and should only be configured. Potentially dangerous and should only be
used if you are entirely sure of the consequences. used if you are entirely sure of the consequences.
chandev= [HW,NET] Generic channel device initialisation ccw_timeout_log [S390]
See Documentation/s390/CommonIO for details.
checkreqprot [SELINUX] Set initial checkreqprot flag value. checkreqprot [SELINUX] Set initial checkreqprot flag value.
Format: { "0" | "1" } Format: { "0" | "1" }
...@@ -381,6 +383,12 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -381,6 +383,12 @@ and is between 256 and 4096 characters. It is defined in the file
Value can be changed at runtime via Value can be changed at runtime via
/selinux/checkreqprot. /selinux/checkreqprot.
cio_ignore= [S390]
See Documentation/s390/CommonIO for details.
cio_msg= [S390]
See Documentation/s390/CommonIO for details.
clock= [BUGS=X86-32, HW] gettimeofday clocksource override. clock= [BUGS=X86-32, HW] gettimeofday clocksource override.
[Deprecated] [Deprecated]
Forces specified clocksource (if available) to be used Forces specified clocksource (if available) to be used
...@@ -408,8 +416,21 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -408,8 +416,21 @@ and is between 256 and 4096 characters. It is defined in the file
[SPARC64] tick [SPARC64] tick
[X86-64] hpet,tsc [X86-64] hpet,tsc
code_bytes [IA32] How many bytes of object code to print in an clearcpuid=BITNUM [X86]
oops report. Disable CPUID feature X for the kernel. See
include/asm-x86/cpufeature.h for the valid bit numbers.
Note the Linux specific bits are not necessarily
stable over kernel options, but the vendor specific
ones should be.
Also note that user programs calling CPUID directly
or using the feature without checking anything
will still see it. This just prevents it from
being used by the kernel or shown in /proc/cpuinfo.
Also note the kernel might malfunction if you disable
some critical bits.
code_bytes [IA32/X86_64] How many bytes of object code to print
in an oops report.
Range: 0 - 8192 Range: 0 - 8192
Default: 64 Default: 64
...@@ -562,6 +583,12 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -562,6 +583,12 @@ and is between 256 and 4096 characters. It is defined in the file
See drivers/char/README.epca and See drivers/char/README.epca and
Documentation/digiepca.txt. Documentation/digiepca.txt.
disable_mtrr_trim [X86, Intel and AMD only]
By default the kernel will trim any uncacheable
memory out of your available memory pool based on
MTRR settings. This parameter disables that behavior,
possibly causing your machine to run very slowly.
dmasound= [HW,OSS] Sound subsystem buffers dmasound= [HW,OSS] Sound subsystem buffers
dscc4.setup= [NET] dscc4.setup= [NET]
...@@ -652,6 +679,10 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -652,6 +679,10 @@ and is between 256 and 4096 characters. It is defined in the file
gamma= [HW,DRM] gamma= [HW,DRM]
gart_fix_e820= [X86_64] disable the fix e820 for K8 GART
Format: off | on
default: on
gdth= [HW,SCSI] gdth= [HW,SCSI]
See header of drivers/scsi/gdth.c. See header of drivers/scsi/gdth.c.
...@@ -787,6 +818,16 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -787,6 +818,16 @@ and is between 256 and 4096 characters. It is defined in the file
for translation below 32 bit and if not available for translation below 32 bit and if not available
then look in the higher range. then look in the higher range.
io_delay= [X86-32,X86-64] I/O delay method
0x80
Standard port 0x80 based delay
0xed
Alternate port 0xed based delay (needed on some systems)
udelay
Simple two microseconds delay
none
No delay
io7= [HW] IO7 for Marvel based alpha systems io7= [HW] IO7 for Marvel based alpha systems
See comment before marvel_specify_io7 in See comment before marvel_specify_io7 in
arch/alpha/kernel/core_marvel.c. arch/alpha/kernel/core_marvel.c.
...@@ -1052,6 +1093,11 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -1052,6 +1093,11 @@ and is between 256 and 4096 characters. It is defined in the file
Multi-Function General Purpose Timers on AMD Geode Multi-Function General Purpose Timers on AMD Geode
platforms. platforms.
mfgptfix [X86-32] Fix MFGPT timers on AMD Geode platforms when
the BIOS has incorrectly applied a workaround. TinyBIOS
version 0.98 is known to be affected, 0.99 fixes the
problem by letting the user disable the workaround.
mga= [HW,DRM] mga= [HW,DRM]
mousedev.tap_time= mousedev.tap_time=
...@@ -1124,6 +1170,10 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -1124,6 +1170,10 @@ and is between 256 and 4096 characters. It is defined in the file
of returning the full 64-bit number. of returning the full 64-bit number.
The default is to return 64-bit inode numbers. The default is to return 64-bit inode numbers.
nmi_debug= [KNL,AVR32] Specify one or more actions to take
when a NMI is triggered.
Format: [state][,regs][,debounce][,die]
nmi_watchdog= [KNL,BUGS=X86-32] Debugging features for SMP kernels nmi_watchdog= [KNL,BUGS=X86-32] Debugging features for SMP kernels
no387 [BUGS=X86-32] Tells the kernel to use the 387 maths no387 [BUGS=X86-32] Tells the kernel to use the 387 maths
...@@ -1148,6 +1198,8 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -1148,6 +1198,8 @@ and is between 256 and 4096 characters. It is defined in the file
nodisconnect [HW,SCSI,M68K] Disables SCSI disconnects. nodisconnect [HW,SCSI,M68K] Disables SCSI disconnects.
noefi [X86-32,X86-64] Disable EFI runtime services support.
noexec [IA-64] noexec [IA-64]
noexec [X86-32,X86-64] noexec [X86-32,X86-64]
...@@ -1158,6 +1210,8 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -1158,6 +1210,8 @@ and is between 256 and 4096 characters. It is defined in the file
register save and restore. The kernel will only save register save and restore. The kernel will only save
legacy floating-point registers on task switch. legacy floating-point registers on task switch.
noclflush [BUGS=X86] Don't use the CLFLUSH instruction
nohlt [BUGS=ARM] nohlt [BUGS=ARM]
no-hlt [BUGS=X86-32] Tells the kernel that the hlt no-hlt [BUGS=X86-32] Tells the kernel that the hlt
...@@ -1594,7 +1648,13 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -1594,7 +1648,13 @@ and is between 256 and 4096 characters. It is defined in the file
Format: <vendor>:<model>:<flags> Format: <vendor>:<model>:<flags>
(flags are integer value) (flags are integer value)
scsi_logging= [SCSI] scsi_logging_level= [SCSI] a bit mask of logging levels
See drivers/scsi/scsi_logging.h for bits. Also
settable via sysctl at dev.scsi.logging_level
(/proc/sys/dev/scsi/logging_level).
There is also a nice 'scsi_logging_level' script in the
S390-tools package, available for download at
http://www-128.ibm.com/developerworks/linux/linux390/s390-tools-1.5.4.html
scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they are scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they are
discovered. async scans them in kernel threads, discovered. async scans them in kernel threads,
...@@ -1961,6 +2021,11 @@ and is between 256 and 4096 characters. It is defined in the file ...@@ -1961,6 +2021,11 @@ and is between 256 and 4096 characters. It is defined in the file
vdso=1: enable VDSO (default) vdso=1: enable VDSO (default)
vdso=0: disable VDSO mapping vdso=0: disable VDSO mapping
vdso32= [X86-32,X86-64]
vdso32=2: enable compat VDSO (default with COMPAT_VDSO)
vdso32=1: enable 32-bit VDSO (default)
vdso32=0: disable 32-bit VDSO mapping
vector= [IA-64,SMP] vector= [IA-64,SMP]
vector=percpu: enable percpu vector domain vector=percpu: enable percpu vector domain
......
此差异已折叠。
...@@ -141,6 +141,7 @@ architectures: ...@@ -141,6 +141,7 @@ architectures:
- ppc64 - ppc64
- ia64 (Does not support probes on instruction slot1.) - ia64 (Does not support probes on instruction slot1.)
- sparc64 (Return probes not yet implemented.) - sparc64 (Return probes not yet implemented.)
- arm
3. Configuring Kprobes 3. Configuring Kprobes
......
...@@ -79,6 +79,9 @@ static void *guest_base; ...@@ -79,6 +79,9 @@ static void *guest_base;
/* The maximum guest physical address allowed, and maximum possible. */ /* The maximum guest physical address allowed, and maximum possible. */
static unsigned long guest_limit, guest_max; static unsigned long guest_limit, guest_max;
/* a per-cpu variable indicating whose vcpu is currently running */
static unsigned int __thread cpu_id;
/* This is our list of devices. */ /* This is our list of devices. */
struct device_list struct device_list
{ {
...@@ -153,6 +156,9 @@ struct virtqueue ...@@ -153,6 +156,9 @@ struct virtqueue
void (*handle_output)(int fd, struct virtqueue *me); void (*handle_output)(int fd, struct virtqueue *me);
}; };
/* Remember the arguments to the program so we can "reboot" */
static char **main_args;
/* Since guest is UP and we don't run at the same time, we don't need barriers. /* Since guest is UP and we don't run at the same time, we don't need barriers.
* But I include them in the code in case others copy it. */ * But I include them in the code in case others copy it. */
#define wmb() #define wmb()
...@@ -554,7 +560,7 @@ static void wake_parent(int pipefd, int lguest_fd) ...@@ -554,7 +560,7 @@ static void wake_parent(int pipefd, int lguest_fd)
else else
FD_CLR(-fd - 1, &devices.infds); FD_CLR(-fd - 1, &devices.infds);
} else /* Send LHREQ_BREAK command. */ } else /* Send LHREQ_BREAK command. */
write(lguest_fd, args, sizeof(args)); pwrite(lguest_fd, args, sizeof(args), cpu_id);
} }
} }
...@@ -1489,7 +1495,9 @@ static void setup_block_file(const char *filename) ...@@ -1489,7 +1495,9 @@ static void setup_block_file(const char *filename)
/* Create stack for thread and run it */ /* Create stack for thread and run it */
stack = malloc(32768); stack = malloc(32768);
if (clone(io_thread, stack + 32768, CLONE_VM, dev) == -1) /* SIGCHLD - We dont "wait" for our cloned thread, so prevent it from
* becoming a zombie. */
if (clone(io_thread, stack + 32768, CLONE_VM | SIGCHLD, dev) == -1)
err(1, "Creating clone"); err(1, "Creating clone");
/* We don't need to keep the I/O thread's end of the pipes open. */ /* We don't need to keep the I/O thread's end of the pipes open. */
...@@ -1499,7 +1507,21 @@ static void setup_block_file(const char *filename) ...@@ -1499,7 +1507,21 @@ static void setup_block_file(const char *filename)
verbose("device %u: virtblock %llu sectors\n", verbose("device %u: virtblock %llu sectors\n",
devices.device_num, cap); devices.device_num, cap);
} }
/* That's the end of device setup. */ /* That's the end of device setup. :*/
/* Reboot */
static void __attribute__((noreturn)) restart_guest(void)
{
unsigned int i;
/* Closing pipes causes the waker thread and io_threads to die, and
* closing /dev/lguest cleans up the Guest. Since we don't track all
* open fds, we simply close everything beyond stderr. */
for (i = 3; i < FD_SETSIZE; i++)
close(i);
execv(main_args[0], main_args);
err(1, "Could not exec %s", main_args[0]);
}
/*L:220 Finally we reach the core of the Launcher, which runs the Guest, serves /*L:220 Finally we reach the core of the Launcher, which runs the Guest, serves
* its input and output, and finally, lays it to rest. */ * its input and output, and finally, lays it to rest. */
...@@ -1511,7 +1533,8 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd) ...@@ -1511,7 +1533,8 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd)
int readval; int readval;
/* We read from the /dev/lguest device to run the Guest. */ /* We read from the /dev/lguest device to run the Guest. */
readval = read(lguest_fd, &notify_addr, sizeof(notify_addr)); readval = pread(lguest_fd, &notify_addr,
sizeof(notify_addr), cpu_id);
/* One unsigned long means the Guest did HCALL_NOTIFY */ /* One unsigned long means the Guest did HCALL_NOTIFY */
if (readval == sizeof(notify_addr)) { if (readval == sizeof(notify_addr)) {
...@@ -1521,16 +1544,23 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd) ...@@ -1521,16 +1544,23 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd)
/* ENOENT means the Guest died. Reading tells us why. */ /* ENOENT means the Guest died. Reading tells us why. */
} else if (errno == ENOENT) { } else if (errno == ENOENT) {
char reason[1024] = { 0 }; char reason[1024] = { 0 };
read(lguest_fd, reason, sizeof(reason)-1); pread(lguest_fd, reason, sizeof(reason)-1, cpu_id);
errx(1, "%s", reason); errx(1, "%s", reason);
/* ERESTART means that we need to reboot the guest */
} else if (errno == ERESTART) {
restart_guest();
/* EAGAIN means the Waker wanted us to look at some input. /* EAGAIN means the Waker wanted us to look at some input.
* Anything else means a bug or incompatible change. */ * Anything else means a bug or incompatible change. */
} else if (errno != EAGAIN) } else if (errno != EAGAIN)
err(1, "Running guest failed"); err(1, "Running guest failed");
/* Only service input on thread for CPU 0. */
if (cpu_id != 0)
continue;
/* Service input, then unset the BREAK to release the Waker. */ /* Service input, then unset the BREAK to release the Waker. */
handle_input(lguest_fd); handle_input(lguest_fd);
if (write(lguest_fd, args, sizeof(args)) < 0) if (pwrite(lguest_fd, args, sizeof(args), cpu_id) < 0)
err(1, "Resetting break"); err(1, "Resetting break");
} }
} }
...@@ -1571,6 +1601,12 @@ int main(int argc, char *argv[]) ...@@ -1571,6 +1601,12 @@ int main(int argc, char *argv[])
/* If they specify an initrd file to load. */ /* If they specify an initrd file to load. */
const char *initrd_name = NULL; const char *initrd_name = NULL;
/* Save the args: we "reboot" by execing ourselves again. */
main_args = argv;
/* We don't "wait" for the children, so prevent them from becoming
* zombies. */
signal(SIGCHLD, SIG_IGN);
/* First we initialize the device list. Since console and network /* First we initialize the device list. Since console and network
* device receive input from a file descriptor, we keep an fdset * device receive input from a file descriptor, we keep an fdset
* (infds) and the maximum fd number (max_infd) with the head of the * (infds) and the maximum fd number (max_infd) with the head of the
...@@ -1582,6 +1618,7 @@ int main(int argc, char *argv[]) ...@@ -1582,6 +1618,7 @@ int main(int argc, char *argv[])
devices.lastdev = &devices.dev; devices.lastdev = &devices.dev;
devices.next_irq = 1; devices.next_irq = 1;
cpu_id = 0;
/* We need to know how much memory so we can set up the device /* We need to know how much memory so we can set up the device
* descriptor and memory pages for the devices as we parse the command * descriptor and memory pages for the devices as we parse the command
* line. So we quickly look through the arguments to find the amount * line. So we quickly look through the arguments to find the amount
......
...@@ -867,66 +867,6 @@ controller and should be autodetected by the driver. An example is the ...@@ -867,66 +867,6 @@ controller and should be autodetected by the driver. An example is the
24 bit region which is specified by a mask of 0x00fffffe. 24 bit region which is specified by a mask of 0x00fffffe.
5.5) 53c7xx=
------------
Syntax: 53c7xx=<sub-options...>
These options affect the A4000T, A4091, WarpEngine, Blizzard 603e+,
and GForce 040/060 SCSI controllers on the Amiga, as well as the
builtin MVME 16x SCSI controller.
The <sub-options> is a comma-separated list of the sub-options listed
below.
5.5.1) nosync
-------------
Syntax: nosync:0
Disables sync negotiation for all devices. Any value after the
colon is acceptable (and has the same effect).
5.5.2) noasync
--------------
[OBSOLETE, REMOVED]
5.5.3) nodisconnect
-------------------
Syntax: nodisconnect:0
Disables SCSI disconnects. Any value after the colon is acceptable
(and has the same effect).
5.5.4) validids
---------------
Syntax: validids:0xNN
Specify which SCSI ids the driver should pay attention to. This is
a bitmask (i.e. to only pay attention to ID#4, you'd use 0x10).
Default is 0x7f (devices 0-6).
5.5.5) opthi
5.5.6) optlo
------------
Syntax: opthi:M,optlo:N
Specify options for "hostdata->options". The acceptable definitions
are listed in drivers/scsi/53c7xx.h; the 32 high bits should be in
opthi and the 32 low bits in optlo. They must be specified in the
order opthi=M,optlo=N.
5.5.7) next
-----------
No argument. Used to separate blocks of keywords when there's more
than one 53c7xx host adapter in the system.
/* Local Variables: */ /* Local Variables: */
/* mode: text */ /* mode: text */
/* End: */ /* End: */
...@@ -2,5 +2,3 @@ ...@@ -2,5 +2,3 @@
- this file. - this file.
AU1xxx_IDE.README AU1xxx_IDE.README
- README for MIPS AU1XXX IDE driver. - README for MIPS AU1XXX IDE driver.
GT64120.README
- README for dir with info on MIPS boards using GT-64120 or GT-64120A.
README for arch/mips/gt64120 directory and subdirectories
Jun Sun, jsun@mvista.com or jsun@junsun.net
01/27, 2001
MOTIVATION
----------
Many MIPS boards share the same system controller (or CPU companian chip),
such as GT-64120. It is highly desirable to let these boards share
the same controller code instead of duplicating them.
This directory is meant to hold all MIPS boards that use GT-64120 or GT-64120A.
HOW TO ADD A BOARD
------------------
. Create a subdirectory include/asm/gt64120/<board>.
. Create a file called gt64120_dep.h under that directory.
. Modify include/asm/gt64120/gt64120.h file to include the new gt64120_dep.h
based on config options. The board-dep section is at the end of
include/asm/gt64120/gt64120.h file. There you can find all required
definitions include/asm/gt64120/<board>/gt64120_dep.h file must supply.
. Create a subdirectory arch/mips/gt64120/<board> directory to hold
board specific routines.
. The GT-64120 common code is supplied under arch/mips/gt64120/common directory.
It includes:
1) arch/mips/gt64120/pci.c -
common PCI routine, include the top-level pcibios_init()
2) arch/mips/gt64120/irq.c -
common IRQ routine, include the top-level do_IRQ()
[This part really belongs to arch/mips/kernel. jsun]
3) arch/mips/gt64120/gt_irq.c -
common IRQ routines for GT-64120 chip. Currently it only handles
the timer interrupt.
. Board-specific routines are supplied under arch/mips/gt64120/<board> dir.
1) arch/mips/gt64120/<board>/pci.c - it provides bus fixup routine
2) arch/mips/gt64120/<board>/irq.c - it provides enable/disable irqs
and board irq setup routine (irq_setup)
3) arch/mips/gt64120/<board>/int-handler.S -
The first-level interrupt dispatching routine.
4) a bunch of other "normal" stuff (setup, prom, dbg_io, reset, etc)
. Follow other "normal" procedure to modify configuration files, etc.
TO-DO LIST
----------
. Expand arch/mips/gt64120/gt_irq.c to handle all GT-64120 interrupts.
We probably need to introduce GT_IRQ_BASE in board-dep header file,
which is used the starting irq_nr for all GT irqs.
A function, gt64120_handle_irq(), will be added so that the first-level
irq dispatcher will call this function if it detects an interrupt
from GT-64120.
. More support for GT-64120 PCI features (2nd PCI bus, perhaps)
...@@ -24,6 +24,8 @@ baycom.txt ...@@ -24,6 +24,8 @@ baycom.txt
- info on the driver for Baycom style amateur radio modems - info on the driver for Baycom style amateur radio modems
bridge.txt bridge.txt
- where to get user space programs for ethernet bridging with Linux. - where to get user space programs for ethernet bridging with Linux.
can.txt
- documentation on CAN protocol family.
cops.txt cops.txt
- info on the COPS LocalTalk Linux driver - info on the COPS LocalTalk Linux driver
cs89x0.txt cs89x0.txt
...@@ -82,8 +84,6 @@ policy-routing.txt ...@@ -82,8 +84,6 @@ policy-routing.txt
- IP policy-based routing - IP policy-based routing
ray_cs.txt ray_cs.txt
- Raylink Wireless LAN card driver info. - Raylink Wireless LAN card driver info.
shaper.txt
- info on the module that can shape/limit transmitted traffic.
sk98lin.txt sk98lin.txt
- Marvell Yukon Chipset / SysKonnect SK-98xx compliant Gigabit - Marvell Yukon Chipset / SysKonnect SK-98xx compliant Gigabit
Ethernet Adapter family driver info Ethernet Adapter family driver info
......
Linux Ethernet Bonding Driver HOWTO Linux Ethernet Bonding Driver HOWTO
Latest update: 24 April 2006 Latest update: 12 November 2007
Initial release : Thomas Davis <tadavis at lbl.gov> Initial release : Thomas Davis <tadavis at lbl.gov>
Corrections, HA extensions : 2000/10/03-15 : Corrections, HA extensions : 2000/10/03-15 :
...@@ -166,12 +166,17 @@ to use ifenslave. ...@@ -166,12 +166,17 @@ to use ifenslave.
2. Bonding Driver Options 2. Bonding Driver Options
========================= =========================
Options for the bonding driver are supplied as parameters to Options for the bonding driver are supplied as parameters to the
the bonding module at load time. They may be given as command line bonding module at load time, or are specified via sysfs.
arguments to the insmod or modprobe command, but are usually specified
in either the /etc/modules.conf or /etc/modprobe.conf configuration Module options may be given as command line arguments to the
file, or in a distro-specific configuration file (some of which are insmod or modprobe command, but are usually specified in either the
detailed in the next section). /etc/modules.conf or /etc/modprobe.conf configuration file, or in a
distro-specific configuration file (some of which are detailed in the next
section).
Details on bonding support for sysfs is provided in the
"Configuring Bonding Manually via Sysfs" section, below.
The available bonding driver parameters are listed below. If a The available bonding driver parameters are listed below. If a
parameter is not specified the default value is used. When initially parameter is not specified the default value is used. When initially
...@@ -812,11 +817,13 @@ the system /etc/modules.conf or /etc/modprobe.conf configuration file. ...@@ -812,11 +817,13 @@ the system /etc/modules.conf or /etc/modprobe.conf configuration file.
3.2 Configuration with Initscripts Support 3.2 Configuration with Initscripts Support
------------------------------------------ ------------------------------------------
This section applies to distros using a version of initscripts This section applies to distros using a recent version of
with bonding support, for example, Red Hat Linux 9 or Red Hat initscripts with bonding support, for example, Red Hat Enterprise Linux
Enterprise Linux version 3 or 4. On these systems, the network version 3 or later, Fedora, etc. On these systems, the network
initialization scripts have some knowledge of bonding, and can be initialization scripts have knowledge of bonding, and can be configured to
configured to control bonding devices. control bonding devices. Note that older versions of the initscripts
package have lower levels of support for bonding; this will be noted where
applicable.
These distros will not automatically load the network adapter These distros will not automatically load the network adapter
driver unless the ethX device is configured with an IP address. driver unless the ethX device is configured with an IP address.
...@@ -864,11 +871,31 @@ USERCTL=no ...@@ -864,11 +871,31 @@ USERCTL=no
Be sure to change the networking specific lines (IPADDR, Be sure to change the networking specific lines (IPADDR,
NETMASK, NETWORK and BROADCAST) to match your network configuration. NETMASK, NETWORK and BROADCAST) to match your network configuration.
Finally, it is necessary to edit /etc/modules.conf (or For later versions of initscripts, such as that found with Fedora
/etc/modprobe.conf, depending upon your distro) to load the bonding 7 and Red Hat Enterprise Linux version 5 (or later), it is possible, and,
module with your desired options when the bond0 interface is brought indeed, preferable, to specify the bonding options in the ifcfg-bond0
up. The following lines in /etc/modules.conf (or modprobe.conf) will file, e.g. a line of the format:
load the bonding module, and select its options:
BONDING_OPTS="mode=active-backup arp_interval=60 arp_ip_target=+192.168.1.254"
will configure the bond with the specified options. The options
specified in BONDING_OPTS are identical to the bonding module parameters
except for the arp_ip_target field. Each target should be included as a
separate option and should be preceded by a '+' to indicate it should be
added to the list of queried targets, e.g.,
arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2
is the proper syntax to specify multiple targets. When specifying
options via BONDING_OPTS, it is not necessary to edit /etc/modules.conf or
/etc/modprobe.conf.
For older versions of initscripts that do not support
BONDING_OPTS, it is necessary to edit /etc/modules.conf (or
/etc/modprobe.conf, depending upon your distro) to load the bonding module
with your desired options when the bond0 interface is brought up. The
following lines in /etc/modules.conf (or modprobe.conf) will load the
bonding module, and select its options:
alias bond0 bonding alias bond0 bonding
options bond0 mode=balance-alb miimon=100 options bond0 mode=balance-alb miimon=100
...@@ -883,9 +910,10 @@ up and running. ...@@ -883,9 +910,10 @@ up and running.
3.2.1 Using DHCP with Initscripts 3.2.1 Using DHCP with Initscripts
--------------------------------- ---------------------------------
Recent versions of initscripts (the version supplied with Recent versions of initscripts (the versions supplied with Fedora
Fedora Core 3 and Red Hat Enterprise Linux 4 is reported to work) do Core 3 and Red Hat Enterprise Linux 4, or later versions, are reported to
have support for assigning IP information to bonding devices via DHCP. work) have support for assigning IP information to bonding devices via
DHCP.
To configure bonding for DHCP, configure it as described To configure bonding for DHCP, configure it as described
above, except replace the line "BOOTPROTO=none" with "BOOTPROTO=dhcp" above, except replace the line "BOOTPROTO=none" with "BOOTPROTO=dhcp"
...@@ -895,18 +923,14 @@ is case sensitive. ...@@ -895,18 +923,14 @@ is case sensitive.
3.2.2 Configuring Multiple Bonds with Initscripts 3.2.2 Configuring Multiple Bonds with Initscripts
------------------------------------------------- -------------------------------------------------
At this writing, the initscripts package does not directly Initscripts packages that are included with Fedora 7 and Red Hat
support loading the bonding driver multiple times, so the process for Enterprise Linux 5 support multiple bonding interfaces by simply
doing so is the same as described in the "Configuring Multiple Bonds specifying the appropriate BONDING_OPTS= in ifcfg-bondX where X is the
Manually" section, below. number of the bond. This support requires sysfs support in the kernel,
and a bonding driver of version 3.0.0 or later. Other configurations may
NOTE: It has been observed that some Red Hat supplied kernels not support this method for specifying multiple bonding interfaces; for
are apparently unable to rename modules at load time (the "-o bond1" those instances, see the "Configuring Multiple Bonds Manually" section,
part). Attempts to pass that option to modprobe will produce an below.
"Operation not permitted" error. This has been reported on some
Fedora Core kernels, and has been seen on RHEL 4 as well. On kernels
exhibiting this problem, it will be impossible to configure multiple
bonds with differing parameters.
3.3 Configuring Bonding Manually with Ifenslave 3.3 Configuring Bonding Manually with Ifenslave
----------------------------------------------- -----------------------------------------------
...@@ -977,15 +1001,58 @@ initialization scripts lack support for configuring multiple bonds. ...@@ -977,15 +1001,58 @@ initialization scripts lack support for configuring multiple bonds.
options, you may wish to use the "max_bonds" module parameter, options, you may wish to use the "max_bonds" module parameter,
documented above. documented above.
To create multiple bonding devices with differing options, it To create multiple bonding devices with differing options, it is
is necessary to use bonding parameters exported by sysfs, documented preferrable to use bonding parameters exported by sysfs, documented in the
in the section below. section below.
For versions of bonding without sysfs support, the only means to
provide multiple instances of bonding with differing options is to load
the bonding driver multiple times. Note that current versions of the
sysconfig network initialization scripts handle this automatically; if
your distro uses these scripts, no special action is needed. See the
section Configuring Bonding Devices, above, if you're not sure about your
network initialization scripts.
To load multiple instances of the module, it is necessary to
specify a different name for each instance (the module loading system
requires that every loaded module, even multiple instances of the same
module, have a unique name). This is accomplished by supplying multiple
sets of bonding options in /etc/modprobe.conf, for example:
alias bond0 bonding
options bond0 -o bond0 mode=balance-rr miimon=100
alias bond1 bonding
options bond1 -o bond1 mode=balance-alb miimon=50
will load the bonding module two times. The first instance is
named "bond0" and creates the bond0 device in balance-rr mode with an
miimon of 100. The second instance is named "bond1" and creates the
bond1 device in balance-alb mode with an miimon of 50.
In some circumstances (typically with older distributions),
the above does not work, and the second bonding instance never sees
its options. In that case, the second options line can be substituted
as follows:
install bond1 /sbin/modprobe --ignore-install bonding -o bond1 \
mode=balance-alb miimon=50
This may be repeated any number of times, specifying a new and
unique name in place of bond1 for each subsequent instance.
It has been observed that some Red Hat supplied kernels are unable
to rename modules at load time (the "-o bond1" part). Attempts to pass
that option to modprobe will produce an "Operation not permitted" error.
This has been reported on some Fedora Core kernels, and has been seen on
RHEL 4 as well. On kernels exhibiting this problem, it will be impossible
to configure multiple bonds with differing parameters (as they are older
kernels, and also lack sysfs support).
3.4 Configuring Bonding Manually via Sysfs 3.4 Configuring Bonding Manually via Sysfs
------------------------------------------ ------------------------------------------
Starting with version 3.0, Channel Bonding may be configured Starting with version 3.0.0, Channel Bonding may be configured
via the sysfs interface. This interface allows dynamic configuration via the sysfs interface. This interface allows dynamic configuration
of all bonds in the system without unloading the module. It also of all bonds in the system without unloading the module. It also
allows for adding and removing bonds at runtime. Ifenslave is no allows for adding and removing bonds at runtime. Ifenslave is no
...@@ -1030,9 +1097,6 @@ To enslave interface eth0 to bond bond0: ...@@ -1030,9 +1097,6 @@ To enslave interface eth0 to bond bond0:
To free slave eth0 from bond bond0: To free slave eth0 from bond bond0:
# echo -eth0 > /sys/class/net/bond0/bonding/slaves # echo -eth0 > /sys/class/net/bond0/bonding/slaves
NOTE: The bond must be up before slaves can be added. All
slaves are freed when the interface is brought down.
When an interface is enslaved to a bond, symlinks between the When an interface is enslaved to a bond, symlinks between the
two are created in the sysfs filesystem. In this case, you would get two are created in the sysfs filesystem. In this case, you would get
/sys/class/net/bond0/slave_eth0 pointing to /sys/class/net/eth0, and /sys/class/net/bond0/slave_eth0 pointing to /sys/class/net/eth0, and
...@@ -1622,6 +1686,15 @@ one for each switch in the network). This will insure that, ...@@ -1622,6 +1686,15 @@ one for each switch in the network). This will insure that,
regardless of which switch is active, the ARP monitor has a suitable regardless of which switch is active, the ARP monitor has a suitable
target to query. target to query.
Note, also, that of late many switches now support a functionality
generally referred to as "trunk failover." This is a feature of the
switch that causes the link state of a particular switch port to be set
down (or up) when the state of another switch port goes down (or up).
It's purpose is to propogate link failures from logically "exterior" ports
to the logically "interior" ports that bonding is able to monitor via
miimon. Availability and configuration for trunk failover varies by
switch, but this can be a viable alternative to the ARP monitor when using
suitable switches.
12. Configuring Bonding for Maximum Throughput 12. Configuring Bonding for Maximum Throughput
============================================== ==============================================
...@@ -1709,7 +1782,7 @@ balance-rr: This mode is the only mode that will permit a single ...@@ -1709,7 +1782,7 @@ balance-rr: This mode is the only mode that will permit a single
interfaces. It is therefore the only mode that will allow a interfaces. It is therefore the only mode that will allow a
single TCP/IP stream to utilize more than one interface's single TCP/IP stream to utilize more than one interface's
worth of throughput. This comes at a cost, however: the worth of throughput. This comes at a cost, however: the
striping often results in peer systems receiving packets out striping generally results in peer systems receiving packets out
of order, causing TCP/IP's congestion control system to kick of order, causing TCP/IP's congestion control system to kick
in, often by retransmitting segments. in, often by retransmitting segments.
...@@ -1721,22 +1794,20 @@ balance-rr: This mode is the only mode that will permit a single ...@@ -1721,22 +1794,20 @@ balance-rr: This mode is the only mode that will permit a single
interface's worth of throughput, even after adjusting interface's worth of throughput, even after adjusting
tcp_reordering. tcp_reordering.
Note that this out of order delivery occurs when both the Note that the fraction of packets that will be delivered out of
sending and receiving systems are utilizing a multiple order is highly variable, and is unlikely to be zero. The level
interface bond. Consider a configuration in which a of reordering depends upon a variety of factors, including the
balance-rr bond feeds into a single higher capacity network networking interfaces, the switch, and the topology of the
channel (e.g., multiple 100Mb/sec ethernets feeding a single configuration. Speaking in general terms, higher speed network
gigabit ethernet via an etherchannel capable switch). In this cards produce more reordering (due to factors such as packet
configuration, traffic sent from the multiple 100Mb devices to coalescing), and a "many to many" topology will reorder at a
a destination connected to the gigabit device will not see higher rate than a "many slow to one fast" configuration.
packets out of order. However, traffic sent from the gigabit
device to the multiple 100Mb devices may or may not see Many switches do not support any modes that stripe traffic
traffic out of order, depending upon the balance policy of the (instead choosing a port based upon IP or MAC level addresses);
switch. Many switches do not support any modes that stripe for those devices, traffic for a particular connection flowing
traffic (instead choosing a port based upon IP or MAC level through the switch to a balance-rr bond will not utilize greater
addresses); for those devices, traffic flowing from the than one interface's worth of bandwidth.
gigabit device to the many 100Mb devices will only utilize one
interface.
If you are utilizing protocols other than TCP/IP, UDP for If you are utilizing protocols other than TCP/IP, UDP for
example, and your application can tolerate out of order example, and your application can tolerate out of order
...@@ -1936,6 +2007,10 @@ Failover may be delayed via the downdelay bonding module option. ...@@ -1936,6 +2007,10 @@ Failover may be delayed via the downdelay bonding module option.
13.2 Duplicated Incoming Packets 13.2 Duplicated Incoming Packets
-------------------------------- --------------------------------
NOTE: Starting with version 3.0.2, the bonding driver has logic to
suppress duplicate packets, which should largely eliminate this problem.
The following description is kept for reference.
It is not uncommon to observe a short burst of duplicated It is not uncommon to observe a short burst of duplicated
traffic when the bonding device is first used, or after it has been traffic when the bonding device is first used, or after it has been
idle for some period of time. This is most easily observed by issuing idle for some period of time. This is most easily observed by issuing
...@@ -2096,6 +2171,9 @@ The new driver was designed to be SMP safe from the start. ...@@ -2096,6 +2171,9 @@ The new driver was designed to be SMP safe from the start.
EtherExpress PRO/100 and a 3com 3c905b, for example). For most modes, EtherExpress PRO/100 and a 3com 3c905b, for example). For most modes,
devices need not be of the same speed. devices need not be of the same speed.
Starting with version 3.2.1, bonding also supports Infiniband
slaves in active-backup mode.
3. How many bonding devices can I have? 3. How many bonding devices can I have?
There is no limit. There is no limit.
...@@ -2154,11 +2232,15 @@ switches currently available support 802.3ad. ...@@ -2154,11 +2232,15 @@ switches currently available support 802.3ad.
8. Where does a bonding device get its MAC address from? 8. Where does a bonding device get its MAC address from?
If not explicitly configured (with ifconfig or ip link), the When using slave devices that have fixed MAC addresses, or when
MAC address of the bonding device is taken from its first slave the fail_over_mac option is enabled, the bonding device's MAC address is
device. This MAC address is then passed to all following slaves and the MAC address of the active slave.
remains persistent (even if the first slave is removed) until the
bonding device is brought down or reconfigured. For other configurations, if not explicitly configured (with
ifconfig or ip link), the MAC address of the bonding device is taken from
its first slave device. This MAC address is then passed to all following
slaves and remains persistent (even if the first slave is removed) until
the bonding device is brought down or reconfigured.
If you wish to change the MAC address, you can set it with If you wish to change the MAC address, you can set it with
ifconfig or ip link: ifconfig or ip link:
......
此差异已折叠。
...@@ -14,24 +14,35 @@ Introduction ...@@ -14,24 +14,35 @@ Introduction
============ ============
Datagram Congestion Control Protocol (DCCP) is an unreliable, connection Datagram Congestion Control Protocol (DCCP) is an unreliable, connection
based protocol designed to solve issues present in UDP and TCP particularly oriented protocol designed to solve issues present in UDP and TCP, particularly
for real time and multimedia traffic. for real-time and multimedia (streaming) traffic.
It divides into a base protocol (RFC 4340) and plugable congestion control
modules called CCIDs. Like plugable TCP congestion control, at least one CCID
needs to be enabled in order for the protocol to function properly. In the Linux
implementation, this is the TCP-like CCID2 (RFC 4341). Additional CCIDs, such as
the TCP-friendly CCID3 (RFC 4342), are optional.
For a brief introduction to CCIDs and suggestions for choosing a CCID to match
given applications, see section 10 of RFC 4340.
It has a base protocol and pluggable congestion control IDs (CCIDs). It has a base protocol and pluggable congestion control IDs (CCIDs).
It is at proposed standard RFC status and the homepage for DCCP as a protocol DCCP is a Proposed Standard (RFC 2026), and the homepage for DCCP as a protocol
is at: is at http://www.ietf.org/html.charters/dccp-charter.html
http://www.read.cs.ucla.edu/dccp/
Missing features Missing features
================ ================
The DCCP implementation does not currently have all the features that are in The Linux DCCP implementation does not currently support all the features that are
the RFC. specified in RFCs 4340...42.
The known bugs are at: The known bugs are at:
http://linux-net.osdl.org/index.php/TODO#DCCP http://linux-net.osdl.org/index.php/TODO#DCCP
For more up-to-date versions of the DCCP implementation, please consider using
the experimental DCCP test tree; instructions for checking this out are on:
http://linux-net.osdl.org/index.php/DCCP_Testing#Experimental_DCCP_source_tree
Socket options Socket options
============== ==============
...@@ -46,6 +57,12 @@ can be set before calling bind(). ...@@ -46,6 +57,12 @@ can be set before calling bind().
DCCP_SOCKOPT_GET_CUR_MPS is read-only and retrieves the current maximum packet DCCP_SOCKOPT_GET_CUR_MPS is read-only and retrieves the current maximum packet
size (application payload size) in bytes, see RFC 4340, section 14. size (application payload size) in bytes, see RFC 4340, section 14.
DCCP_SOCKOPT_SERVER_TIMEWAIT enables the server (listening socket) to hold
timewait state when closing the connection (RFC 4340, 8.3). The usual case is
that the closing server sends a CloseReq, whereupon the client holds timewait
state. When this boolean socket option is on, the server sends a Close instead
and will enter TIMEWAIT. This option must be set after accept() returns.
DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the
partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums
always cover the entire packet and that only fully covered application data is always cover the entire packet and that only fully covered application data is
...@@ -72,6 +89,8 @@ DCCP_SOCKOPT_CCID_TX_INFO ...@@ -72,6 +89,8 @@ DCCP_SOCKOPT_CCID_TX_INFO
Returns a `struct tfrc_tx_info' in optval; the buffer for optval and Returns a `struct tfrc_tx_info' in optval; the buffer for optval and
optlen must be set to at least sizeof(struct tfrc_tx_info). optlen must be set to at least sizeof(struct tfrc_tx_info).
On unidirectional connections it is useful to close the unused half-connection
via shutdown (SHUT_WR or SHUT_RD): this will reduce per-packet processing costs.
Sysctl variables Sysctl variables
================ ================
...@@ -123,6 +142,12 @@ sync_ratelimit = 125 ms ...@@ -123,6 +142,12 @@ sync_ratelimit = 125 ms
sequence-invalid packets on the same socket (RFC 4340, 7.5.4). The unit sequence-invalid packets on the same socket (RFC 4340, 7.5.4). The unit
of this parameter is milliseconds; a value of 0 disables rate-limiting. of this parameter is milliseconds; a value of 0 disables rate-limiting.
IOCTLS
======
FIONREAD
Works as in udp(7): returns in the `int' argument pointer the size of
the next pending datagram in bytes, or 0 when no datagram is pending.
Notes Notes
===== =====
......
...@@ -446,6 +446,33 @@ tcp_dma_copybreak - INTEGER ...@@ -446,6 +446,33 @@ tcp_dma_copybreak - INTEGER
and CONFIG_NET_DMA is enabled. and CONFIG_NET_DMA is enabled.
Default: 4096 Default: 4096
UDP variables:
udp_mem - vector of 3 INTEGERs: min, pressure, max
Number of pages allowed for queueing by all UDP sockets.
min: Below this number of pages UDP is not bothered about its
memory appetite. When amount of memory allocated by UDP exceeds
this number, UDP starts to moderate memory usage.
pressure: This value was introduced to follow format of tcp_mem.
max: Number of pages allowed for queueing by all UDP sockets.
Default is calculated at boot time from amount of available memory.
udp_rmem_min - INTEGER
Minimal size of receive buffer used by UDP sockets in moderation.
Each UDP socket is able to use the size for receiving data, even if
total pages of UDP sockets exceed udp_mem pressure. The unit is byte.
Default: 4096
udp_wmem_min - INTEGER
Minimal size of send buffer used by UDP sockets in moderation.
Each UDP socket is able to use the size for sending data, even if
total pages of UDP sockets exceed udp_mem pressure. The unit is byte.
Default: 4096
CIPSOv4 Variables: CIPSOv4 Variables:
cipso_cache_enable - BOOLEAN cipso_cache_enable - BOOLEAN
......
Traffic Shaper For Linux
This is the current BETA release of the traffic shaper for Linux. It works
within the following limits:
o Minimum shaping speed is currently about 9600 baud (it can only
shape down to 1 byte per clock tick)
o Maximum is about 256K, it will go above this but get a bit blocky.
o If you ifconfig the master device that a shaper is attached to down
then your machine will follow.
o The shaper must be a module.
Setup:
A shaper device is configured using the shapeconfig program.
Typically you will do something like this
shapecfg attach shaper0 eth1
shapecfg speed shaper0 64000
ifconfig shaper0 myhost netmask 255.255.255.240 broadcast 1.2.3.4.255 up
route add -net some.network netmask a.b.c.d dev shaper0
The shaper should have the same IP address as the device it is attached to
for normal use.
Gotchas:
The shaper shapes transmitted traffic. It's rather impossible to
shape received traffic except at the end (or a router) transmitting it.
Gated/routed/rwhod/mrouted all see the shaper as an additional device
and will treat it as such unless patched. Note that for mrouted you can run
mrouted tunnels via a traffic shaper to control bandwidth usage.
The shaper is device/route based. This makes it very easy to use
with any setup BUT less flexible. You may need to use iproute2 to set up
multiple route tables to get the flexibility.
There is no "borrowing" or "sharing" scheme. This is a simple
traffic limiter. We implement Van Jacobson and Sally Floyd's CBQ
architecture into Linux 2.2. This is the preferred solution. Shaper is
for simple or back compatible setups.
Alan
...@@ -236,7 +236,7 @@ ...@@ -236,7 +236,7 @@
This displays UDP-Lite statistics variables, whose meaning is as follows. This displays UDP-Lite statistics variables, whose meaning is as follows.
InDatagrams: Total number of received datagrams. InDatagrams: The total number of datagrams delivered to users.
NoPorts: Number of packets received to an unknown port. NoPorts: Number of packets received to an unknown port.
These cases are counted separately (not as InErrors). These cases are counted separately (not as InErrors).
......
XFRM proc - /proc/net/xfrm_* files
==================================
Masahide NAKAMURA <nakam@linux-ipv6.org>
Transformation Statistics
-------------------------
xfrm_proc is a statistics shown factor dropped by transformation
for developer.
It is a counter designed from current transformation source code
and defined like linux private MIB.
Inbound statistics
~~~~~~~~~~~~~~~~~~
XfrmInError:
All errors which is not matched others
XfrmInBufferError:
No buffer is left
XfrmInHdrError:
Header error
XfrmInNoStates:
No state is found
i.e. Either inbound SPI, address, or IPsec protocol at SA is wrong
XfrmInStateProtoError:
Transformation protocol specific error
e.g. SA key is wrong
XfrmInStateModeError:
Transformation mode specific error
XfrmInSeqOutOfWindow:
Sequence out of window
XfrmInStateExpired:
State is expired
XfrmInStateMismatch:
State has mismatch option
e.g. UDP encapsulation type is mismatch
XfrmInStateInvalid:
State is invalid
XfrmInTmplMismatch:
No matching template for states
e.g. Inbound SAs are correct but SP rule is wrong
XfrmInNoPols:
No policy is found for states
e.g. Inbound SAs are correct but no SP is found
XfrmInPolBlock:
Policy discards
XfrmInPolError:
Policy error
Outbound errors
~~~~~~~~~~~~~~~
XfrmOutError:
All errors which is not matched others
XfrmOutBundleGenError:
Bundle generation error
XfrmOutBundleCheckError:
Bundle check error
XfrmOutNoStates:
No state is found
XfrmOutStateProtoError:
Transformation protocol specific error
XfrmOutStateModeError:
Transformation mode specific error
XfrmOutStateExpired:
State is expired
XfrmOutPolBlock:
Policy discards
XfrmOutPolDead:
Policy is dead
XfrmOutPolError:
Policy error
...@@ -17,9 +17,9 @@ The User Interface ...@@ -17,9 +17,9 @@ The User Interface
------------------ ------------------
The Linux Plug and Play user interface provides a means to activate PnP devices The Linux Plug and Play user interface provides a means to activate PnP devices
for legacy and user level drivers that do not support Linux Plug and Play. The for legacy and user level drivers that do not support Linux Plug and Play. The
user interface is integrated into driverfs. user interface is integrated into sysfs.
In addition to the standard driverfs file the following are created in each In addition to the standard sysfs file the following are created in each
device's directory: device's directory:
id - displays a list of support EISA IDs id - displays a list of support EISA IDs
options - displays possible resource configurations options - displays possible resource configurations
......
...@@ -4,6 +4,11 @@ S/390 common I/O-Layer - command line parameters, procfs and debugfs entries ...@@ -4,6 +4,11 @@ S/390 common I/O-Layer - command line parameters, procfs and debugfs entries
Command line parameters Command line parameters
----------------------- -----------------------
* ccw_timeout_log
Enable logging of debug information in case of ccw device timeouts.
* cio_msg = yes | no * cio_msg = yes | no
Determines whether information on found devices and sensed device Determines whether information on found devices and sensed device
......
...@@ -133,7 +133,7 @@ During its startup the Linux/390 system checks for peripheral devices. Each ...@@ -133,7 +133,7 @@ During its startup the Linux/390 system checks for peripheral devices. Each
of those devices is uniquely defined by a so called subchannel by the ESA/390 of those devices is uniquely defined by a so called subchannel by the ESA/390
channel subsystem. While the subchannel numbers are system generated, each channel subsystem. While the subchannel numbers are system generated, each
subchannel also takes a user defined attribute, the so called device number. subchannel also takes a user defined attribute, the so called device number.
Both subchannel number and device number cannot exceed 65535. During driverfs Both subchannel number and device number cannot exceed 65535. During sysfs
initialisation, the information about control unit type and device types that initialisation, the information about control unit type and device types that
imply specific I/O commands (channel command words - CCWs) in order to operate imply specific I/O commands (channel command words - CCWs) in order to operate
the device are gathered. Device drivers can retrieve this set of hardware the device are gathered. Device drivers can retrieve this set of hardware
......
...@@ -64,8 +64,6 @@ lpfc.txt ...@@ -64,8 +64,6 @@ lpfc.txt
- LPFC driver release notes - LPFC driver release notes
megaraid.txt megaraid.txt
- Common Management Module, shared code handling ioctls for LSI drivers - Common Management Module, shared code handling ioctls for LSI drivers
ncr53c7xx.txt
- info on driver for NCR53c7xx based adapters
ncr53c8xx.txt ncr53c8xx.txt
- info on driver for NCR53c8xx based adapters - info on driver for NCR53c8xx based adapters
osst.txt osst.txt
......
1 Release Date : Thur. Nov. 07 16:30:43 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.16
3 Older Version : 00.00.03.15
1. Increased MFI_POLL_TIMEOUT_SECS to 60 seconds from 10. FW may take
a max of 60 seconds to respond to the INIT cmd.
1 Release Date : Fri. Sep. 07 16:30:43 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.15
3 Older Version : 00.00.03.14
1. Added module parameter "poll_mode_io" to support for "polling"
(reduced interrupt operation). In this mode, IO completion
interrupts are delayed. At the end of initiating IOs, the
driver schedules for cmd completion if there are pending cmds
to be completed. A timer-based interrupt has also been added
to prevent IO completion processing from being delayed
indefinitely in the case that no new IOs are initiated.
1 Release Date : Fri. Sep. 07 16:30:43 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.14
3 Older Version : 00.00.03.13
1. Setting the max_sectors_per_req based on max SGL supported by the
FW. Prior versions calculated this value from controller info
(max_sectors_1, max_sectors_2). For certain controllers/FW,
this was resulting in a value greater than max SGL supported
by the FW. Issue was first reported by users running LUKS+XFS
with megaraid_sas. Thanks to RB for providing the logs and
duplication steps that helped to get to the root cause of the
issue. 2. Increased MFI_POLL_TIMEOUT_SECS to 60 seconds from
10. FW may take a max of 60 seconds to respond to the INIT
cmd.
1 Release Date : Fri. June. 15 16:30:43 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.13
3 Older Version : 00.00.03.12
1. Added the megasas_reset_timer routine to intercept cmd timeout and throttle io.
On Fri, 2007-03-16 at 16:44 -0600, James Bottomley wrote:
It looks like megaraid_sas at least needs this to throttle its commands
> as they begin to time out. The code keeps the existing transport
> template use of eh_timed_out (and allows the transport to override the
> host if they both have this callback).
>
> James
1 Release Date : Sat May. 12 16:30:43 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.12
3 Older Version : 00.00.03.11
1. When MegaSAS driver receives reset call from OS, driver waits in reset
routine for max 3 minutes for all pending command completion. Now driver will
call completion routine every 5 seconds from the reset routine instead of
waiting for depending on cmd completion from isr path.
1 Release Date : Mon Apr. 30 10:25:52 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.11
3 Older Version : 00.00.03.09
1. Memory Manager for IOCTL removed for 2.6 kernels.
pci_alloc_consistent replaced by dma_alloc_coherent. With this
change there is no need of memory manager in the driver code
On Wed, 2007-02-07 at 13:30 -0800, Andrew Morton wrote:
> I suspect all this horror is due to stupidity in the DMA API.
>
> pci_alloc_consistent() just goes and assumes GFP_ATOMIC, whereas
> the caller (megasas_mgmt_fw_ioctl) would have been perfectly happy
> to use GFP_KERNEL.
>
> I bet this fixes it
It does, but the DMA API was expanded to cope with this exact case, so
use dma_alloc_coherent() directly in the megaraid code instead. The dev
is just &pci_dev->dev.
James <James.Bottomley@SteelEye.com>
3. SYNCHRONIZE_CACHE is not supported by FW and thus blocked by driver.
4. Hibernation support added
5. Performing diskdump while running IO in RHEL 4 was failing. Fixed.
1 Release Date : Fri Feb. 09 14:36:28 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.09
3 Older Version : 00.00.03.08
i. Under heavy IO mid-layer prints "DRIVER_TIMEOUT" errors
The driver now waits for 10 seconds to elapse instead of 5 (as in
previous release) to resume IO.
1 Release Date : Mon Feb. 05 11:35:24 PST 2007 -
(emaild-id:megaraidlinux@lsi.com)
Sumant Patro
Bo Yang
2 Current Version : 00.00.03.08
3 Older Version : 00.00.03.07
i. Under heavy IO mid-layer prints "DRIVER_TIMEOUT" errors
Fix: The driver is now throttling IO.
Checks added in megasas_queue_command to know if FW is able to
process commands within timeout period. If number of retries
is 2 or greater,the driver stops sending cmd to FW temporarily. IO is
resumed if pending cmd count reduces to 16 or 5 seconds has elapsed
from the time cmds were last sent to FW.
ii. FW enables WCE bit in Mode Sense cmd for drives that are configured
as WriteBack. The OS may send "SYNCHRONIZE_CACHE" cmd when Logical
Disks are exposed with WCE=1. User is advised to enable Write Back
mode only when the controller has battery backup. At this time
Synhronize cache is not supported by the FW. Driver will short-cycle
the cmd and return sucess without sending down to FW.
1 Release Date : Sun Jan. 14 11:21:32 PDT 2007 -
Sumant Patro <Sumant.Patro@lsil.com>/Bo Yang
2 Current Version : 00.00.03.07
3 Older Version : 00.00.03.06
i. bios_param entry added in scsi_host_template that returns disk geometry
information.
1 Release Date : Fri Oct 20 11:21:32 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com>/Bo Yang
2 Current Version : 00.00.03.06
3 Older Version : 00.00.03.05
1. Added new memory management module to support the IOCTL memory allocation. For IOCTL we try to allocate from the memory pool created during driver initialization. If mem pool is empty then we allocate at run time.
2. Added check in megasas_queue_command and dpc/isr routine to see if we have already declared adapter dead
(hw_crit_error=1). If hw_crit_error==1, now we donot accept any processing of pending cmds/accept any cmd from OS
1 Release Date : Mon Oct 02 11:21:32 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com> 1 Release Date : Mon Oct 02 11:21:32 PDT 2006 - Sumant Patro <Sumant.Patro@lsil.com>
2 Current Version : 00.00.03.05 2 Current Version : 00.00.03.05
......
...@@ -56,6 +56,10 @@ Supported Cards/Chipsets ...@@ -56,6 +56,10 @@ Supported Cards/Chipsets
9005:0285:9005:02d1 Adaptec 5405 (Voodoo40) 9005:0285:9005:02d1 Adaptec 5405 (Voodoo40)
9005:0285:15d9:02d2 SMC AOC-USAS-S8i-LP 9005:0285:15d9:02d2 SMC AOC-USAS-S8i-LP
9005:0285:15d9:02d3 SMC AOC-USAS-S8iR-LP 9005:0285:15d9:02d3 SMC AOC-USAS-S8iR-LP
9005:0285:9005:02d4 Adaptec 2045 (Voodoo04 Lite)
9005:0285:9005:02d5 Adaptec 2405 (Voodoo40 Lite)
9005:0285:9005:02d6 Adaptec 2445 (Voodoo44 Lite)
9005:0285:9005:02d7 Adaptec 2805 (Voodoo80 Lite)
1011:0046:9005:0364 Adaptec 5400S (Mustang) 1011:0046:9005:0364 Adaptec 5400S (Mustang)
9005:0287:9005:0800 Adaptec Themisto (Jupiter) 9005:0287:9005:0800 Adaptec Themisto (Jupiter)
9005:0200:9005:0200 Adaptec Themisto (Jupiter) 9005:0200:9005:0200 Adaptec Themisto (Jupiter)
......
HIGHPOINT ROCKETRAID 3xxx RAID DRIVER (hptiop) HIGHPOINT ROCKETRAID 3xxx/4xxx ADAPTER DRIVER (hptiop)
Controller Register Map Controller Register Map
------------------------- -------------------------
The controller IOP is accessed via PCI BAR0. For Intel IOP based adapters, the controller IOP is accessed via PCI BAR0:
BAR0 offset Register BAR0 offset Register
0x10 Inbound Message Register 0 0x10 Inbound Message Register 0
...@@ -18,6 +18,24 @@ The controller IOP is accessed via PCI BAR0. ...@@ -18,6 +18,24 @@ The controller IOP is accessed via PCI BAR0.
0x40 Inbound Queue Port 0x40 Inbound Queue Port
0x44 Outbound Queue Port 0x44 Outbound Queue Port
For Marvell IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1:
BAR0 offset Register
0x20400 Inbound Doorbell Register
0x20404 Inbound Interrupt Mask Register
0x20408 Outbound Doorbell Register
0x2040C Outbound Interrupt Mask Register
BAR1 offset Register
0x0 Inbound Queue Head Pointer
0x4 Inbound Queue Tail Pointer
0x8 Outbound Queue Head Pointer
0xC Outbound Queue Tail Pointer
0x10 Inbound Message Register
0x14 Outbound Message Register
0x40-0x1040 Inbound Queue
0x1040-0x2040 Outbound Queue
I/O Request Workflow I/O Request Workflow
---------------------- ----------------------
...@@ -73,15 +91,9 @@ The driver exposes following sysfs attributes: ...@@ -73,15 +91,9 @@ The driver exposes following sysfs attributes:
driver-version R driver version string driver-version R driver version string
firmware-version R firmware version string firmware-version R firmware version string
The driver registers char device "hptiop" to communicate with HighPoint RAID
management software. Its ioctl routine acts as a general binary interface
between the IOP firmware and HighPoint RAID management software. New management
functions can be implemented in application/firmware without modification
in driver code.
----------------------------------------------------------------------------- -----------------------------------------------------------------------------
Copyright (C) 2006 HighPoint Technologies, Inc. All Rights Reserved. Copyright (C) 2006-2007 HighPoint Technologies, Inc. All Rights Reserved.
This file is distributed in the hope that it will be useful, This file is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of but WITHOUT ANY WARRANTY; without even the implied warranty of
......
README for WarpEngine/A4000T/A4091 SCSI kernels.
Use the following options to disable options in the SCSI driver.
Using amiboot for example.....
To disable Synchronous Negotiation....
amiboot -k kernel 53c7xx=nosync:0
To disable Disconnection....
amiboot -k kernel 53c7xx=nodisconnect:0
To disable certain SCSI devices...
amiboot -k kernel 53c7xx=validids:0x3F
this allows only device ID's 0,1,2,3,4 and 5 for linux to handle.
(this is a bitmasked field - i.e. each bit represents a SCSI ID)
These commands work on a per controller basis and use the option 'next' to
move to the next controller in the system.
e.g.
amiboot -k kernel 53c7xx=nodisconnect:0,next,nosync:0
this uses No Disconnection on the first controller and Asynchronous
SCSI on the second controller.
Known Issues:
Two devices are known not to function with the default settings of using
synchronous SCSI. These are the Archive Viper 150 Tape Drive and the
SyQuest SQ555 removeable hard drive. When using these devices on a controller
use the 'nosync:0' option.
Please try these options and post any problems/successes to me.
Alan Hourihane <alanh@fairlite.demon.co.uk>
0 -> UNKNOWN/GENERIC [0070:3400] 0 -> UNKNOWN/GENERIC [0070:3400]
1 -> Hauppauge WinTV-HVR1800lp [0070:7600] 1 -> Hauppauge WinTV-HVR1800lp [0070:7600]
2 -> Hauppauge WinTV-HVR1800 [0070:7800,0070:7801] 2 -> Hauppauge WinTV-HVR1800 [0070:7800,0070:7801,0070:7809]
3 -> Hauppauge WinTV-HVR1250 [0070:7911] 3 -> Hauppauge WinTV-HVR1250 [0070:7911]
4 -> DViCO FusionHDTV5 Express [18ac:d500] 4 -> DViCO FusionHDTV5 Express [18ac:d500]
5 -> Hauppauge WinTV-HVR1500Q [0070:7790,0070:7797]
6 -> Hauppauge WinTV-HVR1500 [0070:7710,0070:7717]
...@@ -56,3 +56,4 @@ ...@@ -56,3 +56,4 @@
55 -> Shenzhen Tungsten Ages Tech TE-DTV-250 / Swann OEM [c180:c980] 55 -> Shenzhen Tungsten Ages Tech TE-DTV-250 / Swann OEM [c180:c980]
56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [0070:9600,0070:9601,0070:9602] 56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [0070:9600,0070:9601,0070:9602]
57 -> ADS Tech Instant Video PCI [1421:0390] 57 -> ADS Tech Instant Video PCI [1421:0390]
58 -> Pinnacle PCTV HD 800i [11bd:0051]
0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800] 0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800]
1 -> Unknown EM2820/2840 video grabber (em2820/em2840) 1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2750,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883]
2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036] 2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036]
3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208] 3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208]
4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200] 4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201]
5 -> MSI VOX USB 2.0 (em2820/em2840) [eb1a:2820] 5 -> MSI VOX USB 2.0 (em2820/em2840)
6 -> Terratec Cinergy 200 USB (em2800) 6 -> Terratec Cinergy 200 USB (em2800)
7 -> Leadtek Winfast USB II (em2800) 7 -> Leadtek Winfast USB II (em2800)
8 -> Kworld USB2800 (em2800) 8 -> Kworld USB2800 (em2800)
9 -> Pinnacle Dazzle DVC 90 (em2820/em2840) [2304:0207] 9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a]
10 -> Hauppauge WinTV HVR 900 (em2880) 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500]
11 -> Terratec Hybrid XS (em2880) 11 -> Terratec Hybrid XS (em2880) [0ccd:0042]
12 -> Kworld PVR TV 2800 RF (em2820/em2840) 12 -> Kworld PVR TV 2800 RF (em2820/em2840)
13 -> Terratec Prodigy XS (em2880) 13 -> Terratec Prodigy XS (em2880) [0ccd:0047]
14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840)
15 -> V-Gear PocketTV (em2800)
16 -> Hauppauge WinTV HVR 950 (em2880) [2040:6513]
...@@ -16,3 +16,9 @@ ...@@ -16,3 +16,9 @@
16 -> GOTVIEW PCI DVD2 Deluxe [ffac:0600] 16 -> GOTVIEW PCI DVD2 Deluxe [ffac:0600]
17 -> Yuan MPC622 [ff01:d998] 17 -> Yuan MPC622 [ff01:d998]
18 -> Digital Cowboy DCT-MTVP1 [1461:bfff] 18 -> Digital Cowboy DCT-MTVP1 [1461:bfff]
19 -> Yuan PG600V2/GotView PCI DVD Lite [ffab:0600,ffad:0600]
20 -> Club3D ZAP-TV1x01 [ffab:0600]
21 -> AverTV MCE 116 Plus [1461:c439]
22 -> ASUS Falcon2 [1043:4b66,1043:462e,1043:4b2e]
23 -> AverMedia PVR-150 Plus [1461:c035]
24 -> AverMedia EZMaker PCI Deluxe [1461:c03f]
...@@ -80,7 +80,7 @@ ...@@ -80,7 +80,7 @@
79 -> Sedna/MuchTV PC TV Cardbus TV/Radio (ITO25 Rev:2B) 79 -> Sedna/MuchTV PC TV Cardbus TV/Radio (ITO25 Rev:2B)
80 -> ASUS Digimatrix TV [1043:0210] 80 -> ASUS Digimatrix TV [1043:0210]
81 -> Philips Tiger reference design [1131:2018] 81 -> Philips Tiger reference design [1131:2018]
82 -> MSI TV@Anywhere plus [1462:6231] 82 -> MSI TV@Anywhere plus [1462:6231,1462:8624]
83 -> Terratec Cinergy 250 PCI TV [153b:1160] 83 -> Terratec Cinergy 250 PCI TV [153b:1160]
84 -> LifeView FlyDVB Trio [5168:0319] 84 -> LifeView FlyDVB Trio [5168:0319]
85 -> AverTV DVB-T 777 [1461:2c05,1461:2c05] 85 -> AverTV DVB-T 777 [1461:2c05,1461:2c05]
...@@ -102,7 +102,7 @@ ...@@ -102,7 +102,7 @@
101 -> Pinnacle PCTV 310i [11bd:002f] 101 -> Pinnacle PCTV 310i [11bd:002f]
102 -> Avermedia AVerTV Studio 507 [1461:9715] 102 -> Avermedia AVerTV Studio 507 [1461:9715]
103 -> Compro Videomate DVB-T200A 103 -> Compro Videomate DVB-T200A
104 -> Hauppauge WinTV-HVR1110 DVB-T/Hybrid [0070:6701] 104 -> Hauppauge WinTV-HVR1110 DVB-T/Hybrid [0070:6700,0070:6701,0070:6702,0070:6703,0070:6704,0070:6705]
105 -> Terratec Cinergy HT PCMCIA [153b:1172] 105 -> Terratec Cinergy HT PCMCIA [153b:1172]
106 -> Encore ENLTV [1131:2342,1131:2341,3016:2344] 106 -> Encore ENLTV [1131:2342,1131:2341,3016:2344]
107 -> Encore ENLTV-FM [1131:230f] 107 -> Encore ENLTV-FM [1131:230f]
...@@ -116,3 +116,16 @@ ...@@ -116,3 +116,16 @@
115 -> Sabrent PCMCIA TV-PCB05 [0919:2003] 115 -> Sabrent PCMCIA TV-PCB05 [0919:2003]
116 -> 10MOONS TM300 TV Card [1131:2304] 116 -> 10MOONS TM300 TV Card [1131:2304]
117 -> Avermedia Super 007 [1461:f01d] 117 -> Avermedia Super 007 [1461:f01d]
118 -> Beholder BeholdTV 401 [0000:4016]
119 -> Beholder BeholdTV 403 [0000:4036]
120 -> Beholder BeholdTV 403 FM [0000:4037]
121 -> Beholder BeholdTV 405 [0000:4050]
122 -> Beholder BeholdTV 405 FM [0000:4051]
123 -> Beholder BeholdTV 407 [0000:4070]
124 -> Beholder BeholdTV 407 FM [0000:4071]
125 -> Beholder BeholdTV 409 [0000:4090]
126 -> Beholder BeholdTV 505 FM/RDS [0000:5051,0000:505B,5ace:5050]
127 -> Beholder BeholdTV 507 FM/RDS / BeholdTV 509 FM [0000:5071,0000:507B,5ace:5070,5ace:5090]
128 -> Beholder BeholdTV Columbus TVFM [0000:5201]
129 -> Beholder BeholdTV 607 / BeholdTV 609 [5ace:6070,5ace:6071,5ace:6072,5ace:6073,5ace:6090,5ace:6091,5ace:6092,5ace:6093]
130 -> Beholder BeholdTV M6 / BeholdTV M6 Extra [5ace:6190,5ace:6193]
...@@ -52,7 +52,7 @@ tuner=50 - TCL 2002N ...@@ -52,7 +52,7 @@ tuner=50 - TCL 2002N
tuner=51 - Philips PAL/SECAM_D (FM 1256 I-H3) tuner=51 - Philips PAL/SECAM_D (FM 1256 I-H3)
tuner=52 - Thomson DTT 7610 (ATSC/NTSC) tuner=52 - Thomson DTT 7610 (ATSC/NTSC)
tuner=53 - Philips FQ1286 tuner=53 - Philips FQ1286
tuner=54 - tda8290+75 tuner=54 - Philips/NXP TDA 8290/8295 + 8275/8275A/18271
tuner=55 - TCL 2002MB tuner=55 - TCL 2002MB
tuner=56 - Philips PAL/SECAM multi (FQ1216AME MK4) tuner=56 - Philips PAL/SECAM multi (FQ1216AME MK4)
tuner=57 - Philips FQ1236A MK4 tuner=57 - Philips FQ1236A MK4
...@@ -69,7 +69,8 @@ tuner=67 - Philips TD1316 Hybrid Tuner ...@@ -69,7 +69,8 @@ tuner=67 - Philips TD1316 Hybrid Tuner
tuner=68 - Philips TUV1236D ATSC/NTSC dual in tuner=68 - Philips TUV1236D ATSC/NTSC dual in
tuner=69 - Tena TNF 5335 and similar models tuner=69 - Tena TNF 5335 and similar models
tuner=70 - Samsung TCPN 2121P30A tuner=70 - Samsung TCPN 2121P30A
tuner=71 - Xceive xc3028 tuner=71 - Xceive xc2028/xc3028 tuner
tuner=72 - Thomson FE6600 tuner=72 - Thomson FE6600
tuner=73 - Samsung TCPG 6121P30A tuner=73 - Samsung TCPG 6121P30A
tuner=75 - Philips TEA5761 FM Radio tuner=75 - Philips TEA5761 FM Radio
tuner=76 - Xceive 5000 tuner
...@@ -62,3 +62,4 @@ ...@@ -62,3 +62,4 @@
61 -> Pinnacle Studio Linx Video input cable (PAL) [2304:0301] 61 -> Pinnacle Studio Linx Video input cable (PAL) [2304:0301]
62 -> Pinnacle PCTV Bungee USB (PAL) FM [2304:0419] 62 -> Pinnacle PCTV Bungee USB (PAL) FM [2304:0419]
63 -> Hauppauge WinTv-USB [2400:4200] 63 -> Hauppauge WinTv-USB [2400:4200]
64 -> Pinnacle Studio PCTV USB (NTSC) FM V3 [2304:0113]
此差异已折叠。
...@@ -568,6 +568,7 @@ the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. ...@@ -568,6 +568,7 @@ the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'.
Many thanks to following persons for their contribute (listed in alphabetical Many thanks to following persons for their contribute (listed in alphabetical
order): order):
- David Anderson for the donation of a webcam;
- Luca Capello for the donation of a webcam; - Luca Capello for the donation of a webcam;
- Philippe Coval for having helped testing the PAS202BCA image sensor; - Philippe Coval for having helped testing the PAS202BCA image sensor;
- Joao Rodrigo Fuzaro, Joao Limirio, Claudio Filho and Caio Begotti for the - Joao Rodrigo Fuzaro, Joao Limirio, Claudio Filho and Caio Begotti for the
......
...@@ -1021,7 +1021,7 @@ void read_slab_dir(void) ...@@ -1021,7 +1021,7 @@ void read_slab_dir(void)
char *t; char *t;
int count; int count;
if (chdir("/sys/slab")) if (chdir("/sys/kernel/slab"))
fatal("SYSFS support for SLUB not active\n"); fatal("SYSFS support for SLUB not active\n");
dir = opendir("."); dir = opendir(".");
......
...@@ -63,7 +63,7 @@ In case you forgot to enable debugging on the kernel command line: It is ...@@ -63,7 +63,7 @@ In case you forgot to enable debugging on the kernel command line: It is
possible to enable debugging manually when the kernel is up. Look at the possible to enable debugging manually when the kernel is up. Look at the
contents of: contents of:
/sys/slab/<slab name>/ /sys/kernel/slab/<slab name>/
Look at the writable files. Writing 1 to them will enable the Look at the writable files. Writing 1 to them will enable the
corresponding debug option. All options can be set on a slab that does corresponding debug option. All options can be set on a slab that does
......
...@@ -110,12 +110,18 @@ Idle loop ...@@ -110,12 +110,18 @@ Idle loop
Rebooting Rebooting
reboot=b[ios] | t[riple] | k[bd] [, [w]arm | [c]old] reboot=b[ios] | t[riple] | k[bd] | a[cpi] | e[fi] [, [w]arm | [c]old]
bios Use the CPU reboot vector for warm reset bios Use the CPU reboot vector for warm reset
warm Don't set the cold reboot flag warm Don't set the cold reboot flag
cold Set the cold reboot flag cold Set the cold reboot flag
triple Force a triple fault (init) triple Force a triple fault (init)
kbd Use the keyboard controller. cold reset (default) kbd Use the keyboard controller. cold reset (default)
acpi Use the ACPI RESET_REG in the FADT. If ACPI is not configured or the
ACPI reset does not work, the reboot path attempts the reset using
the keyboard controller.
efi Use efi reset_system runtime service. If EFI is not configured or the
EFI reset does not work, the reboot path attempts the reset using
the keyboard controller.
Using warm reset will be much faster especially on big memory Using warm reset will be much faster especially on big memory
systems because the BIOS will not go through the memory check. systems because the BIOS will not go through the memory check.
......
...@@ -19,6 +19,10 @@ Mechanics: ...@@ -19,6 +19,10 @@ Mechanics:
- Build the kernel with the following configuration. - Build the kernel with the following configuration.
CONFIG_FB_EFI=y CONFIG_FB_EFI=y
CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y
If EFI runtime services are expected, the following configuration should
be selected.
CONFIG_EFI=y
CONFIG_EFI_VARS=y or m # optional
- Create a VFAT partition on the disk - Create a VFAT partition on the disk
- Copy the following to the VFAT partition: - Copy the following to the VFAT partition:
elilo bootloader with x86_64 support, elilo configuration file, elilo bootloader with x86_64 support, elilo configuration file,
...@@ -27,3 +31,8 @@ Mechanics: ...@@ -27,3 +31,8 @@ Mechanics:
can be found in the elilo sourceforge project. can be found in the elilo sourceforge project.
- Boot to EFI shell and invoke elilo choosing the kernel image built - Boot to EFI shell and invoke elilo choosing the kernel image built
in first step. in first step.
- If some or all EFI runtime services don't work, you can try following
kernel command line parameters to turn off some or all EFI runtime
services.
noefi turn off all EFI runtime services
reboot_type=k turn off EFI reboot runtime service
此差异已折叠。
Chinese translated version of Documentation/HOWTO Chinese translated version of Documentation/HOWTO
If you have any comment or update to the content, please contact the If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have problem original document maintainer directly. However, if you have a problem
communicating in English you can also ask the Chinese maintainer for communicating in English you can also ask the Chinese maintainer for
help. Contact the Chinese maintainer, if this translation is outdated help. Contact the Chinese maintainer if this translation is outdated
or there is problem with translation. or if there is a problem with the translation.
Maintainer: Greg Kroah-Hartman <greg@kroah.com> Maintainer: Greg Kroah-Hartman <greg@kroah.com>
Chinese maintainer: Li Yang <leoli@freescale.com> Chinese maintainer: Li Yang <leoli@freescale.com>
...@@ -85,7 +85,7 @@ Linux内核源代码都是在GPL(通用公共许可证)的保护下发布的 ...@@ -85,7 +85,7 @@ Linux内核源代码都是在GPL(通用公共许可证)的保护下发布的
Linux内核代码中包含有大量的文档。这些文档对于学习如何与内核社区互动有着 Linux内核代码中包含有大量的文档。这些文档对于学习如何与内核社区互动有着
不可估量的价值。当一个新的功能被加入内核,最好把解释如何使用这个功能的文 不可估量的价值。当一个新的功能被加入内核,最好把解释如何使用这个功能的文
档也放进内核。当内核的改动导致面向用户空间的接口发生变化时,最好将相关信 档也放进内核。当内核的改动导致面向用户空间的接口发生变化时,最好将相关信
息或手册页(manpages)的补丁发到mtk-manpages@gmx.net,以向手册页(manpages) 息或手册页(manpages)的补丁发到mtk.manpages@gmail.com,以向手册页(manpages)
的维护者解释这些变化。 的维护者解释这些变化。
以下是内核代码中需要阅读的文档: 以下是内核代码中需要阅读的文档:
...@@ -218,6 +218,8 @@ kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循 ...@@ -218,6 +218,8 @@ kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循
时,一个新的-rc版本就会被发布。计划是每周都发布新的-rc版本。 时,一个新的-rc版本就会被发布。计划是每周都发布新的-rc版本。
- 这个过程一直持续下去直到内核被认为达到足够稳定的状态,持续时间大概是 - 这个过程一直持续下去直到内核被认为达到足够稳定的状态,持续时间大概是
6个星期。 6个星期。
- 以下地址跟踪了在每个-rc发布中发现的退步列表:
http://kernelnewbies.org/known_regressions
关于内核发布,值得一提的是Andrew Morton在linux-kernel邮件列表中如是说: 关于内核发布,值得一提的是Andrew Morton在linux-kernel邮件列表中如是说:
“没有人知道新内核何时会被发布,因为发布是根据已知bug的情况来决定 “没有人知道新内核何时会被发布,因为发布是根据已知bug的情况来决定
......
Chinese translated version of Documentation/SubmittingDrivers
If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
Chinese maintainer: Li Yang <leo@zh-kernel.org>
---------------------------------------------------------------------
Documentation/SubmittingDrivers 的中文翻译
如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文
交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题,请联系中文版维护者。
中文版维护者: 李阳 Li Yang <leo@zh-kernel.org>
中文版翻译者: 李阳 Li Yang <leo@zh-kernel.org>
中文版校译者: 陈琦 Maggie Chen <chenqi@beyondsoft.com>
王聪 Wang Cong <xiyou.wangcong@gmail.com>
张巍 Zhang Wei <Wei.Zhang@freescale.com>
以下为正文
---------------------------------------------------------------------
如何向 Linux 内核提交驱动程序
-----------------------------
这篇文档将会解释如何向不同的内核源码树提交设备驱动程序。请注意,如果你感
兴趣的是显卡驱动程序,你也许应该访问 XFree86 项目(http://www.xfree86.org/)
和/或 X.org 项目 (http://x.org)。
另请参阅 Documentation/SubmittingPatches 文档。
分配设备号
----------
块设备和字符设备的主设备号与从设备号是由 Linux 命名编号分配权威 LANANA(
现在是 Torben Mathiasen)负责分配。申请的网址是 http://www.lanana.org/。
即使不准备提交到主流内核的设备驱动也需要在这里分配设备号。有关详细信息,
请参阅 Documentation/devices.txt。
如果你使用的不是已经分配的设备号,那么当你提交设备驱动的时候,它将会被强
制分配一个新的设备号,即便这个设备号和你之前发给客户的截然不同。
设备驱动的提交对象
------------------
Linux 2.0:
此内核源码树不接受新的驱动程序。
Linux 2.2:
此内核源码树不接受新的驱动程序。
Linux 2.4:
如果所属的代码领域在内核的 MAINTAINERS 文件中列有一个总维护者,
那么请将驱动程序提交给他。如果此维护者没有回应或者你找不到恰当的
维护者,那么请联系 Willy Tarreau <w@1wt.eu>。
Linux 2.6:
除了遵循和 2.4 版内核同样的规则外,你还需要在 linux-kernel 邮件
列表上跟踪最新的 API 变化。向 Linux 2.6 内核提交驱动的顶级联系人
是 Andrew Morton <akpm@osdl.org>。
决定设备驱动能否被接受的条件
----------------------------
许可: 代码必须使用 GNU 通用公开许可证 (GPL) 提交给 Linux,但是
我们并不要求 GPL 是唯一的许可。你或许会希望同时使用多种
许可证发布,如果希望驱动程序可以被其他开源社区(比如BSD)
使用。请参考 include/linux/module.h 文件中所列出的可被
接受共存的许可。
版权: 版权所有者必须同意使用 GPL 许可。最好提交者和版权所有者
是相同个人或实体。否则,必需列出授权使用 GPL 的版权所有
人或实体,以备验证之需。
接口: 如果你的驱动程序使用现成的接口并且和其他同类的驱动程序行
为相似,而不是去发明无谓的新接口,那么它将会更容易被接受。
如果你需要一个 Linux 和 NT 的通用驱动接口,那么请在用
户空间实现它。
代码: 请使用 Documentation/CodingStyle 中所描述的 Linux 代码风
格。如果你的某些代码段(例如那些与 Windows 驱动程序包共
享的代码段)需要使用其他格式,而你却只希望维护一份代码,
那么请将它们很好地区分出来,并且注明原因。
可移植性: 请注意,指针并不永远是 32 位的,不是所有的计算机都使用小
尾模式 (little endian) 存储数据,不是所有的人都拥有浮点
单元,不要随便在你的驱动程序里嵌入 x86 汇编指令。只能在
x86 上运行的驱动程序一般是不受欢迎的。虽然你可能只有 x86
硬件,很难测试驱动程序在其他平台上是否可用,但是确保代码
可以被轻松地移植却是很简单的。
清晰度: 做到所有人都能修补这个驱动程序将会很有好处,因为这样你将
会直接收到修复的补丁而不是 bug 报告。如果你提交一个试图
隐藏硬件工作机理的驱动程序,那么它将会被扔进废纸篓。
电源管理: 因为 Linux 正在被很多移动设备和桌面系统使用,所以你的驱
动程序也很有可能被使用在这些设备上。它应该支持最基本的电
源管理,即在需要的情况下实现系统级休眠和唤醒要用到的
.suspend 和 .resume 函数。你应该检查你的驱动程序是否能正
确地处理休眠与唤醒,如果实在无法确认,请至少把 .suspend
函数定义成返回 -ENOSYS(功能未实现)错误。你还应该尝试确
保你的驱动在什么都不干的情况下将耗电降到最低。要获得驱动
程序测试的指导,请参阅
Documentation/power/drivers-testing.txt。有关驱动程序电
源管理问题相对全面的概述,请参阅
Documentation/power/devices.txt。
管理: 如果一个驱动程序的作者还在进行有效的维护,那么通常除了那
些明显正确且不需要任何检查的补丁以外,其他所有的补丁都会
被转发给作者。如果你希望成为驱动程序的联系人和更新者,最
好在代码注释中写明并且在 MAINTAINERS 文件中加入这个驱动
程序的条目。
不影响设备驱动能否被接受的条件
------------------------------
供应商: 由硬件供应商来维护驱动程序通常是一件好事。不过,如果源码
树里已经有其他人提供了可稳定工作的驱动程序,那么请不要期
望“我是供应商”会成为内核改用你的驱动程序的理由。理想的情
况是:供应商与现有驱动程序的作者合作,构建一个统一完美的
驱动程序。
作者: 驱动程序是由大的 Linux 公司研发还是由你个人编写,并不影
响其是否能被内核接受。没有人对内核源码树享有特权。只要你
充分了解内核社区,你就会发现这一点。
资源列表
--------
Linux 内核主源码树:
ftp.??.kernel.org:/pub/linux/kernel/...
?? == 你的国家代码,例如 "cn"、"us"、"uk"、"fr" 等等
Linux 内核邮件列表:
linux-kernel@vger.kernel.org
[可通过向majordomo@vger.kernel.org发邮件来订阅]
Linux 设备驱动程序,第三版(探讨 2.6.10 版内核):
http://lwn.net/Kernel/LDD3/ (免费版)
LWN.net:
每周内核开发活动摘要 - http://lwn.net/
2.6 版中 API 的变更:
http://lwn.net/Articles/2.6-kernel-api/
将旧版内核的驱动程序移植到 2.6 版:
http://lwn.net/Articles/driver-porting/
KernelTrap:
Linux 内核的最新动态以及开发者访谈
http://kerneltrap.org/
内核新手(KernelNewbies):
为新的内核开发者提供文档和帮助
http://kernelnewbies.org/
Linux USB项目:
http://www.linux-usb.org/
写内核驱动的“不要”(Arjan van de Ven著):
http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf
内核清洁工 (Kernel Janitor):
http://janitor.kernelnewbies.org/
Chinese translated version of Documentation/SubmittingPatches
If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
Chinese maintainer: TripleX Chung <triplex@zh-kernel.org>
---------------------------------------------------------------------
Documentation/SubmittingPatches 的中文翻译
如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文
交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题,请联系中文版维护者。
中文版维护者: 钟宇 TripleX Chung <triplex@zh-kernel.org>
中文版翻译者: 钟宇 TripleX Chung <triplex@zh-kernel.org>
中文版校译者: 李阳 Li Yang <leo@zh-kernel.org>
王聪 Wang Cong <xiyou.wangcong@gmail.com>
以下为正文
---------------------------------------------------------------------
如何让你的改动进入内核
或者
获得亲爱的 Linus Torvalds 的关注和处理
----------------------------------
对于想要将改动提交到 Linux 内核的个人或者公司来说,如果不熟悉“规矩”,
提交的流程会让人畏惧。本文档收集了一系列建议,这些建议可以大大的提高你
的改动被接受的机会。
阅读 Documentation/SubmitChecklist 来获得在提交代码前需要检查的项目的列
表。如果你在提交一个驱动程序,那么同时阅读一下
Documentation/SubmittingDrivers 。
--------------------------
第一节 - 创建并发送你的改动
--------------------------
1) "diff -up"
-----------
使用 "diff -up" 或者 "diff -uprN" 来创建补丁。
所有内核的改动,都是以补丁的形式呈现的,补丁由 diff(1) 生成。创建补丁的
时候,要确认它是以 "unified diff" 格式创建的,这种格式由 diff(1) 的 '-u'
参数生成。而且,请使用 '-p' 参数,那样会显示每个改动所在的C函数,使得
产生的补丁容易读得多。补丁应该基于内核源代码树的根目录,而不是里边的任
何子目录。
为一个单独的文件创建补丁,一般来说这样做就够了:
SRCTREE= linux-2.6
MYFILE= drivers/net/mydriver.c
cd $SRCTREE
cp $MYFILE $MYFILE.orig
vi $MYFILE # make your change
cd ..
diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
为多个文件创建补丁,你可以解开一个没有修改过的内核源代码树,然后和你自
己的代码树之间做 diff 。例如:
MYSRC= /devel/linux-2.6
tar xvfz linux-2.6.12.tar.gz
mv linux-2.6.12 linux-2.6.12-vanilla
diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
linux-2.6.12-vanilla $MYSRC > /tmp/patch
"dontdiff" 是内核在编译的时候产生的文件的列表,列表中的文件在 diff(1)
产生的补丁里会被跳过。"dontdiff" 文件被包含在2.6.12和之后版本的内核源代
码树中。对于更早的内核版本,你可以从
<http://www.xenotime.net/linux/doc/dontdiff> 获取它。
确定你的补丁里没有包含任何不属于这次补丁提交的额外文件。记得在用diff(1)
生成补丁之后,审阅一次补丁,以确保准确。
如果你的改动很散乱,你应该研究一下如何将补丁分割成独立的部分,将改动分
割成一系列合乎逻辑的步骤。这样更容易让其他内核开发者审核,如果你想你的
补丁被接受,这是很重要的。下面这些脚本能够帮助你做这件事情:
Quilt:
http://savannah.nongnu.org/projects/quilt
Andrew Morton 的补丁脚本:
http://www.zip.com.au/~akpm/linux/patches/
作为这些脚本的替代,quilt 是值得推荐的补丁管理工具(看上面的链接)。
2)描述你的改动。
描述你的改动包含的技术细节。
要多具体就写多具体。最糟糕的描述可能是像下面这些语句:“更新了某驱动程
序”,“修正了某驱动程序的bug”,或者“这个补丁包含了某子系统的修改,请
使用。”
如果你的描述开始变长,这表示你也许需要拆分你的补丁了,请看第3小节,
继续。
3)拆分你的改动
将改动拆分,逻辑类似的放到同一个补丁文件里。
例如,如果你的改动里同时有bug修正和性能优化,那么把这些改动才分到两个或
者更多的补丁文件中。如果你的改动包含对API的修改,并且修改了驱动程序来适
应这些新的API,那么把这些修改分成两个补丁。
另一方面,如果你将一个单独的改动做成多个补丁文件,那么将它们合并成一个
单独的补丁文件。这样一个逻辑上单独的改动只被包含在一个补丁文件里。
如果有一个补丁依赖另外一个补丁来完成它的改动,那没问题。简单的在你的补
丁描述里指出“这个补丁依赖某补丁”就好了。
如果你不能将补丁浓缩成更少的文件,那么每次大约发送出15个,然后等待审查
和整合。
4)选择 e-mail 的收件人
看一遍 MAINTAINERS 文件和源代码,看看你所的改动所在的内核子系统有没有指
定的维护者。如果有,给他们发e-mail。
如果没有找到维护者,或者维护者没有反馈,将你的补丁发送到内核开发者主邮
件列表 linux-kernel@vger.kernel.org。大部分的内核开发者都跟踪这个邮件列
表,可以评价你的改动。
每次不要发送超过15个补丁到 vger 邮件列表!!!
Linus Torvalds 是决定改动能否进入 Linux 内核的最终裁决者。他的 e-mail
地址是 <torvalds@linux-foundation.org> 。他收到的 e-mail 很多,所以一般
的说,最好别给他发 e-mail。
那些修正bug,“显而易见”的修改或者是类似的只需要很少讨论的补丁可以直接
发送或者CC给Linus。那些需要讨论或者没有很清楚的好处的补丁,一般先发送到
linux-kernel邮件列表。只有当补丁被讨论得差不多了,才提交给Linus。
5)选择CC( e-mail 抄送)列表
除非你有理由不这样做,否则CC linux-kernel@vger.kernel.org。
除了 Linus 之外,其他内核开发者也需要注意到你的改动,这样他们才能评论你
的改动并提供代码审查和建议。linux-kernel 是 Linux 内核开发者主邮件列表
。其它的邮件列表为特定的子系统提供服务,比如 USB,framebuffer 设备,虚
拟文件系统,SCSI 子系统,等等。查看 MAINTAINERS 文件来获得和你的改动有
关的邮件列表。
Majordomo lists of VGER.KERNEL.ORG at:
<http://vger.kernel.org/vger-lists.html>
如果改动影响了用户空间和内核之间的接口,请给 MAN-PAGES 的维护者(列在
MAITAINERS 文件里的)发送一个手册页(man-pages)补丁,或者至少通知一下改
变,让一些信息有途径进入手册页。
即使在第四步的时候,维护者没有作出回应,也要确认在修改他们的代码的时候
,一直将维护者拷贝到CC列表中。
对于小的补丁,你也许会CC到 Adrian Bunk 管理的搜集琐碎补丁的邮件列表
(Trivial Patch Monkey)trivial@kernel.org,那里专门收集琐碎的补丁。下面这样
的补丁会被看作“琐碎的”补丁:
文档的拼写修正。
修正会影响到 grep(1) 的拼写。
警告信息修正(频繁的打印无用的警告是不好的。)
编译错误修正(代码逻辑的确是对的,只是编译有问题。)
运行时修正(只要真的修正了错误。)
移除使用了被废弃的函数/宏的代码(例如 check_region。)
联系方式和文档修正。
用可移植的代码替换不可移植的代码(即使在体系结构相关的代码中,既然有
人拷贝,只要它是琐碎的)
任何文件的作者/维护者对该文件的改动(例如 patch monkey 在重传模式下)
URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
(译注,关于“琐碎补丁”的一些说明:因为原文的这一部分写得比较简单,所以不得不
违例写一下译注。"trivial"这个英文单词的本意是“琐碎的,不重要的。”但是在这里
有稍微有一些变化,例如对一些明显的NULL指针的修正,属于运行时修正,会被归类
到琐碎补丁里。虽然NULL指针的修正很重要,但是这样的修正往往很小而且很容易得到
检验,所以也被归入琐碎补丁。琐碎补丁更精确的归类应该是
“simple, localized & easy to verify”,也就是说简单的,局部的和易于检验的。
trivial@kernel.org邮件列表的目的是针对这样的补丁,为提交者提供一个中心,来
降低提交的门槛。)
6)没有 MIME 编码,没有链接,没有压缩,没有附件,只有纯文本。
Linus 和其他的内核开发者需要阅读和评论你提交的改动。对于内核开发者来说
,可以“引用”你的改动很重要,使用一般的 e-mail 工具,他们就可以在你的
代码的任何位置添加评论。
因为这个原因,所有的提交的补丁都是 e-mail 中“内嵌”的。
警告:如果你使用剪切-粘贴你的补丁,小心你的编辑器的自动换行功能破坏你的
补丁。
不要将补丁作为 MIME 编码的附件,不管是否压缩。很多流行的 e-mail 软件不
是任何时候都将 MIME 编码的附件当作纯文本发送的,这会使得别人无法在你的
代码中加评论。另外,MIME 编码的附件会让 Linus 多花一点时间来处理,这就
降低了你的改动被接受的可能性。
警告:一些邮件软件,比如 Mozilla 会将你的信息以如下格式发送:
---- 邮件头 ----
Content-Type: text/plain; charset=us-ascii; format=flowed
---- 邮件头 ----
问题在于 “format=flowed” 会让接收端的某些邮件软件将邮件中的制表符替换
成空格以及做一些类似的替换。这样,你发送的时候看起来没问题的补丁就被破
坏了。
要修正这个问题,只需要将你的 mozilla 的 defaults/pref/mailnews.js 文件
里的
pref("mailnews.send_plaintext_flowed", false); // RFC 2646=======
修改成
pref("mailnews.display.disable_format_flowed_support", true);
就可以了。
7) e-mail 的大小
给 Linus 发送补丁的时候,永远按照第6小节说的做。
大的改动对邮件列表不合适,对某些维护者也不合适。如果你的补丁,在不压缩
的情况下,超过了40kB,那么你最好将补丁放在一个能通过 internet 访问的服
务器上,然后用指向你的补丁的 URL 替代。
8) 指出你的内核版本
在标题和在补丁的描述中,指出补丁对应的内核的版本,是很重要的。
如果补丁不能干净的在最新版本的内核上打上,Linus 是不会接受它的。
9) 不要气馁,继续提交。
当你提交了改动以后,耐心地等待。如果 Linus 喜欢你的改动并且同意它,那么
它将在下一个内核发布版本中出现。
然而,如果你的改动没有出现在下一个版本的内核中,可能有若干原因。减少那
些原因,修正错误,重新提交更新后的改动,是你自己的工作。
Linus不给出任何评论就“丢弃”你的补丁是常见的事情。在系统中这样的事情很
平常。如果他没有接受你的补丁,也许是由于以下原本:
* 你的补丁不能在最新版本的内核上干净的打上。
* 你的补丁在 linux-kernel 邮件列表中没有得到充分的讨论。
* 风格问题(参照第2小节)
* 邮件格式问题(重读本节)
* 你的改动有技术问题。
* 他收到了成吨的 e-mail,而你的在混乱中丢失了。
* 你让人为难。
有疑问的时候,在 linux-kernel 邮件列表上请求评论。
10) 在标题上加上 PATCH 的字样
Linus 和 linux-kernel 邮件列表的 e-mail 流量都很高,一个通常的约定是标
题行以 [PATCH] 开头。这样可以让 Linus 和其他内核开发人员可以从 e-mail
的讨论中很轻易的将补丁分辨出来。
11)为你的工作签名
为了加强对谁做了何事的追踪,尤其是对那些透过好几层的维护者的补丁,我们
建议在发送出去的补丁上加一个 “sign-off” 的过程。
"sign-off" 是在补丁的注释的最后的简单的一行文字,认证你编写了它或者其他
人有权力将它作为开放源代码的补丁传递。规则很简单:如果你能认证如下信息
开发者来源证书 1.1
对于本项目的贡献,我认证如下信息:
(a)这些贡献是完全或者部分的由我创建,我有权利以文件中指出
的开放源代码许可证提交它;或者
(b)这些贡献基于以前的工作,据我所知,这些以前的工作受恰当的开放
源代码许可证保护,而且,根据许可证,我有权提交修改后的贡献,
无论是完全还是部分由我创造,这些贡献都使用同一个开放源代码许可证
(除非我被允许用其它的许可证),正如文件中指出的;或者
(c)这些贡献由认证(a),(b)或者(c)的人直接提供给我,而
且我没有修改它。
(d)我理解并同意这个项目和贡献是公开的,贡献的记录(包括我
一起提交的个人记录,包括 sign-off )被永久维护并且可以和这个项目
或者开放源代码的许可证同步地再发行。
那么加入这样一行:
Signed-off-by: Random J Developer <random@developer.example.org>
使用你的真名(抱歉,不能使用假名或者匿名。)
有人在最后加上标签。现在这些东西会被忽略,但是你可以这样做,来标记公司
内部的过程,或者只是指出关于 sign-off 的一些特殊细节。
12)标准补丁格式
标准的补丁,标题行是:
Subject: [PATCH 001/123] 子系统:一句话概述
标准补丁的信体存在如下部分:
- 一个 "from" 行指出补丁作者。
- 一个空行
- 说明的主体,这些说明文字会被拷贝到描述该补丁的永久改动记录里。
- 一个由"---"构成的标记行
- 不合适放到改动记录里的额外的注解。
- 补丁本身(diff 输出)
标题行的格式,使得对标题行按字母序排序非常的容易 - 很多 e-mail 客户端都
可以支持 - 因为序列号是用零填充的,所以按数字排序和按字母排序是一样的。
e-mail 标题中的“子系统”标识哪个内核子系统将被打补丁。
e-mail 标题中的“一句话概述”扼要的描述 e-mail 中的补丁。“一句话概述”
不应该是一个文件名。对于一个补丁系列(“补丁系列”指一系列的多个相关补
丁),不要对每个补丁都使用同样的“一句话概述”。
记住 e-mail 的“一句话概述”会成为该补丁的全局唯一标识。它会蔓延到 git
的改动记录里。然后“一句话概述”会被用在开发者的讨论里,用来指代这个补
丁。用户将希望通过 google 来搜索"一句话概述"来找到那些讨论这个补丁的文
章。
一些标题的例子:
Subject: [patch 2/5] ext2: improve scalability of bitmap searching
Subject: [PATCHv2 001/207] x86: fix eflags tracking
"from" 行是信体里的最上面一行,具有如下格式:
From: Original Author <author@example.com>
"from" 行指明在永久改动日志里,谁会被确认为作者。如果没有 "from" 行,那
么邮件头里的 "From: " 行会被用来决定改动日志中的作者。
说明的主题将会被提交到永久的源代码改动日志里,因此对那些早已经不记得和
这个补丁相关的讨论细节的有能力的读者来说,是有意义的。
"---" 标记行对于补丁处理工具要找到哪里是改动日志信息的结束,是不可缺少
的。
对于 "---" 标记之后的额外注解,一个好的用途就是用来写 diffstat,用来显
示修改了什么文件和每个文件都增加和删除了多少行。diffstat 对于比较大的补
丁特别有用。其余那些只是和时刻或者开发者相关的注解,不合适放到永久的改
动日志里的,也应该放这里。
使用 diffstat的选项 "-p 1 -w 70" 这样文件名就会从内核源代码树的目录开始
,不会占用太宽的空间(很容易适合80列的宽度,也许会有一些缩进。)
在后面的参考资料中能看到适当的补丁格式的更多细节。
-------------------------------
第二节 提示,建议和诀窍
-------------------------------
本节包含很多和提交到内核的代码有关的通常的"规则"。事情永远有例外...但是
你必须真的有好的理由这样做。你可以把本节叫做Linus的计算机科学入门课。
1) 读 Document/CodingStyle
Nuff 说过,如果你的代码和这个偏离太多,那么它有可能会被拒绝,没有更多的
审查,没有更多的评价。
2) #ifdef 是丑陋的
混杂了 ifdef 的代码难以阅读和维护。别这样做。作为替代,将你的 ifdef 放
在头文件里,有条件地定义 "static inline" 函数,或者宏,在代码里用这些东
西。让编译器把那些"空操作"优化掉。
一个简单的例子,不好的代码:
dev = alloc_etherdev (sizeof(struct funky_private));
if (!dev)
return -ENODEV;
#ifdef CONFIG_NET_FUNKINESS
init_funky_net(dev);
#endif
清理后的例子:
(头文件里)
#ifndef CONFIG_NET_FUNKINESS
static inline void init_funky_net (struct net_device *d) {}
#endif
(代码文件里)
dev = alloc_etherdev (sizeof(struct funky_private));
if (!dev)
return -ENODEV;
init_funky_net(dev);
3) 'static inline' 比宏好
Static inline 函数相比宏来说,是好得多的选择。Static inline 函数提供了
类型安全,没有长度限制,没有格式限制,在 gcc 下开销和宏一样小。
宏只在 static inline 函数不是最优的时候[在 fast paths 里有很少的独立的
案例],或者不可能用 static inline 函数的时候[例如字符串分配]。
应该用 'static inline' 而不是 'static __inline__', 'extern inline' 和
'extern __inline__' 。
4) 不要过度设计
不要试图预计模糊的未来事情,这些事情也许有用也许没有用:"让事情尽可能的
简单,而不是更简单"。
----------------
第三节 参考文献
----------------
Andrew Morton, "The perfect patch" (tpp).
<http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt>
Jeff Garzik, "Linux kernel patch submission format".
<http://linux.yyz.us/patch-format.html>
Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
<http://www.kroah.com/log/2005/03/31/>
<http://www.kroah.com/log/2005/07/08/>
<http://www.kroah.com/log/2005/10/19/>
<http://www.kroah.com/log/2006/01/11/>
NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
<http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
Kernel Documentation/CodingStyle:
<http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle>
Linus Torvalds's mail on the canonical patch format:
<http://lkml.org/lkml/2005/4/7/183>
--
此差异已折叠。
此差异已折叠。
Chinese translated version of Documentation/stable_kernel_rules.txt
If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.
Chinese maintainer: TripleX Chung <triplex@zh-kernel.org>
---------------------------------------------------------------------
Documentation/stable_kernel_rules.txt 的中文翻译
如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文
交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题,请联系中文版维护者。
中文版维护者: 钟宇 TripleX Chung <triplex@zh-kernel.org>
中文版翻译者: 钟宇 TripleX Chung <triplex@zh-kernel.org>
中文版校译者: 李阳 Li Yang <leo@zh-kernel.org>
Kangkai Yin <e12051@motorola.com>
以下为正文
---------------------------------------------------------------------
关于Linux 2.6稳定版发布,所有你想知道的事情。
关于哪些类型的补丁可以被接收进入稳定版代码树,哪些不可以的规则:
- 必须是显而易见的正确,并且经过测试的。
- 连同上下文,不能大于100行。
- 必须只修正一件事情。
- 必须修正了一个给大家带来麻烦的真正的bug(不是“这也许是一个问题...”
那样的东西)。
- 必须修正带来如下后果的问题:编译错误(对被标记为CONFIG_BROKEN的例外),
内核崩溃,挂起,数据损坏,真正的安全问题,或者一些类似“哦,这不
好”的问题。简短的说,就是一些致命的问题。
- 没有“理论上的竞争条件”,除非能给出竞争条件如何被利用的解释。
- 不能存在任何的“琐碎的”修正(拼写修正,去掉多余空格之类的)。
- 必须被相关子系统的维护者接受。
- 必须遵循Documentation/SubmittingPatches里的规则。
向稳定版代码树提交补丁的过程:
- 在确认了补丁符合以上的规则后,将补丁发送到stable@kernel.org。
- 如果补丁被接受到队列里,发送者会收到一个ACK回复,如果没有被接受,收
到的是NAK回复。回复需要几天的时间,这取决于开发者的时间安排。
- 被接受的补丁会被加到稳定版本队列里,等待其他开发者的审查。
- 安全方面的补丁不要发到这个列表,应该发送到security@kernel.org。
审查周期:
- 当稳定版的维护者决定开始一个审查周期,补丁将被发送到审查委员会,以
及被补丁影响的领域的维护者(除非提交者就是该领域的维护者)并且抄送
到linux-kernel邮件列表。
- 审查委员会有48小时的时间,用来决定给该补丁回复ACK还是NAK。
- 如果委员会中有成员拒绝这个补丁,或者linux-kernel列表上有人反对这个
补丁,并提出维护者和审查委员会之前没有意识到的问题,补丁会从队列中
丢弃。
- 在审查周期结束的时候,那些得到ACK回应的补丁将会被加入到最新的稳定版
发布中,一个新的稳定版发布就此产生。
- 安全性补丁将从内核安全小组那里直接接收到稳定版代码树中,而不是通过
通常的审查周期。请联系内核安全小组以获得关于这个过程的更多细节。
审查委员会:
- 由一些自愿承担这项任务的内核开发者,和几个非志愿的组成。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
...@@ -20,7 +20,6 @@ ...@@ -20,7 +20,6 @@
#include <linux/capability.h> #include <linux/capability.h>
#include <linux/device.h> #include <linux/device.h>
#include <linux/mutex.h> #include <linux/mutex.h>
#include <linux/rtc.h>
#include <asm/rtc.h> #include <asm/rtc.h>
#include <asm/semaphore.h> #include <asm/semaphore.h>
......
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册