apfs/linux-apfs
0
0
Fork 0
mirror of https://github.com/linux-apfs/linux-apfs.git synced 2026-05-01 15:00:59 -07:00
Code Issues Packages Projects Releases Wiki Activity

Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux

Browse Source 
Merge upstream tree in order to reinstate crct10dif.
This commit is contained in:
Herbert Xu
2013-09-07 12:53:35 +10:00
parent ff6f83fc9d b48a97be8e
commit eeca9fad52
4397 changed files with 249238 additions and 171900 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/ABI/stable/sysfs-driver-ib_srp
+7
View File
@@ -54,6 +54,13 @@ Description: Interface for making ib_srp connect to a new target.
ib_srp. Specifying a value that exceeds cmd_sg_entries is
only safe with partial memory descriptor list support enabled
(allow_ext_sg=1).
* comp_vector, a number in the range 0..n-1 specifying the
MSI-X completion vector. Some HCA's allocate multiple (n)
MSI-X vectors per HCA port. If the IRQ affinity masks of
these interrupts have been configured such that each MSI-X
interrupt is handled by a different CPU then the comp_vector
parameter can be used to spread the SRP completion workload
over multiple CPU's.
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
Date: January 2, 2006
Documentation/ABI/stable/sysfs-module
+7 -3
View File
@@ -4,9 +4,13 @@ Description:
/sys/module/MODULENAME
The name of the module that is in the kernel. This
module name will show up either if the module is built
directly into the kernel, or if it is loaded as a
dynamic module.
module name will always show up if the module is loaded as a
dynamic module. If it is built directly into the kernel, it
will only show up if it has a version or at least one
parameter.
Note: The conditions of creation in the built-in case are not
by design and may be removed in the future.
/sys/module/MODULENAME/parameters
This directory contains individual files that are each
Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+1 -1
View File
@@ -29,7 +29,7 @@ Description: Generic performance monitoring events
What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
/sys/devices/cpu/events/PM_BRU_FIN
/sys/devices/cpu/events/PM_BRU_MPRED
/sys/devices/cpu/events/PM_BR_MPRED
/sys/devices/cpu/events/PM_CMPLU_STALL
/sys/devices/cpu/events/PM_CMPLU_STALL_BRU
/sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS
Documentation/ABI/testing/sysfs-class-pwm
+79
View File
@@ -0,0 +1,79 @@
What: /sys/class/pwm/
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
The pwm/ class sub-directory belongs to the Generic PWM
Framework and provides a sysfs interface for using PWM
channels.
What: /sys/class/pwm/pwmchipN/
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
A /sys/class/pwm/pwmchipN directory is created for each
probed PWM controller/chip where N is the base of the
PWM chip.
What: /sys/class/pwm/pwmchipN/npwm
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
The number of PWM channels supported by the PWM chip.
What: /sys/class/pwm/pwmchipN/export
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Exports a PWM channel from the PWM chip for sysfs control.
Value is between 0 and /sys/class/pwm/pwmchipN/npwm - 1.
What: /sys/class/pwm/pwmchipN/unexport
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Unexports a PWM channel.
What: /sys/class/pwm/pwmchipN/pwmX
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
A /sys/class/pwm/pwmchipN/pwmX directory is created for
each exported PWM channel where X is the exported PWM
channel number.
What: /sys/class/pwm/pwmchipN/pwmX/period
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Sets the PWM signal period in nanoseconds.
What: /sys/class/pwm/pwmchipN/pwmX/duty_cycle
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Sets the PWM signal duty cycle in nanoseconds.
What: /sys/class/pwm/pwmchipN/pwmX/polarity
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Sets the output polarity of the PWM signal to "normal" or
"inversed".
What: /sys/class/pwm/pwmchipN/pwmX/enable
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Enable/disable the PWM signal.
0 is disabled
1 is enabled
Documentation/ABI/testing/sysfs-devices-edac
+7 -7
View File
@@ -77,7 +77,7 @@ Description: Read/Write attribute file that controls memory scrubbing.
What: /sys/devices/system/edac/mc/mc*/max_location
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file displays the information about the last
available memory slot in this memory controller. It is used by
@@ -85,7 +85,7 @@ Description: This attribute file displays the information about the last
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/size
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display the size of dimm or rank.
For dimm*/size, this is the size, in MB of the DIMM memory
@@ -96,14 +96,14 @@ Description: This attribute file will display the size of dimm or rank.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_dev_type
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of DRAM device is
being utilized on this DIMM (x1, x2, x4, x8, ...).
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_edac_mode
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of Error detection
and correction is being utilized. For example: S4ECD4ED would
@@ -111,7 +111,7 @@ Description: This attribute file will display what type of Error detection
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_label
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This control file allows this DIMM to have a label assigned
to it. With this label in the module, when errors occur
@@ -126,14 +126,14 @@ Description: This control file allows this DIMM to have a label assigned
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_location
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display the location (csrow/channel,
branch/channel/slot or channel/slot) of the dimm or rank.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_mem_type
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of memory is
currently on this csrow. Normally, either buffered or
Documentation/ABI/testing/sysfs-driver-intel-rapid-start
+21
View File
@@ -0,0 +1,21 @@
What: /sys/bus/acpi/intel-rapid-start/wakeup_events
Date: July 2, 2013
KernelVersion: 3.11
Contact: Matthew Garrett <mjg59@srcf.ucam.org>
Description: An integer representing a set of wakeup events as follows:
1: Wake to enter hibernation when the wakeup timer expires
2: Wake to enter hibernation when the battery reaches a
critical level
These values are ORed together. For example, a value of 3
indicates that the system will wake to enter hibernation when
either the wakeup timer expires or the battery reaches a
critical level.
What: /sys/bus/acpi/intel-rapid-start/wakeup_time
Date: July 2, 2013
KernelVersion: 3.11
Contact: Matthew Garrett <mjg59@srcf.ucam.org>
Description: An integer representing the length of time the system will
remain asleep before waking up to enter hibernation.
This value is in minutes.
Documentation/ABI/testing/sysfs-driver-xen-blkback
+17
View File
@@ -0,0 +1,17 @@
What: /sys/module/xen_blkback/parameters/max_buffer_pages
Date: March 2013
KernelVersion: 3.11
Contact: Roger Pau Monné <roger.pau@citrix.com>
Description:
Maximum number of free pages to keep in each block
backend buffer.
What: /sys/module/xen_blkback/parameters/max_persistent_grants
Date: March 2013
KernelVersion: 3.11
Contact: Roger Pau Monné <roger.pau@citrix.com>
Description:
Maximum number of grants to map persistently in
blkback. If the frontend tries to use more than
max_persistent_grants, the LRU kicks in and starts
removing 5% of max_persistent_grants every 100ms.
Documentation/ABI/testing/sysfs-driver-xen-blkfront
+10
View File
@@ -0,0 +1,10 @@
What: /sys/module/xen_blkfront/parameters/max
Date: June 2013
KernelVersion: 3.11
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Maximum number of segments that the frontend will negotiate
with the backend for indirect descriptors. The default value
is 32 - higher value means more potential throughput but more
memory usage. The backend picks the minimum of the frontend
and its default backend value.
Documentation/DocBook/80211.tmpl
+5 -8
View File
@@ -127,14 +127,11 @@
!Finclude/net/cfg80211.h cfg80211_ibss_params
!Finclude/net/cfg80211.h cfg80211_connect_params
!Finclude/net/cfg80211.h cfg80211_pmksa
!Finclude/net/cfg80211.h cfg80211_send_rx_auth
!Finclude/net/cfg80211.h cfg80211_send_auth_timeout
!Finclude/net/cfg80211.h cfg80211_send_rx_assoc
!Finclude/net/cfg80211.h cfg80211_send_assoc_timeout
!Finclude/net/cfg80211.h cfg80211_send_deauth
!Finclude/net/cfg80211.h __cfg80211_send_deauth
!Finclude/net/cfg80211.h cfg80211_send_disassoc
!Finclude/net/cfg80211.h __cfg80211_send_disassoc
!Finclude/net/cfg80211.h cfg80211_rx_mlme_mgmt
!Finclude/net/cfg80211.h cfg80211_auth_timeout
!Finclude/net/cfg80211.h cfg80211_rx_assoc_resp
!Finclude/net/cfg80211.h cfg80211_assoc_timeout
!Finclude/net/cfg80211.h cfg80211_tx_mlme_mgmt
!Finclude/net/cfg80211.h cfg80211_ibss_joined
!Finclude/net/cfg80211.h cfg80211_connect_result
!Finclude/net/cfg80211.h cfg80211_roamed
Documentation/DocBook/device-drivers.tmpl
+2
View File
@@ -126,6 +126,8 @@ X!Edrivers/base/interface.c
</sect1>
<sect1><title>Device Drivers DMA Management</title>
!Edrivers/base/dma-buf.c
!Edrivers/base/reservation.c
!Iinclude/linux/reservation.h
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c
</sect1>
Documentation/DocBook/drm.tmpl
+219 -52
View File
@@ -186,11 +186,12 @@
<varlistentry>
<term>DRIVER_HAVE_IRQ</term><term>DRIVER_IRQ_SHARED</term>
<listitem><para>
DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler. The
DRM core will automatically register an interrupt handler when the
flag is set. DRIVER_IRQ_SHARED indicates whether the device &amp;
handler support shared IRQs (note that this is required of PCI
drivers).
DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler
managed by the DRM Core. The core will support simple IRQ handler
installation when the flag is set. The installation process is
described in <xref linkend="drm-irq-registration"/>.</para>
<para>DRIVER_IRQ_SHARED indicates whether the device &amp; handler
support shared IRQs (note that this is required of PCI drivers).
</para></listitem>
</varlistentry>
<varlistentry>
@@ -344,50 +345,71 @@ char *date;</synopsis>
The DRM core tries to facilitate IRQ handler registration and
unregistration by providing <function>drm_irq_install</function> and
<function>drm_irq_uninstall</function> functions. Those functions only
support a single interrupt per device.
</para>
<!--!Fdrivers/char/drm/drm_irq.c drm_irq_install-->
<para>
Both functions get the device IRQ by calling
<function>drm_dev_to_irq</function>. This inline function will call a
bus-specific operation to retrieve the IRQ number. For platform devices,
<function>platform_get_irq</function>(..., 0) is used to retrieve the
IRQ number.
</para>
<para>
<function>drm_irq_install</function> starts by calling the
<methodname>irq_preinstall</methodname> driver operation. The operation
is optional and must make sure that the interrupt will not get fired by
clearing all pending interrupt flags or disabling the interrupt.
</para>
<para>
The IRQ will then be requested by a call to
<function>request_irq</function>. If the DRIVER_IRQ_SHARED driver
feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
requested.
</para>
<para>
The IRQ handler function must be provided as the mandatory irq_handler
driver operation. It will get passed directly to
<function>request_irq</function> and thus has the same prototype as all
IRQ handlers. It will get called with a pointer to the DRM device as the
second argument.
</para>
<para>
Finally the function calls the optional
<methodname>irq_postinstall</methodname> driver operation. The operation
usually enables interrupts (excluding the vblank interrupt, which is
enabled separately), but drivers may choose to enable/disable interrupts
at a different time.
</para>
<para>
<function>drm_irq_uninstall</function> is similarly used to uninstall an
IRQ handler. It starts by waking up all processes waiting on a vblank
interrupt to make sure they don't hang, and then calls the optional
<methodname>irq_uninstall</methodname> driver operation. The operation
must disable all hardware interrupts. Finally the function frees the IRQ
by calling <function>free_irq</function>.
support a single interrupt per device, devices that use more than one
IRQs need to be handled manually.
</para>
<sect4>
<title>Managed IRQ Registration</title>
<para>
Both the <function>drm_irq_install</function> and
<function>drm_irq_uninstall</function> functions get the device IRQ by
calling <function>drm_dev_to_irq</function>. This inline function will
call a bus-specific operation to retrieve the IRQ number. For platform
devices, <function>platform_get_irq</function>(..., 0) is used to
retrieve the IRQ number.
</para>
<para>
<function>drm_irq_install</function> starts by calling the
<methodname>irq_preinstall</methodname> driver operation. The operation
is optional and must make sure that the interrupt will not get fired by
clearing all pending interrupt flags or disabling the interrupt.
</para>
<para>
The IRQ will then be requested by a call to
<function>request_irq</function>. If the DRIVER_IRQ_SHARED driver
feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
requested.
</para>
<para>
The IRQ handler function must be provided as the mandatory irq_handler
driver operation. It will get passed directly to
<function>request_irq</function> and thus has the same prototype as all
IRQ handlers. It will get called with a pointer to the DRM device as the
second argument.
</para>
<para>
Finally the function calls the optional
<methodname>irq_postinstall</methodname> driver operation. The operation
usually enables interrupts (excluding the vblank interrupt, which is
enabled separately), but drivers may choose to enable/disable interrupts
at a different time.
</para>
<para>
<function>drm_irq_uninstall</function> is similarly used to uninstall an
IRQ handler. It starts by waking up all processes waiting on a vblank
interrupt to make sure they don't hang, and then calls the optional
<methodname>irq_uninstall</methodname> driver operation. The operation
must disable all hardware interrupts. Finally the function frees the IRQ
by calling <function>free_irq</function>.
</para>
</sect4>
<sect4>
<title>Manual IRQ Registration</title>
<para>
Drivers that require multiple interrupt handlers can't use the managed
IRQ registration functions. In that case IRQs must be registered and
unregistered manually (usually with the <function>request_irq</function>
and <function>free_irq</function> functions, or their devm_* equivalent).
</para>
<para>
When manually registering IRQs, drivers must not set the DRIVER_HAVE_IRQ
driver feature flag, and must not provide the
<methodname>irq_handler</methodname> driver operation. They must set the
<structname>drm_device</structname> <structfield>irq_enabled</structfield>
field to 1 upon registration of the IRQs, and clear it to 0 after
unregistering the IRQs.
</para>
</sect4>
</sect3>
<sect3>
<title>Memory Manager Initialization</title>
@@ -1213,6 +1235,15 @@ int max_width, max_height;</synopsis>
<sect4>
<title>Miscellaneous</title>
<itemizedlist>
<listitem>
<synopsis>void (*set_property)(struct drm_crtc *crtc,
struct drm_property *property, uint64_t value);</synopsis>
<para>
Set the value of the given CRTC property to
<parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
for more information about properties.
</para>
</listitem>
<listitem>
<synopsis>void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
uint32_t start, uint32_t size);</synopsis>
@@ -1363,6 +1394,15 @@ int max_width, max_height;</synopsis>
<xref linkend="drm-kms-init"/>.
</para>
</listitem>
<listitem>
<synopsis>void (*set_property)(struct drm_plane *plane,
struct drm_property *property, uint64_t value);</synopsis>
<para>
Set the value of the given plane property to
<parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
for more information about properties.
</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
@@ -1571,6 +1611,15 @@ int max_width, max_height;</synopsis>
<sect4>
<title>Miscellaneous</title>
<itemizedlist>
<listitem>
<synopsis>void (*set_property)(struct drm_connector *connector,
struct drm_property *property, uint64_t value);</synopsis>
<para>
Set the value of the given connector property to
<parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
for more information about properties.
</para>
</listitem>
<listitem>
<synopsis>void (*destroy)(struct drm_connector *connector);</synopsis>
<para>
@@ -1846,10 +1895,6 @@ void intel_crt_init(struct drm_device *dev)
<synopsis>bool (*mode_fixup)(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);</synopsis>
<note><para>
FIXME: The mode argument be const, but the i915 driver modifies
mode-&gt;clock in <function>intel_dp_mode_fixup</function>.
</para></note>
<para>
Let encoders adjust the requested mode or reject it completely. This
operation returns true if the mode is accepted (possibly after being
@@ -2161,6 +2206,128 @@ void intel_crt_init(struct drm_device *dev)
<title>EDID Helper Functions Reference</title>
!Edrivers/gpu/drm/drm_edid.c
</sect2>
<sect2>
<title>Rectangle Utilities Reference</title>
!Pinclude/drm/drm_rect.h rect utils
!Iinclude/drm/drm_rect.h
!Edrivers/gpu/drm/drm_rect.c
</sect2>
</sect1>
<!-- Internals: kms properties -->
<sect1 id="drm-kms-properties">
<title>KMS Properties</title>
<para>
Drivers may need to expose additional parameters to applications than
those described in the previous sections. KMS supports attaching
properties to CRTCs, connectors and planes and offers a userspace API to
list, get and set the property values.
</para>
<para>
Properties are identified by a name that uniquely defines the property
purpose, and store an associated value. For all property types except blob
properties the value is a 64-bit unsigned integer.
</para>
<para>
KMS differentiates between properties and property instances. Drivers
first create properties and then create and associate individual instances
of those properties to objects. A property can be instantiated multiple
times and associated with different objects. Values are stored in property
instances, and all other property information are stored in the propery
and shared between all instances of the property.
</para>
<para>
Every property is created with a type that influences how the KMS core
handles the property. Supported property types are
<variablelist>
<varlistentry>
<term>DRM_MODE_PROP_RANGE</term>
<listitem><para>Range properties report their minimum and maximum
admissible values. The KMS core verifies that values set by
application fit in that range.</para></listitem>
</varlistentry>
<varlistentry>
<term>DRM_MODE_PROP_ENUM</term>
<listitem><para>Enumerated properties take a numerical value that
ranges from 0 to the number of enumerated values defined by the
property minus one, and associate a free-formed string name to each
value. Applications can retrieve the list of defined value-name pairs
and use the numerical value to get and set property instance values.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRM_MODE_PROP_BITMASK</term>
<listitem><para>Bitmask properties are enumeration properties that
additionally restrict all enumerated values to the 0..63 range.
Bitmask property instance values combine one or more of the
enumerated bits defined by the property.</para></listitem>
</varlistentry>
<varlistentry>
<term>DRM_MODE_PROP_BLOB</term>
<listitem><para>Blob properties store a binary blob without any format
restriction. The binary blobs are created as KMS standalone objects,
and blob property instance values store the ID of their associated
blob object.</para>
<para>Blob properties are only used for the connector EDID property
and cannot be created by drivers.</para></listitem>
</varlistentry>
</variablelist>
</para>
<para>
To create a property drivers call one of the following functions depending
on the property type. All property creation functions take property flags
and name, as well as type-specific arguments.
<itemizedlist>
<listitem>
<synopsis>struct drm_property *drm_property_create_range(struct drm_device *dev, int flags,
const char *name,
uint64_t min, uint64_t max);</synopsis>
<para>Create a range property with the given minimum and maximum
values.</para>
</listitem>
<listitem>
<synopsis>struct drm_property *drm_property_create_enum(struct drm_device *dev, int flags,
const char *name,
const struct drm_prop_enum_list *props,
int num_values);</synopsis>
<para>Create an enumerated property. The <parameter>props</parameter>
argument points to an array of <parameter>num_values</parameter>
value-name pairs.</para>
</listitem>
<listitem>
<synopsis>struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
int flags, const char *name,
const struct drm_prop_enum_list *props,
int num_values);</synopsis>
<para>Create a bitmask property. The <parameter>props</parameter>
argument points to an array of <parameter>num_values</parameter>
value-name pairs.</para>
</listitem>
</itemizedlist>
</para>
<para>
Properties can additionally be created as immutable, in which case they
will be read-only for applications but can be modified by the driver. To
create an immutable property drivers must set the DRM_MODE_PROP_IMMUTABLE
flag at property creation time.
</para>
<para>
When no array of value-name pairs is readily available at property
creation time for enumerated or range properties, drivers can create
the property using the <function>drm_property_create</function> function
and manually add enumeration value-name pairs by calling the
<function>drm_property_add_enum</function> function. Care must be taken to
properly specify the property type through the <parameter>flags</parameter>
argument.
</para>
<para>
After creating properties drivers can attach property instances to CRTC,
connector and plane objects by calling the
<function>drm_object_attach_property</function>. The function takes a
pointer to the target object, a pointer to the previously created property
and an initial instance value.
</para>
</sect1>
<!-- Internals: vertical blanking -->
Documentation/DocBook/media/v4l/compat.xml
+12 -2
View File
@@ -2254,7 +2254,7 @@ video encoding.</para>
<orderedlist>
<listitem>
<para>The <constant>VIDIOC_G_CHIP_IDENT</constant> ioctl was renamed
to <constant>VIDIOC_G_CHIP_IDENT_OLD</constant> and &VIDIOC-DBG-G-CHIP-IDENT;
to <constant>VIDIOC_G_CHIP_IDENT_OLD</constant> and <constant>VIDIOC_DBG_G_CHIP_IDENT</constant>
was introduced in its place. The old struct <structname>v4l2_chip_ident</structname>
was renamed to <structname id="v4l2-chip-ident-old">v4l2_chip_ident_old</structname>.</para>
</listitem>
@@ -2513,6 +2513,16 @@ that used it. It was originally scheduled for removal in 2.6.35.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.11</title>
<orderedlist>
<listitem>
<para>Remove obsolete <constant>VIDIOC_DBG_G_CHIP_IDENT</constant> ioctl.
</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>
@@ -2596,7 +2606,7 @@ and may change in the future.</para>
ioctls.</para>
</listitem>
<listitem>
<para>&VIDIOC-DBG-G-CHIP-IDENT; ioctl.</para>
<para>&VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
</listitem>
<listitem>
<para>&VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and
Documentation/DocBook/media/v4l/v4l2.xml
+9 -2
View File
@@ -140,6 +140,14 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>3.11</revnumber>
<date>2013-05-26</date>
<authorinitials>hv</authorinitials>
<revremark>Remove obsolete VIDIOC_DBG_G_CHIP_IDENT ioctl.
</revremark>
</revision>
<revision>
<revnumber>3.10</revnumber>
<date>2013-03-25</date>
@@ -493,7 +501,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.10</subtitle>
<subtitle>Revision 3.11</subtitle>
<chapter id="common">
&sub-common;
@@ -547,7 +555,6 @@ and discussions on the V4L mailing list.</revremark>
<!-- All ioctls go here. -->
&sub-create-bufs;
&sub-cropcap;
&sub-dbg-g-chip-ident;
&sub-dbg-g-chip-info;
&sub-dbg-g-register;
&sub-decoder-cmd;
Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml
-271
View File
@@ -1,271 +0,0 @@
<refentry id="vidioc-dbg-g-chip-ident">
<refmeta>
<refentrytitle>ioctl VIDIOC_DBG_G_CHIP_IDENT</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_DBG_G_CHIP_IDENT</refname>
<refpurpose>Identify the chips on a TV card</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_dbg_chip_ident
*<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_DBG_G_CHIP_IDENT</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link
linkend="experimental">experimental</link> interface and may change in
the future.</para>
</note>
<para>For driver debugging purposes this ioctl allows test
applications to query the driver about the chips present on the TV
card. Regular applications must not use it. When you found a chip
specific bug, please contact the linux-media mailing list (&v4l-ml;)
so it can be fixed.</para>
<para>To query the driver applications must initialize the
<structfield>match.type</structfield> and
<structfield>match.addr</structfield> or <structfield>match.name</structfield>
fields of a &v4l2-dbg-chip-ident;
and call <constant>VIDIOC_DBG_G_CHIP_IDENT</constant> with a pointer to
this structure. On success the driver stores information about the
selected chip in the <structfield>ident</structfield> and
<structfield>revision</structfield> fields. On failure the structure
remains unchanged.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_HOST</constant>,
<structfield>match.addr</structfield> selects the nth non-&i2c; chip
on the TV card. You can enumerate all chips by starting at zero and
incrementing <structfield>match.addr</structfield> by one until
<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> fails with an &EINVAL;.
The number zero always selects the host chip, &eg; the chip connected
to the PCI or USB bus.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>,
<structfield>match.name</structfield> contains the I2C driver name.
For instance
<constant>"saa7127"</constant> will match any chip
supported by the saa7127 driver, regardless of its &i2c; bus address.
When multiple chips supported by the same driver are present, the
ioctl will return <constant>V4L2_IDENT_AMBIGUOUS</constant> in the
<structfield>ident</structfield> field.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_I2C_ADDR</constant>,
<structfield>match.addr</structfield> selects a chip by its 7 bit
&i2c; bus address.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_AC97</constant>,
<structfield>match.addr</structfield> selects the nth AC97 chip
on the TV card. You can enumerate all chips by starting at zero and
incrementing <structfield>match.addr</structfield> by one until
<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> fails with an &EINVAL;.</para>
<para>On success, the <structfield>ident</structfield> field will
contain a chip ID from the Linux
<filename>media/v4l2-chip-ident.h</filename> header file, and the
<structfield>revision</structfield> field will contain a driver
specific value, or zero if no particular revision is associated with
this chip.</para>
<para>When the driver could not identify the selected chip,
<structfield>ident</structfield> will contain
<constant>V4L2_IDENT_UNKNOWN</constant>. When no chip matched
the ioctl will succeed but the
<structfield>ident</structfield> field will contain
<constant>V4L2_IDENT_NONE</constant>. If multiple chips matched,
<structfield>ident</structfield> will contain
<constant>V4L2_IDENT_AMBIGUOUS</constant>. In all these cases the
<structfield>revision</structfield> field remains unchanged.</para>
<para>This ioctl is optional, not all drivers may support it. It
was introduced in Linux 2.6.21, but the API was changed to the
one described here in 2.6.29.</para>
<para>We recommended the <application>v4l2-dbg</application>
utility over calling this ioctl directly. It is available from the
LinuxTV v4l-dvb repository; see <ulink
url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
access instructions.</para>
<!-- Note for convenience vidioc-dbg-g-register.sgml
contains a duplicate of this table. -->
<table pgwide="1" frame="none" id="ident-v4l2-dbg-match">
<title>struct <structname>v4l2_dbg_match</structname></title>
<tgroup cols="4">
&cs-ustr;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>See <xref linkend="ident-chip-match-types" /> for a list of
possible types.</entry>
</row>
<row>
<entry>union</entry>
<entry>(anonymous)</entry>
</row>
<row>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>addr</structfield></entry>
<entry>Match a chip by this number, interpreted according
to the <structfield>type</structfield> field.</entry>
</row>
<row>
<entry></entry>
<entry>char</entry>
<entry><structfield>name[32]</structfield></entry>
<entry>Match a chip by this name, interpreted according
to the <structfield>type</structfield> field.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="v4l2-dbg-chip-ident">
<title>struct <structname>v4l2_dbg_chip_ident</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>struct v4l2_dbg_match</entry>
<entry><structfield>match</structfield></entry>
<entry>How to match the chip, see <xref linkend="ident-v4l2-dbg-match" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>ident</structfield></entry>
<entry>A chip identifier as defined in the Linux
<filename>media/v4l2-chip-ident.h</filename> header file, or one of
the values from <xref linkend="chip-ids" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>revision</structfield></entry>
<entry>A chip revision, chip and driver specific.</entry>
</row>
</tbody>
</tgroup>
</table>
<!-- Note for convenience vidioc-dbg-g-register.sgml
contains a duplicate of this table. -->
<table pgwide="1" frame="none" id="ident-chip-match-types">
<title>Chip Match Types</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_CHIP_MATCH_BRIDGE</constant></entry>
<entry>0</entry>
<entry>Match the nth chip on the card, zero for the
bridge chip. Does not match sub-devices.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
<entry>1</entry>
<entry>Match an &i2c; chip by its driver name.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
<entry>2</entry>
<entry>Match a chip by its 7 bit &i2c; bus address.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
<entry>3</entry>
<entry>Match the nth anciliary AC97 chip.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
<entry>4</entry>
<entry>Match the nth sub-device. Can't be used with this ioctl.</entry>
</row>
</tbody>
</tgroup>
</table>
<!-- This is an anonymous enum in media/v4l2-chip-ident.h. -->
<table pgwide="1" frame="none" id="chip-ids">
<title>Chip Identifiers</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_IDENT_NONE</constant></entry>
<entry>0</entry>
<entry>No chip matched.</entry>
</row>
<row>
<entry><constant>V4L2_IDENT_AMBIGUOUS</constant></entry>
<entry>1</entry>
<entry>Multiple chips matched.</entry>
</row>
<row>
<entry><constant>V4L2_IDENT_UNKNOWN</constant></entry>
<entry>2</entry>
<entry>A chip is present at this address, but the driver
could not identify it.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The <structfield>match_type</structfield> is invalid.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml
+2 -18
View File
@@ -73,8 +73,7 @@ fields of a &v4l2-dbg-chip-info;
and call <constant>VIDIOC_DBG_G_CHIP_INFO</constant> with a pointer to
this structure. On success the driver stores information about the
selected chip in the <structfield>name</structfield> and
<structfield>flags</structfield> fields. On failure the structure
remains unchanged.</para>
<structfield>flags</structfield> fields.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
@@ -132,7 +131,7 @@ to the <structfield>type</structfield> field.</entry>
<entry>char</entry>
<entry><structfield>name[32]</structfield></entry>
<entry>Match a chip by this name, interpreted according
to the <structfield>type</structfield> field.</entry>
to the <structfield>type</structfield> field. Currently unused.</entry>
</row>
</tbody>
</tgroup>
@@ -182,21 +181,6 @@ is set, then the driver supports reading registers from the device. If
<entry>Match the nth chip on the card, zero for the
bridge chip. Does not match sub-devices.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
<entry>1</entry>
<entry>Match an &i2c; chip by its driver name. Can't be used with this ioctl.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
<entry>2</entry>
<entry>Match a chip by its 7 bit &i2c; bus address. Can't be used with this ioctl.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
<entry>3</entry>
<entry>Match the nth anciliary AC97 chip. Can't be used with this ioctl.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
<entry>4</entry>
Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml
+12 -52
View File
@@ -76,7 +76,7 @@ compiled with the <constant>CONFIG_VIDEO_ADV_DEBUG</constant> option
to enable these ioctls.</para>
<para>To write a register applications must initialize all fields
of a &v4l2-dbg-register; and call
of a &v4l2-dbg-register; except for <structfield>size</structfield> and call
<constant>VIDIOC_DBG_S_REGISTER</constant> with a pointer to this
structure. The <structfield>match.type</structfield> and
<structfield>match.addr</structfield> or <structfield>match.name</structfield>
@@ -91,8 +91,8 @@ written into the register.</para>
<structfield>reg</structfield> fields, and call
<constant>VIDIOC_DBG_G_REGISTER</constant> with a pointer to this
structure. On success the driver stores the register value in the
<structfield>val</structfield> field. On failure the structure remains
unchanged.</para>
<structfield>val</structfield> field and the size (in bytes) of the
value in <structfield>size</structfield>.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
@@ -101,40 +101,10 @@ on the TV card. The number zero always selects the host chip, &eg; the
chip connected to the PCI or USB bus. You can find out which chips are
present with the &VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>,
<structfield>match.name</structfield> contains the I2C driver name.
For instance
<constant>"saa7127"</constant> will match any chip
supported by the saa7127 driver, regardless of its &i2c; bus address.
When multiple chips supported by the same driver are present, the
effect of these ioctls is undefined. Again with the
&VIDIOC-DBG-G-CHIP-INFO; ioctl you can find out which &i2c; chips are
present.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_I2C_ADDR</constant>,
<structfield>match.addr</structfield> selects a chip by its 7 bit &i2c;
bus address.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_AC97</constant>,
<structfield>match.addr</structfield> selects the nth AC97 chip
on the TV card.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_SUBDEV</constant>,
<structfield>match.addr</structfield> selects the nth sub-device.</para>
<note>
<title>Success not guaranteed</title>
<para>Due to a flaw in the Linux &i2c; bus driver these ioctls may
return successfully without actually reading or writing a register. To
catch the most likely failure we recommend a &VIDIOC-DBG-G-CHIP-INFO;
call confirming the presence of the selected &i2c; chip.</para>
</note>
<para>These ioctls are optional, not all drivers may support them.
However when a driver supports these ioctls it must also support
&VIDIOC-DBG-G-CHIP-INFO;. Conversely it may support
@@ -150,7 +120,7 @@ LinuxTV v4l-dvb repository; see <ulink
url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
access instructions.</para>
<!-- Note for convenience vidioc-dbg-g-chip-ident.sgml
<!-- Note for convenience vidioc-dbg-g-chip-info.sgml
contains a duplicate of this table. -->
<table pgwide="1" frame="none" id="v4l2-dbg-match">
<title>struct <structname>v4l2_dbg_match</structname></title>
@@ -160,7 +130,7 @@ access instructions.</para>
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>See <xref linkend="ident-chip-match-types" /> for a list of
<entry>See <xref linkend="chip-match-types" /> for a list of
possible types.</entry>
</row>
<row>
@@ -179,7 +149,7 @@ to the <structfield>type</structfield> field.</entry>
<entry>char</entry>
<entry><structfield>name[32]</structfield></entry>
<entry>Match a chip by this name, interpreted according
to the <structfield>type</structfield> field.</entry>
to the <structfield>type</structfield> field. Currently unused.</entry>
</row>
</tbody>
</tgroup>
@@ -198,6 +168,11 @@ to the <structfield>type</structfield> field.</entry>
<entry><structfield>match</structfield></entry>
<entry>How to match the chip, see <xref linkend="v4l2-dbg-match" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>size</structfield></entry>
<entry>The register size in bytes.</entry>
</row>
<row>
<entry>__u64</entry>
<entry><structfield>reg</structfield></entry>
@@ -213,7 +188,7 @@ register.</entry>
</tgroup>
</table>
<!-- Note for convenience vidioc-dbg-g-chip-ident.sgml
<!-- Note for convenience vidioc-dbg-g-chip-info.sgml
contains a duplicate of this table. -->
<table pgwide="1" frame="none" id="chip-match-types">
<title>Chip Match Types</title>
@@ -226,21 +201,6 @@ register.</entry>
<entry>Match the nth chip on the card, zero for the
bridge chip. Does not match sub-devices.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
<entry>1</entry>
<entry>Match an &i2c; chip by its driver name.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
<entry>2</entry>
<entry>Match a chip by its 7 bit &i2c; bus address.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
<entry>3</entry>
<entry>Match the nth anciliary AC97 chip.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
<entry>4</entry>
Documentation/DocBook/media/v4l/vidioc-querystd.xml
+2 -1
View File
@@ -54,7 +54,8 @@ standard automatically. To do so, applications call <constant>
VIDIOC_QUERYSTD</constant> with a pointer to a &v4l2-std-id; type. The
driver stores here a set of candidates, this can be a single flag or a
set of supported standards if for example the hardware can only
distinguish between 50 and 60 Hz systems. When detection is not
distinguish between 50 and 60 Hz systems. If no signal was detected,
then the driver will return V4L2_STD_UNKNOWN. When detection is not
possible or fails, the set must contain all standards supported by the
current video input or output.</para>
Documentation/bcache.txt
+24 -13
View File
@@ -46,29 +46,33 @@ you format your backing devices and cache device at the same time, you won't
have to manually attach:
make-bcache -B /dev/sda /dev/sdb -C /dev/sdc
To make bcache devices known to the kernel, echo them to /sys/fs/bcache/register:
bcache-tools now ships udev rules, and bcache devices are known to the kernel
immediately. Without udev, you can manually register devices like this:
echo /dev/sdb > /sys/fs/bcache/register
echo /dev/sdc > /sys/fs/bcache/register
To register your bcache devices automatically, you could add something like
this to an init script:
Registering the backing device makes the bcache device show up in /dev; you can
now format it and use it as normal. But the first time using a new bcache
device, it'll be running in passthrough mode until you attach it to a cache.
See the section on attaching.
echo /dev/sd* > /sys/fs/bcache/register_quiet
The devices show up as:
It'll look for bcache superblocks and ignore everything that doesn't have one.
/dev/bcache<N>
Registering the backing device makes the bcache show up in /dev; you can now
format it and use it as normal. But the first time using a new bcache device,
it'll be running in passthrough mode until you attach it to a cache. See the
section on attaching.
As well as (with udev):
The devices show up at /dev/bcacheN, and can be controlled via sysfs from
/sys/block/bcacheN/bcache:
/dev/bcache/by-uuid/<uuid>
/dev/bcache/by-label/<label>
To get started:
mkfs.ext4 /dev/bcache0
mount /dev/bcache0 /mnt
You can control bcache devices through sysfs at /sys/block/bcache<N>/bcache .
Cache devices are managed as sets; multiple caches per set isn't supported yet
but will allow for mirroring of metadata and dirty data in the future. Your new
cache set shows up as /sys/fs/bcache/<UUID>
@@ -80,11 +84,11 @@ must be attached to your cache set to enable caching. Attaching a backing
device to a cache set is done thusly, with the UUID of the cache set in
/sys/fs/bcache:
echo <UUID> > /sys/block/bcache0/bcache/attach
echo <CSET-UUID> > /sys/block/bcache0/bcache/attach
This only has to be done once. The next time you reboot, just reregister all
your bcache devices. If a backing device has data in a cache somewhere, the
/dev/bcache# device won't be created until the cache shows up - particularly
/dev/bcache<N> device won't be created until the cache shows up - particularly
important if you have writeback caching turned on.
If you're booting up and your cache device is gone and never coming back, you
@@ -191,6 +195,9 @@ want for getting the best possible numbers when benchmarking.
SYSFS - BACKING DEVICE:
Available at /sys/block/<bdev>/bcache, /sys/block/bcache*/bcache and
(if attached) /sys/fs/bcache/<cset-uuid>/bdev*
attach
Echo the UUID of a cache set to this file to enable caching.
@@ -300,6 +307,8 @@ cache_readaheads
SYSFS - CACHE SET:
Available at /sys/fs/bcache/<cset-uuid>
average_key_size
Average data per key in the btree.
@@ -390,6 +399,8 @@ trigger_gc
SYSFS - CACHE DEVICE:
Available at /sys/block/<cdev>/bcache
block_size
Minimum granularity of writes - should match hardware sector size.
Documentation/cgroups/blkio-controller.txt
+15 -14
View File
@@ -94,11 +94,13 @@ Throttling/Upper Limit policy
Hierarchical Cgroups
====================
- Currently only CFQ supports hierarchical groups. For throttling,
cgroup interface does allow creation of hierarchical cgroups and
internally it treats them as flat hierarchy.
If somebody created a hierarchy like as follows.
Both CFQ and throttling implement hierarchy support; however,
throttling's hierarchy support is enabled iff "sane_behavior" is
enabled from cgroup side, which currently is a development option and
not publicly available.
If somebody created a hierarchy like as follows.
root
/ \
@@ -106,21 +108,20 @@ Hierarchical Cgroups
|
test3
CFQ will handle the hierarchy correctly but and throttling will
practically treat all groups at same level. For details on CFQ
hierarchy support, refer to Documentation/block/cfq-iosched.txt.
Throttling will treat the hierarchy as if it looks like the
following.
CFQ by default and throttling with "sane_behavior" will handle the
hierarchy correctly. For details on CFQ hierarchy support, refer to
Documentation/block/cfq-iosched.txt. For throttling, all limits apply
to the whole subtree while all statistics are local to the IOs
directly generated by tasks in that cgroup.
Throttling without "sane_behavior" enabled from cgroup side will
practically treat all groups at same level as if it looks like the
following.
pivot
/ / \ \
root test1 test2 test3
Nesting cgroups, while allowed, isn't officially supported and blkio
genereates warning when cgroups nest. Once throttling implements
hierarchy support, hierarchy will be supported and the warning will
be removed.
Various user visible config options
===================================
CONFIG_BLK_CGROUP
Documentation/coccinelle.txt
+39 -24
View File
@@ -6,15 +6,17 @@ Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr>
Getting Coccinelle
~~~~~~~~~~~~~~~~~~~~
The semantic patches included in the kernel use the 'virtual rule'
feature which was introduced in Coccinelle version 0.1.11.
The semantic patches included in the kernel use features and options
which are provided by Coccinelle version 1.0.0-rc11 and above.
Using earlier versions will fail as the option names used by
the Coccinelle files and coccicheck have been updated.
Coccinelle (>=0.2.0) is available through the package manager
Coccinelle is available through the package manager
of many distributions, e.g. :
- Debian (>=squeeze)
- Fedora (>=13)
- Ubuntu (>=10.04 Lucid Lynx)
- Debian
- Fedora
- Ubuntu
- OpenSUSE
- Arch Linux
- NetBSD
@@ -36,11 +38,6 @@ as a regular user, and install it with
sudo make install
The semantic patches in the kernel will work best with Coccinelle version
0.2.4 or later. Using earlier versions may incur some parse errors in the
semantic patch code, but any results that are obtained should still be
correct.
Using Coccinelle on the Linux kernel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -48,7 +45,7 @@ A Coccinelle-specific target is defined in the top level
Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
front-end in the 'scripts' directory.
Four modes are defined: patch, report, context, and org. The mode to
Four basic modes are defined: patch, report, context, and org. The mode to
use is specified by setting the MODE variable with 'MODE=<mode>'.
'patch' proposes a fix, when possible.
@@ -62,18 +59,24 @@ diff-like style.Lines of interest are indicated with '-'.
'org' generates a report in the Org mode format of Emacs.
Note that not all semantic patches implement all modes. For easy use
of Coccinelle, the default mode is "chain" which tries the previous
modes in the order above until one succeeds.
of Coccinelle, the default mode is "report".
To make a report for every semantic patch, run the following command:
Two other modes provide some common combinations of these modes.
make coccicheck MODE=report
'chain' tries the previous modes in the order above until one succeeds.
NB: The 'report' mode is the default one.
'rep+ctxt' runs successively the report mode and the context mode.
It should be used with the C option (described later)
which checks the code on a file basis.
To produce patches, run:
Examples:
To make a report for every semantic patch, run the following command:
make coccicheck MODE=patch
make coccicheck MODE=report
To produce patches, run:
make coccicheck MODE=patch
The coccicheck target applies every semantic patch available in the
@@ -91,6 +94,11 @@ To enable verbose messages set the V= variable, for example:
make coccicheck MODE=report V=1
By default, coccicheck tries to run as parallel as possible. To change
the parallelism, set the J= variable. For example, to run across 4 CPUs:
make coccicheck MODE=report J=4
Using Coccinelle with a single semantic patch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -124,26 +132,33 @@ To check only newly edited code, use the value 2 for the C flag, i.e.
make C=2 CHECK="scripts/coccicheck"
In these modes, which works on a file basis, there is no information
about semantic patches displayed, and no commit message proposed.
This runs every semantic patch in scripts/coccinelle by default. The
COCCI variable may additionally be used to only apply a single
semantic patch as shown in the previous section.
The "chain" mode is the default. You can select another one with the
The "report" mode is the default. You can select another one with the
MODE variable explained above.
In this mode, there is no information about semantic patches
displayed, and no commit message proposed.
Additional flags
~~~~~~~~~~~~~~~~~~
Additional flags can be passed to spatch through the SPFLAGS
variable.
make SPFLAGS=--use_glimpse coccicheck
make SPFLAGS=--use-glimpse coccicheck
make SPFLAGS=--use-idutils coccicheck
See spatch --help to learn more about spatch options.
Note that the '--use-glimpse' and '--use-idutils' options
require external tools for indexing the code. None of them is
thus active by default. However, by indexing the code with
one of these tools, and according to the cocci file used,
spatch could proceed the entire code base more quickly.
Proposing new semantic patches
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Some files were not shown because too many files have changed in this diff Show More