diff options
author | Ingo Molnar <mingo@elte.hu> | 2009-04-08 11:25:42 -0400 |
---|---|---|
committer | Ingo Molnar <mingo@elte.hu> | 2009-04-08 11:26:00 -0400 |
commit | 5af8c4e0fac9838428bd718040b664043a05f37c (patch) | |
tree | 75a01d98ed244db45fe3c734c4a81c1a3d92ac37 /Documentation | |
parent | 46e0bb9c12f4bab539736f1714cbf16600f681ec (diff) | |
parent | 577c9c456f0e1371cbade38eaf91ae8e8a308555 (diff) |
Merge commit 'v2.6.30-rc1' into sched/urgent
Merge reason: update to latest upstream to queue up fix
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'Documentation')
175 files changed, 14225 insertions, 4339 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 2a39aeba1464..d05737aaa84b 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
@@ -86,6 +86,8 @@ cachetlb.txt | |||
86 | - describes the cache/TLB flushing interfaces Linux uses. | 86 | - describes the cache/TLB flushing interfaces Linux uses. |
87 | cdrom/ | 87 | cdrom/ |
88 | - directory with information on the CD-ROM drivers that Linux has. | 88 | - directory with information on the CD-ROM drivers that Linux has. |
89 | cgroups/ | ||
90 | - cgroups features, including cpusets and memory controller. | ||
89 | connector/ | 91 | connector/ |
90 | - docs on the netlink based userspace<->kernel space communication mod. | 92 | - docs on the netlink based userspace<->kernel space communication mod. |
91 | console/ | 93 | console/ |
@@ -98,8 +100,6 @@ cpu-load.txt | |||
98 | - document describing how CPU load statistics are collected. | 100 | - document describing how CPU load statistics are collected. |
99 | cpuidle/ | 101 | cpuidle/ |
100 | - info on CPU_IDLE, CPU idle state management subsystem. | 102 | - info on CPU_IDLE, CPU idle state management subsystem. |
101 | cpusets.txt | ||
102 | - documents the cpusets feature; assign CPUs and Mem to a set of tasks. | ||
103 | cputopology.txt | 103 | cputopology.txt |
104 | - documentation on how CPU topology info is exported via sysfs. | 104 | - documentation on how CPU topology info is exported via sysfs. |
105 | cris/ | 105 | cris/ |
diff --git a/Documentation/ABI/testing/debugfs-kmemtrace b/Documentation/ABI/testing/debugfs-kmemtrace new file mode 100644 index 000000000000..5e6a92a02d85 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-kmemtrace | |||
@@ -0,0 +1,71 @@ | |||
1 | What: /sys/kernel/debug/kmemtrace/ | ||
2 | Date: July 2008 | ||
3 | Contact: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> | ||
4 | Description: | ||
5 | |||
6 | In kmemtrace-enabled kernels, the following files are created: | ||
7 | |||
8 | /sys/kernel/debug/kmemtrace/ | ||
9 | cpu<n> (0400) Per-CPU tracing data, see below. (binary) | ||
10 | total_overruns (0400) Total number of bytes which were dropped from | ||
11 | cpu<n> files because of full buffer condition, | ||
12 | non-binary. (text) | ||
13 | abi_version (0400) Kernel's kmemtrace ABI version. (text) | ||
14 | |||
15 | Each per-CPU file should be read according to the relay interface. That is, | ||
16 | the reader should set affinity to that specific CPU and, as currently done by | ||
17 | the userspace application (though there are other methods), use poll() with | ||
18 | an infinite timeout before every read(). Otherwise, erroneous data may be | ||
19 | read. The binary data has the following _core_ format: | ||
20 | |||
21 | Event ID (1 byte) Unsigned integer, one of: | ||
22 | 0 - represents an allocation (KMEMTRACE_EVENT_ALLOC) | ||
23 | 1 - represents a freeing of previously allocated memory | ||
24 | (KMEMTRACE_EVENT_FREE) | ||
25 | Type ID (1 byte) Unsigned integer, one of: | ||
26 | 0 - this is a kmalloc() / kfree() | ||
27 | 1 - this is a kmem_cache_alloc() / kmem_cache_free() | ||
28 | 2 - this is a __get_free_pages() et al. | ||
29 | Event size (2 bytes) Unsigned integer representing the | ||
30 | size of this event. Used to extend | ||
31 | kmemtrace. Discard the bytes you | ||
32 | don't know about. | ||
33 | Sequence number (4 bytes) Signed integer used to reorder data | ||
34 | logged on SMP machines. Wraparound | ||
35 | must be taken into account, although | ||
36 | it is unlikely. | ||
37 | Caller address (8 bytes) Return address to the caller. | ||
38 | Pointer to mem (8 bytes) Pointer to target memory area. Can be | ||
39 | NULL, but not all such calls might be | ||
40 | recorded. | ||
41 | |||
42 | In case of KMEMTRACE_EVENT_ALLOC events, the next fields follow: | ||
43 | |||
44 | Requested bytes (8 bytes) Total number of requested bytes, | ||
45 | unsigned, must not be zero. | ||
46 | Allocated bytes (8 bytes) Total number of actually allocated | ||
47 | bytes, unsigned, must not be lower | ||
48 | than requested bytes. | ||
49 | Requested flags (4 bytes) GFP flags supplied by the caller. | ||
50 | Target CPU (4 bytes) Signed integer, valid for event id 1. | ||
51 | If equal to -1, target CPU is the same | ||
52 | as origin CPU, but the reverse might | ||
53 | not be true. | ||
54 | |||
55 | The data is made available in the same endianness the machine has. | ||
56 | |||
57 | Other event ids and type ids may be defined and added. Other fields may be | ||
58 | added by increasing event size, but see below for details. | ||
59 | Every modification to the ABI, including new id definitions, are followed | ||
60 | by bumping the ABI version by one. | ||
61 | |||
62 | Adding new data to the packet (features) is done at the end of the mandatory | ||
63 | data: | ||
64 | Feature size (2 byte) | ||
65 | Feature ID (1 byte) | ||
66 | Feature data (Feature size - 3 bytes) | ||
67 | |||
68 | |||
69 | Users: | ||
70 | kmemtrace-user - git://repo.or.cz/kmemtrace-user.git | ||
71 | |||
diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy new file mode 100644 index 000000000000..6434f0df012e --- /dev/null +++ b/Documentation/ABI/testing/ima_policy | |||
@@ -0,0 +1,61 @@ | |||
1 | What: security/ima/policy | ||
2 | Date: May 2008 | ||
3 | Contact: Mimi Zohar <zohar@us.ibm.com> | ||
4 | Description: | ||
5 | The Trusted Computing Group(TCG) runtime Integrity | ||
6 | Measurement Architecture(IMA) maintains a list of hash | ||
7 | values of executables and other sensitive system files | ||
8 | loaded into the run-time of this system. At runtime, | ||
9 | the policy can be constrained based on LSM specific data. | ||
10 | Policies are loaded into the securityfs file ima/policy | ||
11 | by opening the file, writing the rules one at a time and | ||
12 | then closing the file. The new policy takes effect after | ||
13 | the file ima/policy is closed. | ||
14 | |||
15 | rule format: action [condition ...] | ||
16 | |||
17 | action: measure | dont_measure | ||
18 | condition:= base | lsm | ||
19 | base: [[func=] [mask=] [fsmagic=] [uid=]] | ||
20 | lsm: [[subj_user=] [subj_role=] [subj_type=] | ||
21 | [obj_user=] [obj_role=] [obj_type=]] | ||
22 | |||
23 | base: func:= [BPRM_CHECK][FILE_MMAP][INODE_PERMISSION] | ||
24 | mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC] | ||
25 | fsmagic:= hex value | ||
26 | uid:= decimal value | ||
27 | lsm: are LSM specific | ||
28 | |||
29 | default policy: | ||
30 | # PROC_SUPER_MAGIC | ||
31 | dont_measure fsmagic=0x9fa0 | ||
32 | # SYSFS_MAGIC | ||
33 | dont_measure fsmagic=0x62656572 | ||
34 | # DEBUGFS_MAGIC | ||
35 | dont_measure fsmagic=0x64626720 | ||
36 | # TMPFS_MAGIC | ||
37 | dont_measure fsmagic=0x01021994 | ||
38 | # SECURITYFS_MAGIC | ||
39 | dont_measure fsmagic=0x73636673 | ||
40 | |||
41 | measure func=BPRM_CHECK | ||
42 | measure func=FILE_MMAP mask=MAY_EXEC | ||
43 | measure func=INODE_PERM mask=MAY_READ uid=0 | ||
44 | |||
45 | The default policy measures all executables in bprm_check, | ||
46 | all files mmapped executable in file_mmap, and all files | ||
47 | open for read by root in inode_permission. | ||
48 | |||
49 | Examples of LSM specific definitions: | ||
50 | |||
51 | SELinux: | ||
52 | # SELINUX_MAGIC | ||
53 | dont_measure fsmagic=0xF97CFF8C | ||
54 | |||
55 | dont_measure obj_type=var_log_t | ||
56 | dont_measure obj_type=auditd_log_t | ||
57 | measure subj_user=system_u func=INODE_PERM mask=MAY_READ | ||
58 | measure subj_role=system_r func=INODE_PERM mask=MAY_READ | ||
59 | |||
60 | Smack: | ||
61 | measure subj_user=_ func=INODE_PERM mask=MAY_READ | ||
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index ceddcff4082a..97ad190e13af 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci | |||
@@ -1,3 +1,89 @@ | |||
1 | What: /sys/bus/pci/drivers/.../bind | ||
2 | Date: December 2003 | ||
3 | Contact: linux-pci@vger.kernel.org | ||
4 | Description: | ||
5 | Writing a device location to this file will cause | ||
6 | the driver to attempt to bind to the device found at | ||
7 | this location. This is useful for overriding default | ||
8 | bindings. The format for the location is: DDDD:BB:DD.F. | ||
9 | That is Domain:Bus:Device.Function and is the same as | ||
10 | found in /sys/bus/pci/devices/. For example: | ||
11 | # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/bind | ||
12 | (Note: kernels before 2.6.28 may require echo -n). | ||
13 | |||
14 | What: /sys/bus/pci/drivers/.../unbind | ||
15 | Date: December 2003 | ||
16 | Contact: linux-pci@vger.kernel.org | ||
17 | Description: | ||
18 | Writing a device location to this file will cause the | ||
19 | driver to attempt to unbind from the device found at | ||
20 | this location. This may be useful when overriding default | ||
21 | bindings. The format for the location is: DDDD:BB:DD.F. | ||
22 | That is Domain:Bus:Device.Function and is the same as | ||
23 | found in /sys/bus/pci/devices/. For example: | ||
24 | # echo 0000:00:19.0 > /sys/bus/pci/drivers/foo/unbind | ||
25 | (Note: kernels before 2.6.28 may require echo -n). | ||
26 | |||
27 | What: /sys/bus/pci/drivers/.../new_id | ||
28 | Date: December 2003 | ||
29 | Contact: linux-pci@vger.kernel.org | ||
30 | Description: | ||
31 | Writing a device ID to this file will attempt to | ||
32 | dynamically add a new device ID to a PCI device driver. | ||
33 | This may allow the driver to support more hardware than | ||
34 | was included in the driver's static device ID support | ||
35 | table at compile time. The format for the device ID is: | ||
36 | VVVV DDDD SVVV SDDD CCCC MMMM PPPP. That is Vendor ID, | ||
37 | Device ID, Subsystem Vendor ID, Subsystem Device ID, | ||
38 | Class, Class Mask, and Private Driver Data. The Vendor ID | ||
39 | and Device ID fields are required, the rest are optional. | ||
40 | Upon successfully adding an ID, the driver will probe | ||
41 | for the device and attempt to bind to it. For example: | ||
42 | # echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id | ||
43 | |||
44 | What: /sys/bus/pci/drivers/.../remove_id | ||
45 | Date: February 2009 | ||
46 | Contact: Chris Wright <chrisw@sous-sol.org> | ||
47 | Description: | ||
48 | Writing a device ID to this file will remove an ID | ||
49 | that was dynamically added via the new_id sysfs entry. | ||
50 | The format for the device ID is: | ||
51 | VVVV DDDD SVVV SDDD CCCC MMMM. That is Vendor ID, Device | ||
52 | ID, Subsystem Vendor ID, Subsystem Device ID, Class, | ||
53 | and Class Mask. The Vendor ID and Device ID fields are | ||
54 | required, the rest are optional. After successfully | ||
55 | removing an ID, the driver will no longer support the | ||
56 | device. This is useful to ensure auto probing won't | ||
57 | match the driver to the device. For example: | ||
58 | # echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id | ||
59 | |||
60 | What: /sys/bus/pci/rescan | ||
61 | Date: January 2009 | ||
62 | Contact: Linux PCI developers <linux-pci@vger.kernel.org> | ||
63 | Description: | ||
64 | Writing a non-zero value to this attribute will | ||
65 | force a rescan of all PCI buses in the system, and | ||
66 | re-discover previously removed devices. | ||
67 | Depends on CONFIG_HOTPLUG. | ||
68 | |||
69 | What: /sys/bus/pci/devices/.../remove | ||
70 | Date: January 2009 | ||
71 | Contact: Linux PCI developers <linux-pci@vger.kernel.org> | ||
72 | Description: | ||
73 | Writing a non-zero value to this attribute will | ||
74 | hot-remove the PCI device and any of its children. | ||
75 | Depends on CONFIG_HOTPLUG. | ||
76 | |||
77 | What: /sys/bus/pci/devices/.../rescan | ||
78 | Date: January 2009 | ||
79 | Contact: Linux PCI developers <linux-pci@vger.kernel.org> | ||
80 | Description: | ||
81 | Writing a non-zero value to this attribute will | ||
82 | force a rescan of the device's parent bus and all | ||
83 | child buses, and re-discover devices removed earlier | ||
84 | from this part of the device tree. | ||
85 | Depends on CONFIG_HOTPLUG. | ||
86 | |||
1 | What: /sys/bus/pci/devices/.../vpd | 87 | What: /sys/bus/pci/devices/.../vpd |
2 | Date: February 2008 | 88 | Date: February 2008 |
3 | Contact: Ben Hutchings <bhutchings@solarflare.com> | 89 | Contact: Ben Hutchings <bhutchings@solarflare.com> |
@@ -9,3 +95,30 @@ Description: | |||
9 | that some devices may have malformatted data. If the | 95 | that some devices may have malformatted data. If the |
10 | underlying VPD has a writable section then the | 96 | underlying VPD has a writable section then the |
11 | corresponding section of this file will be writable. | 97 | corresponding section of this file will be writable. |
98 | |||
99 | What: /sys/bus/pci/devices/.../virtfnN | ||
100 | Date: March 2009 | ||
101 | Contact: Yu Zhao <yu.zhao@intel.com> | ||
102 | Description: | ||
103 | This symbolic link appears when hardware supports the SR-IOV | ||
104 | capability and the Physical Function driver has enabled it. | ||
105 | The symbolic link points to the PCI device sysfs entry of the | ||
106 | Virtual Function whose index is N (0...MaxVFs-1). | ||
107 | |||
108 | What: /sys/bus/pci/devices/.../dep_link | ||
109 | Date: March 2009 | ||
110 | Contact: Yu Zhao <yu.zhao@intel.com> | ||
111 | Description: | ||
112 | This symbolic link appears when hardware supports the SR-IOV | ||
113 | capability and the Physical Function driver has enabled it, | ||
114 | and this device has vendor specific dependencies with others. | ||
115 | The symbolic link points to the PCI device sysfs entry of | ||
116 | Physical Function this device depends on. | ||
117 | |||
118 | What: /sys/bus/pci/devices/.../physfn | ||
119 | Date: March 2009 | ||
120 | Contact: Yu Zhao <yu.zhao@intel.com> | ||
121 | Description: | ||
122 | This symbolic link appears when a device is a Virtual Function. | ||
123 | The symbolic link points to the PCI device sysfs entry of the | ||
124 | Physical Function this device associates with. | ||
diff --git a/Documentation/ABI/testing/sysfs-class-regulator b/Documentation/ABI/testing/sysfs-class-regulator index 873ef1fc1569..e091fa873792 100644 --- a/Documentation/ABI/testing/sysfs-class-regulator +++ b/Documentation/ABI/testing/sysfs-class-regulator | |||
@@ -4,8 +4,8 @@ KernelVersion: 2.6.26 | |||
4 | Contact: Liam Girdwood <lrg@slimlogic.co.uk> | 4 | Contact: Liam Girdwood <lrg@slimlogic.co.uk> |
5 | Description: | 5 | Description: |
6 | Some regulator directories will contain a field called | 6 | Some regulator directories will contain a field called |
7 | state. This reports the regulator enable status, for | 7 | state. This reports the regulator enable control, for |
8 | regulators which can report that value. | 8 | regulators which can report that input value. |
9 | 9 | ||
10 | This will be one of the following strings: | 10 | This will be one of the following strings: |
11 | 11 | ||
@@ -14,16 +14,54 @@ Description: | |||
14 | 'unknown' | 14 | 'unknown' |
15 | 15 | ||
16 | 'enabled' means the regulator output is ON and is supplying | 16 | 'enabled' means the regulator output is ON and is supplying |
17 | power to the system. | 17 | power to the system (assuming no error prevents it). |
18 | 18 | ||
19 | 'disabled' means the regulator output is OFF and is not | 19 | 'disabled' means the regulator output is OFF and is not |
20 | supplying power to the system.. | 20 | supplying power to the system (unless some non-Linux |
21 | control has enabled it). | ||
21 | 22 | ||
22 | 'unknown' means software cannot determine the state, or | 23 | 'unknown' means software cannot determine the state, or |
23 | the reported state is invalid. | 24 | the reported state is invalid. |
24 | 25 | ||
25 | NOTE: this field can be used in conjunction with microvolts | 26 | NOTE: this field can be used in conjunction with microvolts |
26 | and microamps to determine regulator output levels. | 27 | or microamps to determine configured regulator output levels. |
28 | |||
29 | |||
30 | What: /sys/class/regulator/.../status | ||
31 | Description: | ||
32 | Some regulator directories will contain a field called | ||
33 | "status". This reports the current regulator status, for | ||
34 | regulators which can report that output value. | ||
35 | |||
36 | This will be one of the following strings: | ||
37 | |||
38 | off | ||
39 | on | ||
40 | error | ||
41 | fast | ||
42 | normal | ||
43 | idle | ||
44 | standby | ||
45 | |||
46 | "off" means the regulator is not supplying power to the | ||
47 | system. | ||
48 | |||
49 | "on" means the regulator is supplying power to the system, | ||
50 | and the regulator can't report a detailed operation mode. | ||
51 | |||
52 | "error" indicates an out-of-regulation status such as being | ||
53 | disabled due to thermal shutdown, or voltage being unstable | ||
54 | because of problems with the input power supply. | ||
55 | |||
56 | "fast", "normal", "idle", and "standby" are all detailed | ||
57 | regulator operation modes (described elsewhere). They | ||
58 | imply "on", but provide more detail. | ||
59 | |||
60 | Note that regulator status is a function of many inputs, | ||
61 | not limited to control inputs from Linux. For example, | ||
62 | the actual load presented may trigger "error" status; or | ||
63 | a regulator may be enabled by another user, even though | ||
64 | Linux did not enable it. | ||
27 | 65 | ||
28 | 66 | ||
29 | What: /sys/class/regulator/.../type | 67 | What: /sys/class/regulator/.../type |
@@ -58,7 +96,7 @@ Description: | |||
58 | Some regulator directories will contain a field called | 96 | Some regulator directories will contain a field called |
59 | microvolts. This holds the regulator output voltage setting | 97 | microvolts. This holds the regulator output voltage setting |
60 | measured in microvolts (i.e. E-6 Volts), for regulators | 98 | measured in microvolts (i.e. E-6 Volts), for regulators |
61 | which can report that voltage. | 99 | which can report the control input for voltage. |
62 | 100 | ||
63 | NOTE: This value should not be used to determine the regulator | 101 | NOTE: This value should not be used to determine the regulator |
64 | output voltage level as this value is the same regardless of | 102 | output voltage level as this value is the same regardless of |
@@ -73,7 +111,7 @@ Description: | |||
73 | Some regulator directories will contain a field called | 111 | Some regulator directories will contain a field called |
74 | microamps. This holds the regulator output current limit | 112 | microamps. This holds the regulator output current limit |
75 | setting measured in microamps (i.e. E-6 Amps), for regulators | 113 | setting measured in microamps (i.e. E-6 Amps), for regulators |
76 | which can report that current. | 114 | which can report the control input for a current limit. |
77 | 115 | ||
78 | NOTE: This value should not be used to determine the regulator | 116 | NOTE: This value should not be used to determine the regulator |
79 | output current level as this value is the same regardless of | 117 | output current level as this value is the same regardless of |
@@ -87,7 +125,7 @@ Contact: Liam Girdwood <lrg@slimlogic.co.uk> | |||
87 | Description: | 125 | Description: |
88 | Some regulator directories will contain a field called | 126 | Some regulator directories will contain a field called |
89 | opmode. This holds the current regulator operating mode, | 127 | opmode. This holds the current regulator operating mode, |
90 | for regulators which can report it. | 128 | for regulators which can report that control input value. |
91 | 129 | ||
92 | The opmode value can be one of the following strings: | 130 | The opmode value can be one of the following strings: |
93 | 131 | ||
@@ -101,7 +139,8 @@ Description: | |||
101 | 139 | ||
102 | NOTE: This value should not be used to determine the regulator | 140 | NOTE: This value should not be used to determine the regulator |
103 | output operating mode as this value is the same regardless of | 141 | output operating mode as this value is the same regardless of |
104 | whether the regulator is enabled or disabled. | 142 | whether the regulator is enabled or disabled. A "status" |
143 | attribute may be available to determine the actual mode. | ||
105 | 144 | ||
106 | 145 | ||
107 | What: /sys/class/regulator/.../min_microvolts | 146 | What: /sys/class/regulator/.../min_microvolts |
diff --git a/Documentation/ABI/testing/sysfs-firmware-memmap b/Documentation/ABI/testing/sysfs-firmware-memmap index 0d99ee6ae02e..eca0d65087dc 100644 --- a/Documentation/ABI/testing/sysfs-firmware-memmap +++ b/Documentation/ABI/testing/sysfs-firmware-memmap | |||
@@ -1,6 +1,6 @@ | |||
1 | What: /sys/firmware/memmap/ | 1 | What: /sys/firmware/memmap/ |
2 | Date: June 2008 | 2 | Date: June 2008 |
3 | Contact: Bernhard Walle <bwalle@suse.de> | 3 | Contact: Bernhard Walle <bernhard.walle@gmx.de> |
4 | Description: | 4 | Description: |
5 | On all platforms, the firmware provides a memory map which the | 5 | On all platforms, the firmware provides a memory map which the |
6 | kernel reads. The resources from that memory map are registered | 6 | kernel reads. The resources from that memory map are registered |
diff --git a/Documentation/ABI/testing/sysfs-fs-ext4 b/Documentation/ABI/testing/sysfs-fs-ext4 new file mode 100644 index 000000000000..4e79074de282 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-fs-ext4 | |||
@@ -0,0 +1,81 @@ | |||
1 | What: /sys/fs/ext4/<disk>/mb_stats | ||
2 | Date: March 2008 | ||
3 | Contact: "Theodore Ts'o" <tytso@mit.edu> | ||
4 | Description: | ||
5 | Controls whether the multiblock allocator should | ||
6 | collect statistics, which are shown during the unmount. | ||
7 | 1 means to collect statistics, 0 means not to collect | ||
8 | statistics | ||
9 | |||
10 | What: /sys/fs/ext4/<disk>/mb_group_prealloc | ||
11 | Date: March 2008 | ||
12 | Contact: "Theodore Ts'o" <tytso@mit.edu> | ||
13 | Description: | ||
14 | The multiblock allocator will round up allocation | ||
15 | requests to a multiple of this tuning parameter if the | ||
16 | stripe size is not set in the ext4 superblock | ||
17 | |||
18 | What: /sys/fs/ext4/<disk>/mb_max_to_scan | ||
19 | Date: March 2008 | ||
20 | Contact: "Theodore Ts'o" <tytso@mit.edu> | ||
21 | Description: | ||
22 | The maximum number of extents the multiblock allocator | ||
23 | will search to find the best extent | ||
24 | |||
25 | What: /sys/fs/ext4/<disk>/mb_min_to_scan | ||
26 | Date: March 2008 | ||
27 | Contact: "Theodore Ts'o" <tytso@mit.edu> | ||
28 | Description: | ||
29 | The minimum number of extents the multiblock allocator | ||
30 | will search to find the best extent | ||
31 | |||
32 | What: /sys/fs/ext4/<disk>/mb_order2_req | ||
33 | Date: March 2008 | ||
34 | Contact: "Theodore Ts'o" <tytso@mit.edu> | ||
35 | Description: | ||
36 | Tuning parameter which controls the minimum size for | ||
37 | requests (as a power of 2) where the buddy cache is | ||
38 | used | ||
39 | |||
40 | What: /sys/fs/ext4/<disk>/mb_stream_req | ||
41 | Date: March 2008 | ||
42 | Contact: "Theodore Ts'o" <tytso@mit.edu> | ||
43 | Description: | ||
44 | Files which have fewer blocks than this tunable | ||
45 | parameter will have their blocks allocated out of a | ||
46 | block group specific preallocation pool, so that small | ||
47 | files are packed closely together. Each large file | ||
48 | will have its blocks allocated out of its own unique | ||
49 | preallocation pool. | ||
50 | |||
51 | What: /sys/fs/ext4/<disk>/inode_readahead | ||
52 | Date: March 2008 | ||
53 | Contact: "Theodore Ts'o" <tytso@mit.edu> | ||
54 | Description: | ||
55 | Tuning parameter which controls the maximum number of | ||
56 | inode table blocks that ext4's inode table readahead | ||
57 | algorithm will pre-read into the buffer cache | ||
58 | |||
59 | What: /sys/fs/ext4/<disk>/delayed_allocation_blocks | ||
60 | Date: March 2008 | ||
61 | Contact: "Theodore Ts'o" <tytso@mit.edu> | ||
62 | Description: | ||
63 | This file is read-only and shows the number of blocks | ||
64 | that are dirty in the page cache, but which do not | ||
65 | have their location in the filesystem allocated yet. | ||
66 | |||
67 | What: /sys/fs/ext4/<disk>/lifetime_write_kbytes | ||
68 | Date: March 2008 | ||
69 | Contact: "Theodore Ts'o" <tytso@mit.edu> | ||
70 | Description: | ||
71 | This file is read-only and shows the number of kilobytes | ||
72 | of data that have been written to this filesystem since it was | ||
73 | created. | ||
74 | |||
75 | What: /sys/fs/ext4/<disk>/session_write_kbytes | ||
76 | Date: March 2008 | ||
77 | Contact: "Theodore Ts'o" <tytso@mit.edu> | ||
78 | Description: | ||
79 | This file is read-only and shows the number of | ||
80 | kilobytes of data that have been written to this | ||
81 | filesystem since it was mounted. | ||
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 2a3fcc55e981..d9aa43d78bcc 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt | |||
@@ -609,3 +609,109 @@ size is the size (and should be a page-sized multiple). | |||
609 | The return value will be either a pointer to the processor virtual | 609 | The return value will be either a pointer to the processor virtual |
610 | address of the memory, or an error (via PTR_ERR()) if any part of the | 610 | address of the memory, or an error (via PTR_ERR()) if any part of the |
611 | region is occupied. | 611 | region is occupied. |
612 | |||
613 | Part III - Debug drivers use of the DMA-API | ||
614 | ------------------------------------------- | ||
615 | |||
616 | The DMA-API as described above as some constraints. DMA addresses must be | ||
617 | released with the corresponding function with the same size for example. With | ||
618 | the advent of hardware IOMMUs it becomes more and more important that drivers | ||
619 | do not violate those constraints. In the worst case such a violation can | ||
620 | result in data corruption up to destroyed filesystems. | ||
621 | |||
622 | To debug drivers and find bugs in the usage of the DMA-API checking code can | ||
623 | be compiled into the kernel which will tell the developer about those | ||
624 | violations. If your architecture supports it you can select the "Enable | ||
625 | debugging of DMA-API usage" option in your kernel configuration. Enabling this | ||
626 | option has a performance impact. Do not enable it in production kernels. | ||
627 | |||
628 | If you boot the resulting kernel will contain code which does some bookkeeping | ||
629 | about what DMA memory was allocated for which device. If this code detects an | ||
630 | error it prints a warning message with some details into your kernel log. An | ||
631 | example warning message may look like this: | ||
632 | |||
633 | ------------[ cut here ]------------ | ||
634 | WARNING: at /data2/repos/linux-2.6-iommu/lib/dma-debug.c:448 | ||
635 | check_unmap+0x203/0x490() | ||
636 | Hardware name: | ||
637 | forcedeth 0000:00:08.0: DMA-API: device driver frees DMA memory with wrong | ||
638 | function [device address=0x00000000640444be] [size=66 bytes] [mapped as | ||
639 | single] [unmapped as page] | ||
640 | Modules linked in: nfsd exportfs bridge stp llc r8169 | ||
641 | Pid: 0, comm: swapper Tainted: G W 2.6.28-dmatest-09289-g8bb99c0 #1 | ||
642 | Call Trace: | ||
643 | <IRQ> [<ffffffff80240b22>] warn_slowpath+0xf2/0x130 | ||
644 | [<ffffffff80647b70>] _spin_unlock+0x10/0x30 | ||
645 | [<ffffffff80537e75>] usb_hcd_link_urb_to_ep+0x75/0xc0 | ||
646 | [<ffffffff80647c22>] _spin_unlock_irqrestore+0x12/0x40 | ||
647 | [<ffffffff8055347f>] ohci_urb_enqueue+0x19f/0x7c0 | ||
648 | [<ffffffff80252f96>] queue_work+0x56/0x60 | ||
649 | [<ffffffff80237e10>] enqueue_task_fair+0x20/0x50 | ||
650 | [<ffffffff80539279>] usb_hcd_submit_urb+0x379/0xbc0 | ||
651 | [<ffffffff803b78c3>] cpumask_next_and+0x23/0x40 | ||
652 | [<ffffffff80235177>] find_busiest_group+0x207/0x8a0 | ||
653 | [<ffffffff8064784f>] _spin_lock_irqsave+0x1f/0x50 | ||
654 | [<ffffffff803c7ea3>] check_unmap+0x203/0x490 | ||
655 | [<ffffffff803c8259>] debug_dma_unmap_page+0x49/0x50 | ||
656 | [<ffffffff80485f26>] nv_tx_done_optimized+0xc6/0x2c0 | ||
657 | [<ffffffff80486c13>] nv_nic_irq_optimized+0x73/0x2b0 | ||
658 | [<ffffffff8026df84>] handle_IRQ_event+0x34/0x70 | ||
659 | [<ffffffff8026ffe9>] handle_edge_irq+0xc9/0x150 | ||
660 | [<ffffffff8020e3ab>] do_IRQ+0xcb/0x1c0 | ||
661 | [<ffffffff8020c093>] ret_from_intr+0x0/0xa | ||
662 | <EOI> <4>---[ end trace f6435a98e2a38c0e ]--- | ||
663 | |||
664 | The driver developer can find the driver and the device including a stacktrace | ||
665 | of the DMA-API call which caused this warning. | ||
666 | |||
667 | Per default only the first error will result in a warning message. All other | ||
668 | errors will only silently counted. This limitation exist to prevent the code | ||
669 | from flooding your kernel log. To support debugging a device driver this can | ||
670 | be disabled via debugfs. See the debugfs interface documentation below for | ||
671 | details. | ||
672 | |||
673 | The debugfs directory for the DMA-API debugging code is called dma-api/. In | ||
674 | this directory the following files can currently be found: | ||
675 | |||
676 | dma-api/all_errors This file contains a numeric value. If this | ||
677 | value is not equal to zero the debugging code | ||
678 | will print a warning for every error it finds | ||
679 | into the kernel log. Be carefull with this | ||
680 | option. It can easily flood your logs. | ||
681 | |||
682 | dma-api/disabled This read-only file contains the character 'Y' | ||
683 | if the debugging code is disabled. This can | ||
684 | happen when it runs out of memory or if it was | ||
685 | disabled at boot time | ||
686 | |||
687 | dma-api/error_count This file is read-only and shows the total | ||
688 | numbers of errors found. | ||
689 | |||
690 | dma-api/num_errors The number in this file shows how many | ||
691 | warnings will be printed to the kernel log | ||
692 | before it stops. This number is initialized to | ||
693 | one at system boot and be set by writing into | ||
694 | this file | ||
695 | |||
696 | dma-api/min_free_entries | ||
697 | This read-only file can be read to get the | ||
698 | minimum number of free dma_debug_entries the | ||
699 | allocator has ever seen. If this value goes | ||
700 | down to zero the code will disable itself | ||
701 | because it is not longer reliable. | ||
702 | |||
703 | dma-api/num_free_entries | ||
704 | The current number of free dma_debug_entries | ||
705 | in the allocator. | ||
706 | |||
707 | If you have this code compiled into your kernel it will be enabled by default. | ||
708 | If you want to boot without the bookkeeping anyway you can provide | ||
709 | 'dma_debug=off' as a boot parameter. This will disable DMA-API debugging. | ||
710 | Notice that you can not enable it again at runtime. You have to reboot to do | ||
711 | so. | ||
712 | |||
713 | When the code disables itself at runtime this is most likely because it ran | ||
714 | out of dma_debug_entries. These entries are preallocated at boot. The number | ||
715 | of preallocated entries is defined per architecture. If it is too low for you | ||
716 | boot with 'dma_debug_entries=<your_desired_number>' to overwrite the | ||
717 | architectural default. | ||
diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt index b2a4d6d244d9..01f24e94bdb6 100644 --- a/Documentation/DMA-mapping.txt +++ b/Documentation/DMA-mapping.txt | |||
@@ -136,7 +136,7 @@ exactly why. | |||
136 | The standard 32-bit addressing PCI device would do something like | 136 | The standard 32-bit addressing PCI device would do something like |
137 | this: | 137 | this: |
138 | 138 | ||
139 | if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { | 139 | if (pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) { |
140 | printk(KERN_WARNING | 140 | printk(KERN_WARNING |
141 | "mydev: No suitable DMA available.\n"); | 141 | "mydev: No suitable DMA available.\n"); |
142 | goto ignore_this_device; | 142 | goto ignore_this_device; |
@@ -155,9 +155,9 @@ all 64-bits when accessing streaming DMA: | |||
155 | 155 | ||
156 | int using_dac; | 156 | int using_dac; |
157 | 157 | ||
158 | if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { | 158 | if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) { |
159 | using_dac = 1; | 159 | using_dac = 1; |
160 | } else if (!pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { | 160 | } else if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) { |
161 | using_dac = 0; | 161 | using_dac = 0; |
162 | } else { | 162 | } else { |
163 | printk(KERN_WARNING | 163 | printk(KERN_WARNING |
@@ -170,14 +170,14 @@ the case would look like this: | |||
170 | 170 | ||
171 | int using_dac, consistent_using_dac; | 171 | int using_dac, consistent_using_dac; |
172 | 172 | ||
173 | if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) { | 173 | if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) { |
174 | using_dac = 1; | 174 | using_dac = 1; |
175 | consistent_using_dac = 1; | 175 | consistent_using_dac = 1; |
176 | pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK); | 176 | pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64)); |
177 | } else if (!pci_set_dma_mask(pdev, DMA_32BIT_MASK)) { | 177 | } else if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) { |
178 | using_dac = 0; | 178 | using_dac = 0; |
179 | consistent_using_dac = 0; | 179 | consistent_using_dac = 0; |
180 | pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK); | 180 | pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32)); |
181 | } else { | 181 | } else { |
182 | printk(KERN_WARNING | 182 | printk(KERN_WARNING |
183 | "mydev: No suitable DMA available.\n"); | 183 | "mydev: No suitable DMA available.\n"); |
@@ -192,7 +192,7 @@ check the return value from pci_set_consistent_dma_mask(). | |||
192 | Finally, if your device can only drive the low 24-bits of | 192 | Finally, if your device can only drive the low 24-bits of |
193 | address during PCI bus mastering you might do something like: | 193 | address during PCI bus mastering you might do something like: |
194 | 194 | ||
195 | if (pci_set_dma_mask(pdev, DMA_24BIT_MASK)) { | 195 | if (pci_set_dma_mask(pdev, DMA_BIT_MASK(24))) { |
196 | printk(KERN_WARNING | 196 | printk(KERN_WARNING |
197 | "mydev: 24-bit DMA addressing not available.\n"); | 197 | "mydev: 24-bit DMA addressing not available.\n"); |
198 | goto ignore_this_device; | 198 | goto ignore_this_device; |
@@ -213,7 +213,7 @@ most specific mask. | |||
213 | 213 | ||
214 | Here is pseudo-code showing how this might be done: | 214 | Here is pseudo-code showing how this might be done: |
215 | 215 | ||
216 | #define PLAYBACK_ADDRESS_BITS DMA_32BIT_MASK | 216 | #define PLAYBACK_ADDRESS_BITS DMA_BIT_MASK(32) |
217 | #define RECORD_ADDRESS_BITS 0x00ffffff | 217 | #define RECORD_ADDRESS_BITS 0x00ffffff |
218 | 218 | ||
219 | struct my_sound_card *card; | 219 | struct my_sound_card *card; |
diff --git a/Documentation/DocBook/.gitignore b/Documentation/DocBook/.gitignore index c102c02ecf89..c6def352fe39 100644 --- a/Documentation/DocBook/.gitignore +++ b/Documentation/DocBook/.gitignore | |||
@@ -4,3 +4,7 @@ | |||
4 | *.html | 4 | *.html |
5 | *.9.gz | 5 | *.9.gz |
6 | *.9 | 6 | *.9 |
7 | *.aux | ||
8 | *.dvi | ||
9 | *.log | ||
10 | *.out | ||
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index dc3154e49279..a3a83d38f96f 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile | |||
@@ -6,13 +6,14 @@ | |||
6 | # To add a new book the only step required is to add the book to the | 6 | # To add a new book the only step required is to add the book to the |
7 | # list of DOCBOOKS. | 7 | # list of DOCBOOKS. |
8 | 8 | ||
9 | DOCBOOKS := z8530book.xml mcabook.xml \ | 9 | DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \ |
10 | kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ | 10 | kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ |
11 | procfs-guide.xml writing_usb_driver.xml networking.xml \ | 11 | procfs-guide.xml writing_usb_driver.xml networking.xml \ |
12 | kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ | 12 | kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ |
13 | gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ | 13 | gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ |
14 | genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ | 14 | genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ |
15 | mac80211.xml debugobjects.xml sh.xml regulator.xml | 15 | mac80211.xml debugobjects.xml sh.xml regulator.xml \ |
16 | alsa-driver-api.xml writing-an-alsa-driver.xml | ||
16 | 17 | ||
17 | ### | 18 | ### |
18 | # The build process is as follows (targets): | 19 | # The build process is as follows (targets): |
diff --git a/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl b/Documentation/DocBook/alsa-driver-api.tmpl index 9d644f7e241e..0230a96f0564 100644 --- a/Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl +++ b/Documentation/DocBook/alsa-driver-api.tmpl | |||
@@ -1,11 +1,11 @@ | |||
1 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> | 1 | <?xml version="1.0" encoding="UTF-8"?> |
2 | 2 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" | |
3 | <book> | 3 | "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> |
4 | <?dbhtml filename="index.html"> | ||
5 | 4 | ||
6 | <!-- ****************************************************** --> | 5 | <!-- ****************************************************** --> |
7 | <!-- Header --> | 6 | <!-- Header --> |
8 | <!-- ****************************************************** --> | 7 | <!-- ****************************************************** --> |
8 | <book id="ALSA-Driver-API"> | ||
9 | <bookinfo> | 9 | <bookinfo> |
10 | <title>The ALSA Driver API</title> | 10 | <title>The ALSA Driver API</title> |
11 | 11 | ||
@@ -35,6 +35,8 @@ | |||
35 | 35 | ||
36 | </bookinfo> | 36 | </bookinfo> |
37 | 37 | ||
38 | <toc></toc> | ||
39 | |||
38 | <chapter><title>Management of Cards and Devices</title> | 40 | <chapter><title>Management of Cards and Devices</title> |
39 | <sect1><title>Card Management</title> | 41 | <sect1><title>Card Management</title> |
40 | !Esound/core/init.c | 42 | !Esound/core/init.c |
@@ -71,6 +73,10 @@ | |||
71 | !Esound/pci/ac97/ac97_codec.c | 73 | !Esound/pci/ac97/ac97_codec.c |
72 | !Esound/pci/ac97/ac97_pcm.c | 74 | !Esound/pci/ac97/ac97_pcm.c |
73 | </sect1> | 75 | </sect1> |
76 | <sect1><title>Virtual Master Control API</title> | ||
77 | !Esound/core/vmaster.c | ||
78 | !Iinclude/sound/control.h | ||
79 | </sect1> | ||
74 | </chapter> | 80 | </chapter> |
75 | <chapter><title>MIDI API</title> | 81 | <chapter><title>MIDI API</title> |
76 | <sect1><title>Raw MIDI API</title> | 82 | <sect1><title>Raw MIDI API</title> |
@@ -89,6 +95,9 @@ | |||
89 | <sect1><title>Hardware-Dependent Devices API</title> | 95 | <sect1><title>Hardware-Dependent Devices API</title> |
90 | !Esound/core/hwdep.c | 96 | !Esound/core/hwdep.c |
91 | </sect1> | 97 | </sect1> |
98 | <sect1><title>Jack Abstraction Layer API</title> | ||
99 | !Esound/core/jack.c | ||
100 | </sect1> | ||
92 | <sect1><title>ISA DMA Helpers</title> | 101 | <sect1><title>ISA DMA Helpers</title> |
93 | !Esound/core/isadma.c | 102 | !Esound/core/isadma.c |
94 | </sect1> | 103 | </sect1> |
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl new file mode 100644 index 000000000000..94a20fe8fedf --- /dev/null +++ b/Documentation/DocBook/device-drivers.tmpl | |||
@@ -0,0 +1,418 @@ | |||
1 | <?xml version="1.0" encoding="UTF-8"?> | ||
2 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" | ||
3 | "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> | ||
4 | |||
5 | <book id="LinuxDriversAPI"> | ||
6 | <bookinfo> | ||
7 | <title>Linux Device Drivers</title> | ||
8 | |||
9 | <legalnotice> | ||
10 | <para> | ||
11 | This documentation is free software; you can redistribute | ||
12 | it and/or modify it under the terms of the GNU General Public | ||
13 | License as published by the Free Software Foundation; either | ||
14 | version 2 of the License, or (at your option) any later | ||
15 | version. | ||
16 | </para> | ||
17 | |||
18 | <para> | ||
19 | This program is distributed in the hope that it will be | ||
20 | useful, but WITHOUT ANY WARRANTY; without even the implied | ||
21 | warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. | ||
22 | See the GNU General Public License for more details. | ||
23 | </para> | ||
24 | |||
25 | <para> | ||
26 | You should have received a copy of the GNU General Public | ||
27 | License along with this program; if not, write to the Free | ||
28 | Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, | ||
29 | MA 02111-1307 USA | ||
30 | </para> | ||
31 | |||
32 | <para> | ||
33 | For more details see the file COPYING in the source | ||
34 | distribution of Linux. | ||
35 | </para> | ||
36 | </legalnotice> | ||
37 | </bookinfo> | ||
38 | |||
39 | <toc></toc> | ||
40 | |||
41 | <chapter id="Basics"> | ||
42 | <title>Driver Basics</title> | ||
43 | <sect1><title>Driver Entry and Exit points</title> | ||
44 | !Iinclude/linux/init.h | ||
45 | </sect1> | ||
46 | |||
47 | <sect1><title>Atomic and pointer manipulation</title> | ||
48 | !Iarch/x86/include/asm/atomic_32.h | ||
49 | !Iarch/x86/include/asm/unaligned.h | ||
50 | </sect1> | ||
51 | |||
52 | <sect1><title>Delaying, scheduling, and timer routines</title> | ||
53 | !Iinclude/linux/sched.h | ||
54 | !Ekernel/sched.c | ||
55 | !Ekernel/timer.c | ||
56 | </sect1> | ||
57 | <sect1><title>High-resolution timers</title> | ||
58 | !Iinclude/linux/ktime.h | ||
59 | !Iinclude/linux/hrtimer.h | ||
60 | !Ekernel/hrtimer.c | ||
61 | </sect1> | ||
62 | <sect1><title>Workqueues and Kevents</title> | ||
63 | !Ekernel/workqueue.c | ||
64 | </sect1> | ||
65 | <sect1><title>Internal Functions</title> | ||
66 | !Ikernel/exit.c | ||
67 | !Ikernel/signal.c | ||
68 | !Iinclude/linux/kthread.h | ||
69 | !Ekernel/kthread.c | ||
70 | </sect1> | ||
71 | |||
72 | <sect1><title>Kernel objects manipulation</title> | ||
73 | <!-- | ||
74 | X!Iinclude/linux/kobject.h | ||
75 | --> | ||
76 | !Elib/kobject.c | ||
77 | </sect1> | ||
78 | |||
79 | <sect1><title>Kernel utility functions</title> | ||
80 | !Iinclude/linux/kernel.h | ||
81 | !Ekernel/printk.c | ||
82 | !Ekernel/panic.c | ||
83 | !Ekernel/sys.c | ||
84 | !Ekernel/rcupdate.c | ||
85 | </sect1> | ||
86 | |||
87 | <sect1><title>Device Resource Management</title> | ||
88 | !Edrivers/base/devres.c | ||
89 | </sect1> | ||
90 | |||
91 | </chapter> | ||
92 | |||
93 | <chapter id="devdrivers"> | ||
94 | <title>Device drivers infrastructure</title> | ||
95 | <sect1><title>Device Drivers Base</title> | ||
96 | <!-- | ||
97 | X!Iinclude/linux/device.h | ||
98 | --> | ||
99 | !Edrivers/base/driver.c | ||
100 | !Edrivers/base/core.c | ||
101 | !Edrivers/base/class.c | ||
102 | !Edrivers/base/firmware_class.c | ||
103 | !Edrivers/base/transport_class.c | ||
104 | <!-- Cannot be included, because | ||
105 | attribute_container_add_class_device_adapter | ||
106 | and attribute_container_classdev_to_container | ||
107 | exceed allowed 44 characters maximum | ||
108 | X!Edrivers/base/attribute_container.c | ||
109 | --> | ||
110 | !Edrivers/base/sys.c | ||
111 | <!-- | ||
112 | X!Edrivers/base/interface.c | ||
113 | --> | ||
114 | !Edrivers/base/platform.c | ||
115 | !Edrivers/base/bus.c | ||
116 | </sect1> | ||
117 | <sect1><title>Device Drivers Power Management</title> | ||
118 | !Edrivers/base/power/main.c | ||
119 | </sect1> | ||
120 | <sect1><title>Device Drivers ACPI Support</title> | ||
121 | <!-- Internal functions only | ||
122 | X!Edrivers/acpi/sleep/main.c | ||
123 | X!Edrivers/acpi/sleep/wakeup.c | ||
124 | X!Edrivers/acpi/motherboard.c | ||
125 | X!Edrivers/acpi/bus.c | ||
126 | --> | ||
127 | !Edrivers/acpi/scan.c | ||
128 | !Idrivers/acpi/scan.c | ||
129 | <!-- No correct structured comments | ||
130 | X!Edrivers/acpi/pci_bind.c | ||
131 | --> | ||
132 | </sect1> | ||
133 | <sect1><title>Device drivers PnP support</title> | ||
134 | !Idrivers/pnp/core.c | ||
135 | <!-- No correct structured comments | ||
136 | X!Edrivers/pnp/system.c | ||
137 | --> | ||
138 | !Edrivers/pnp/card.c | ||
139 | !Idrivers/pnp/driver.c | ||
140 | !Edrivers/pnp/manager.c | ||
141 | !Edrivers/pnp/support.c | ||
142 | </sect1> | ||
143 | <sect1><title>Userspace IO devices</title> | ||
144 | !Edrivers/uio/uio.c | ||
145 | !Iinclude/linux/uio_driver.h | ||
146 | </sect1> | ||
147 | </chapter> | ||
148 | |||
149 | <chapter id="parportdev"> | ||
150 | <title>Parallel Port Devices</title> | ||
151 | !Iinclude/linux/parport.h | ||
152 | !Edrivers/parport/ieee1284.c | ||
153 | !Edrivers/parport/share.c | ||
154 | !Idrivers/parport/daisy.c | ||
155 | </chapter> | ||
156 | |||
157 | <chapter id="message_devices"> | ||
158 | <title>Message-based devices</title> | ||
159 | <sect1><title>Fusion message devices</title> | ||
160 | !Edrivers/message/fusion/mptbase.c | ||
161 | !Idrivers/message/fusion/mptbase.c | ||
162 | !Edrivers/message/fusion/mptscsih.c | ||
163 | !Idrivers/message/fusion/mptscsih.c | ||
164 | !Idrivers/message/fusion/mptctl.c | ||
165 | !Idrivers/message/fusion/mptspi.c | ||
166 | !Idrivers/message/fusion/mptfc.c | ||
167 | !Idrivers/message/fusion/mptlan.c | ||
168 | </sect1> | ||
169 | <sect1><title>I2O message devices</title> | ||
170 | !Iinclude/linux/i2o.h | ||
171 | !Idrivers/message/i2o/core.h | ||
172 | !Edrivers/message/i2o/iop.c | ||
173 | !Idrivers/message/i2o/iop.c | ||
174 | !Idrivers/message/i2o/config-osm.c | ||
175 | !Edrivers/message/i2o/exec-osm.c | ||
176 | !Idrivers/message/i2o/exec-osm.c | ||
177 | !Idrivers/message/i2o/bus-osm.c | ||
178 | !Edrivers/message/i2o/device.c | ||
179 | !Idrivers/message/i2o/device.c | ||
180 | !Idrivers/message/i2o/driver.c | ||
181 | !Idrivers/message/i2o/pci.c | ||
182 | !Idrivers/message/i2o/i2o_block.c | ||
183 | !Idrivers/message/i2o/i2o_scsi.c | ||
184 | !Idrivers/message/i2o/i2o_proc.c | ||
185 | </sect1> | ||
186 | </chapter> | ||
187 | |||
188 | <chapter id="snddev"> | ||
189 | <title>Sound Devices</title> | ||
190 | !Iinclude/sound/core.h | ||
191 | !Esound/sound_core.c | ||
192 | !Iinclude/sound/pcm.h | ||
193 | !Esound/core/pcm.c | ||
194 | !Esound/core/device.c | ||
195 | !Esound/core/info.c | ||
196 | !Esound/core/rawmidi.c | ||
197 | !Esound/core/sound.c | ||
198 | !Esound/core/memory.c | ||
199 | !Esound/core/pcm_memory.c | ||
200 | !Esound/core/init.c | ||
201 | !Esound/core/isadma.c | ||
202 | !Esound/core/control.c | ||
203 | !Esound/core/pcm_lib.c | ||
204 | !Esound/core/hwdep.c | ||
205 | !Esound/core/pcm_native.c | ||
206 | !Esound/core/memalloc.c | ||
207 | <!-- FIXME: Removed for now since no structured comments in source | ||
208 | X!Isound/sound_firmware.c | ||
209 | --> | ||
210 | </chapter> | ||
211 | |||
212 | <chapter id="uart16x50"> | ||
213 | <title>16x50 UART Driver</title> | ||
214 | !Iinclude/linux/serial_core.h | ||
215 | !Edrivers/serial/serial_core.c | ||
216 | !Edrivers/serial/8250.c | ||
217 | </chapter> | ||
218 | |||
219 | <chapter id="fbdev"> | ||
220 | <title>Frame Buffer Library</title> | ||
221 | |||
222 | <para> | ||
223 | The frame buffer drivers depend heavily on four data structures. | ||
224 | These structures are declared in include/linux/fb.h. They are | ||
225 | fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs. | ||
226 | The last three can be made available to and from userland. | ||
227 | </para> | ||
228 | |||
229 | <para> | ||
230 | fb_info defines the current state of a particular video card. | ||
231 | Inside fb_info, there exists a fb_ops structure which is a | ||
232 | collection of needed functions to make fbdev and fbcon work. | ||
233 | fb_info is only visible to the kernel. | ||
234 | </para> | ||
235 | |||
236 | <para> | ||
237 | fb_var_screeninfo is used to describe the features of a video card | ||
238 | that are user defined. With fb_var_screeninfo, things such as | ||
239 | depth and the resolution may be defined. | ||
240 | </para> | ||
241 | |||
242 | <para> | ||
243 | The next structure is fb_fix_screeninfo. This defines the | ||
244 | properties of a card that are created when a mode is set and can't | ||
245 | be changed otherwise. A good example of this is the start of the | ||
246 | frame buffer memory. This "locks" the address of the frame buffer | ||
247 | memory, so that it cannot be changed or moved. | ||
248 | </para> | ||
249 | |||
250 | <para> | ||
251 | The last structure is fb_monospecs. In the old API, there was | ||
252 | little importance for fb_monospecs. This allowed for forbidden things | ||
253 | such as setting a mode of 800x600 on a fix frequency monitor. With | ||
254 | the new API, fb_monospecs prevents such things, and if used | ||
255 | correctly, can prevent a monitor from being cooked. fb_monospecs | ||
256 | will not be useful until kernels 2.5.x. | ||
257 | </para> | ||
258 | |||
259 | <sect1><title>Frame Buffer Memory</title> | ||
260 | !Edrivers/video/fbmem.c | ||
261 | </sect1> | ||
262 | <!-- | ||
263 | <sect1><title>Frame Buffer Console</title> | ||
264 | X!Edrivers/video/console/fbcon.c | ||
265 | </sect1> | ||
266 | --> | ||
267 | <sect1><title>Frame Buffer Colormap</title> | ||
268 | !Edrivers/video/fbcmap.c | ||
269 | </sect1> | ||
270 | <!-- FIXME: | ||
271 | drivers/video/fbgen.c has no docs, which stuffs up the sgml. Comment | ||
272 | out until somebody adds docs. KAO | ||
273 | <sect1><title>Frame Buffer Generic Functions</title> | ||
274 | X!Idrivers/video/fbgen.c | ||
275 | </sect1> | ||
276 | KAO --> | ||
277 | <sect1><title>Frame Buffer Video Mode Database</title> | ||
278 | !Idrivers/video/modedb.c | ||
279 | !Edrivers/video/modedb.c | ||
280 | </sect1> | ||
281 | <sect1><title>Frame Buffer Macintosh Video Mode Database</title> | ||
282 | !Edrivers/video/macmodes.c | ||
283 | </sect1> | ||
284 | <sect1><title>Frame Buffer Fonts</title> | ||
285 | <para> | ||
286 | Refer to the file drivers/video/console/fonts.c for more information. | ||
287 | </para> | ||
288 | <!-- FIXME: Removed for now since no structured comments in source | ||
289 | X!Idrivers/video/console/fonts.c | ||
290 | --> | ||
291 | </sect1> | ||
292 | </chapter> | ||
293 | |||
294 | <chapter id="input_subsystem"> | ||
295 | <title>Input Subsystem</title> | ||
296 | !Iinclude/linux/input.h | ||
297 | !Edrivers/input/input.c | ||
298 | !Edrivers/input/ff-core.c | ||
299 | !Edrivers/input/ff-memless.c | ||
300 | </chapter> | ||
301 | |||
302 | <chapter id="spi"> | ||
303 | <title>Serial Peripheral Interface (SPI)</title> | ||
304 | <para> | ||
305 | SPI is the "Serial Peripheral Interface", widely used with | ||
306 | embedded systems because it is a simple and efficient | ||
307 | interface: basically a multiplexed shift register. | ||
308 | Its three signal wires hold a clock (SCK, often in the range | ||
309 | of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and | ||
310 | a "Master In, Slave Out" (MISO) data line. | ||
311 | SPI is a full duplex protocol; for each bit shifted out the | ||
312 | MOSI line (one per clock) another is shifted in on the MISO line. | ||
313 | Those bits are assembled into words of various sizes on the | ||
314 | way to and from system memory. | ||
315 | An additional chipselect line is usually active-low (nCS); | ||
316 | four signals are normally used for each peripheral, plus | ||
317 | sometimes an interrupt. | ||
318 | </para> | ||
319 | <para> | ||
320 | The SPI bus facilities listed here provide a generalized | ||
321 | interface to declare SPI busses and devices, manage them | ||
322 | according to the standard Linux driver model, and perform | ||
323 | input/output operations. | ||
324 | At this time, only "master" side interfaces are supported, | ||
325 | where Linux talks to SPI peripherals and does not implement | ||
326 | such a peripheral itself. | ||
327 | (Interfaces to support implementing SPI slaves would | ||
328 | necessarily look different.) | ||
329 | </para> | ||
330 | <para> | ||
331 | The programming interface is structured around two kinds of driver, | ||
332 | and two kinds of device. | ||
333 | A "Controller Driver" abstracts the controller hardware, which may | ||
334 | be as simple as a set of GPIO pins or as complex as a pair of FIFOs | ||
335 | connected to dual DMA engines on the other side of the SPI shift | ||
336 | register (maximizing throughput). Such drivers bridge between | ||
337 | whatever bus they sit on (often the platform bus) and SPI, and | ||
338 | expose the SPI side of their device as a | ||
339 | <structname>struct spi_master</structname>. | ||
340 | SPI devices are children of that master, represented as a | ||
341 | <structname>struct spi_device</structname> and manufactured from | ||
342 | <structname>struct spi_board_info</structname> descriptors which | ||
343 | are usually provided by board-specific initialization code. | ||
344 | A <structname>struct spi_driver</structname> is called a | ||
345 | "Protocol Driver", and is bound to a spi_device using normal | ||
346 | driver model calls. | ||
347 | </para> | ||
348 | <para> | ||
349 | The I/O model is a set of queued messages. Protocol drivers | ||
350 | submit one or more <structname>struct spi_message</structname> | ||
351 | objects, which are processed and completed asynchronously. | ||
352 | (There are synchronous wrappers, however.) Messages are | ||
353 | built from one or more <structname>struct spi_transfer</structname> | ||
354 | objects, each of which wraps a full duplex SPI transfer. | ||
355 | A variety of protocol tweaking options are needed, because | ||
356 | different chips adopt very different policies for how they | ||
357 | use the bits transferred with SPI. | ||
358 | </para> | ||
359 | !Iinclude/linux/spi/spi.h | ||
360 | !Fdrivers/spi/spi.c spi_register_board_info | ||
361 | !Edrivers/spi/spi.c | ||
362 | </chapter> | ||
363 | |||
364 | <chapter id="i2c"> | ||
365 | <title>I<superscript>2</superscript>C and SMBus Subsystem</title> | ||
366 | |||
367 | <para> | ||
368 | I<superscript>2</superscript>C (or without fancy typography, "I2C") | ||
369 | is an acronym for the "Inter-IC" bus, a simple bus protocol which is | ||
370 | widely used where low data rate communications suffice. | ||
371 | Since it's also a licensed trademark, some vendors use another | ||
372 | name (such as "Two-Wire Interface", TWI) for the same bus. | ||
373 | I2C only needs two signals (SCL for clock, SDA for data), conserving | ||
374 | board real estate and minimizing signal quality issues. | ||
375 | Most I2C devices use seven bit addresses, and bus speeds of up | ||
376 | to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet | ||
377 | found wide use. | ||
378 | I2C is a multi-master bus; open drain signaling is used to | ||
379 | arbitrate between masters, as well as to handshake and to | ||
380 | synchronize clocks from slower clients. | ||
381 | </para> | ||
382 | |||
383 | <para> | ||
384 | The Linux I2C programming interfaces support only the master | ||
385 | side of bus interactions, not the slave side. | ||
386 | The programming interface is structured around two kinds of driver, | ||
387 | and two kinds of device. | ||
388 | An I2C "Adapter Driver" abstracts the controller hardware; it binds | ||
389 | to a physical device (perhaps a PCI device or platform_device) and | ||
390 | exposes a <structname>struct i2c_adapter</structname> representing | ||
391 | each I2C bus segment it manages. | ||
392 | On each I2C bus segment will be I2C devices represented by a | ||
393 | <structname>struct i2c_client</structname>. Those devices will | ||
394 | be bound to a <structname>struct i2c_driver</structname>, | ||
395 | which should follow the standard Linux driver model. | ||
396 | (At this writing, a legacy model is more widely used.) | ||
397 | There are functions to perform various I2C protocol operations; at | ||
398 | this writing all such functions are usable only from task context. | ||
399 | </para> | ||
400 | |||
401 | <para> | ||
402 | The System Management Bus (SMBus) is a sibling protocol. Most SMBus | ||
403 | systems are also I2C conformant. The electrical constraints are | ||
404 | tighter for SMBus, and it standardizes particular protocol messages | ||
405 | and idioms. Controllers that support I2C can also support most | ||
406 | SMBus operations, but SMBus controllers don't support all the protocol | ||
407 | options that an I2C controller will. | ||
408 | There are functions to perform various SMBus protocol operations, | ||
409 | either using I2C primitives or by issuing SMBus commands to | ||
410 | i2c_adapter devices which don't support those I2C operations. | ||
411 | </para> | ||
412 | |||
413 | !Iinclude/linux/i2c.h | ||
414 | !Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info | ||
415 | !Edrivers/i2c/i2c-core.c | ||
416 | </chapter> | ||
417 | |||
418 | </book> | ||
diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl index 3a882d9a90a9..c671a0168096 100644 --- a/Documentation/DocBook/genericirq.tmpl +++ b/Documentation/DocBook/genericirq.tmpl | |||
@@ -440,6 +440,7 @@ desc->chip->end(); | |||
440 | used in the generic IRQ layer. | 440 | used in the generic IRQ layer. |
441 | </para> | 441 | </para> |
442 | !Iinclude/linux/irq.h | 442 | !Iinclude/linux/irq.h |
443 | !Iinclude/linux/interrupt.h | ||
443 | </chapter> | 444 | </chapter> |
444 | 445 | ||
445 | <chapter id="pubfunctions"> | 446 | <chapter id="pubfunctions"> |
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 5818ff75786a..d6ac5d61820e 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl | |||
@@ -38,58 +38,6 @@ | |||
38 | 38 | ||
39 | <toc></toc> | 39 | <toc></toc> |
40 | 40 | ||
41 | <chapter id="Basics"> | ||
42 | <title>Driver Basics</title> | ||
43 | <sect1><title>Driver Entry and Exit points</title> | ||
44 | !Iinclude/linux/init.h | ||
45 | </sect1> | ||
46 | |||
47 | <sect1><title>Atomic and pointer manipulation</title> | ||
48 | !Iarch/x86/include/asm/atomic_32.h | ||
49 | !Iarch/x86/include/asm/unaligned.h | ||
50 | </sect1> | ||
51 | |||
52 | <sect1><title>Delaying, scheduling, and timer routines</title> | ||
53 | !Iinclude/linux/sched.h | ||
54 | !Ekernel/sched.c | ||
55 | !Ekernel/timer.c | ||
56 | </sect1> | ||
57 | <sect1><title>High-resolution timers</title> | ||
58 | !Iinclude/linux/ktime.h | ||
59 | !Iinclude/linux/hrtimer.h | ||
60 | !Ekernel/hrtimer.c | ||
61 | </sect1> | ||
62 | <sect1><title>Workqueues and Kevents</title> | ||
63 | !Ekernel/workqueue.c | ||
64 | </sect1> | ||
65 | <sect1><title>Internal Functions</title> | ||
66 | !Ikernel/exit.c | ||
67 | !Ikernel/signal.c | ||
68 | !Iinclude/linux/kthread.h | ||
69 | !Ekernel/kthread.c | ||
70 | </sect1> | ||
71 | |||
72 | <sect1><title>Kernel objects manipulation</title> | ||
73 | <!-- | ||
74 | X!Iinclude/linux/kobject.h | ||
75 | --> | ||
76 | !Elib/kobject.c | ||
77 | </sect1> | ||
78 | |||
79 | <sect1><title>Kernel utility functions</title> | ||
80 | !Iinclude/linux/kernel.h | ||
81 | !Ekernel/printk.c | ||
82 | !Ekernel/panic.c | ||
83 | !Ekernel/sys.c | ||
84 | !Ekernel/rcupdate.c | ||
85 | </sect1> | ||
86 | |||
87 | <sect1><title>Device Resource Management</title> | ||
88 | !Edrivers/base/devres.c | ||
89 | </sect1> | ||
90 | |||
91 | </chapter> | ||
92 | |||
93 | <chapter id="adt"> | 41 | <chapter id="adt"> |
94 | <title>Data Types</title> | 42 | <title>Data Types</title> |
95 | <sect1><title>Doubly Linked Lists</title> | 43 | <sect1><title>Doubly Linked Lists</title> |
@@ -251,6 +199,7 @@ X!Edrivers/pci/hotplug.c | |||
251 | --> | 199 | --> |
252 | !Edrivers/pci/probe.c | 200 | !Edrivers/pci/probe.c |
253 | !Edrivers/pci/rom.c | 201 | !Edrivers/pci/rom.c |
202 | !Edrivers/pci/iov.c | ||
254 | </sect1> | 203 | </sect1> |
255 | <sect1><title>PCI Hotplug Support Library</title> | 204 | <sect1><title>PCI Hotplug Support Library</title> |
256 | !Edrivers/pci/hotplug/pci_hotplug_core.c | 205 | !Edrivers/pci/hotplug/pci_hotplug_core.c |
@@ -298,62 +247,6 @@ X!Earch/x86/kernel/mca_32.c | |||
298 | !Ikernel/acct.c | 247 | !Ikernel/acct.c |
299 | </chapter> | 248 | </chapter> |
300 | 249 | ||
301 | <chapter id="devdrivers"> | ||
302 | <title>Device drivers infrastructure</title> | ||
303 | <sect1><title>Device Drivers Base</title> | ||
304 | <!-- | ||
305 | X!Iinclude/linux/device.h | ||
306 | --> | ||
307 | !Edrivers/base/driver.c | ||
308 | !Edrivers/base/core.c | ||
309 | !Edrivers/base/class.c | ||
310 | !Edrivers/base/firmware_class.c | ||
311 | !Edrivers/base/transport_class.c | ||
312 | <!-- Cannot be included, because | ||
313 | attribute_container_add_class_device_adapter | ||
314 | and attribute_container_classdev_to_container | ||
315 | exceed allowed 44 characters maximum | ||
316 | X!Edrivers/base/attribute_container.c | ||
317 | --> | ||
318 | !Edrivers/base/sys.c | ||
319 | <!-- | ||
320 | X!Edrivers/base/interface.c | ||
321 | --> | ||
322 | !Edrivers/base/platform.c | ||
323 | !Edrivers/base/bus.c | ||
324 | </sect1> | ||
325 | <sect1><title>Device Drivers Power Management</title> | ||
326 | !Edrivers/base/power/main.c | ||
327 | </sect1> | ||
328 | <sect1><title>Device Drivers ACPI Support</title> | ||
329 | <!-- Internal functions only | ||
330 | X!Edrivers/acpi/sleep/main.c | ||
331 | X!Edrivers/acpi/sleep/wakeup.c | ||
332 | X!Edrivers/acpi/motherboard.c | ||
333 | X!Edrivers/acpi/bus.c | ||
334 | --> | ||
335 | !Edrivers/acpi/scan.c | ||
336 | !Idrivers/acpi/scan.c | ||
337 | <!-- No correct structured comments | ||
338 | X!Edrivers/acpi/pci_bind.c | ||
339 | --> | ||
340 | </sect1> | ||
341 | <sect1><title>Device drivers PnP support</title> | ||
342 | !Idrivers/pnp/core.c | ||
343 | <!-- No correct structured comments | ||
344 | X!Edrivers/pnp/system.c | ||
345 | --> | ||
346 | !Edrivers/pnp/card.c | ||
347 | !Idrivers/pnp/driver.c | ||
348 | !Edrivers/pnp/manager.c | ||
349 | !Edrivers/pnp/support.c | ||
350 | </sect1> | ||
351 | <sect1><title>Userspace IO devices</title> | ||
352 | !Edrivers/uio/uio.c | ||
353 | !Iinclude/linux/uio_driver.h | ||
354 | </sect1> | ||
355 | </chapter> | ||
356 | |||
357 | <chapter id="blkdev"> | 250 | <chapter id="blkdev"> |
358 | <title>Block Devices</title> | 251 | <title>Block Devices</title> |
359 | !Eblock/blk-core.c | 252 | !Eblock/blk-core.c |
@@ -366,7 +259,7 @@ X!Edrivers/pnp/system.c | |||
366 | !Eblock/blk-tag.c | 259 | !Eblock/blk-tag.c |
367 | !Iblock/blk-tag.c | 260 | !Iblock/blk-tag.c |
368 | !Eblock/blk-integrity.c | 261 | !Eblock/blk-integrity.c |
369 | !Iblock/blktrace.c | 262 | !Ikernel/trace/blktrace.c |
370 | !Iblock/genhd.c | 263 | !Iblock/genhd.c |
371 | !Eblock/genhd.c | 264 | !Eblock/genhd.c |
372 | </chapter> | 265 | </chapter> |
@@ -381,275 +274,6 @@ X!Edrivers/pnp/system.c | |||
381 | !Edrivers/char/misc.c | 274 | !Edrivers/char/misc.c |
382 | </chapter> | 275 | </chapter> |
383 | 276 | ||
384 | <chapter id="parportdev"> | ||
385 | <title>Parallel Port Devices</title> | ||
386 | !Iinclude/linux/parport.h | ||
387 | !Edrivers/parport/ieee1284.c | ||
388 | !Edrivers/parport/share.c | ||
389 | !Idrivers/parport/daisy.c | ||
390 | </chapter> | ||
391 | |||
392 | <chapter id="message_devices"> | ||
393 | <title>Message-based devices</title> | ||
394 | <sect1><title>Fusion message devices</title> | ||
395 | !Edrivers/message/fusion/mptbase.c | ||
396 | !Idrivers/message/fusion/mptbase.c | ||
397 | !Edrivers/message/fusion/mptscsih.c | ||
398 | !Idrivers/message/fusion/mptscsih.c | ||
399 | !Idrivers/message/fusion/mptctl.c | ||
400 | !Idrivers/message/fusion/mptspi.c | ||
401 | !Idrivers/message/fusion/mptfc.c | ||
402 | !Idrivers/message/fusion/mptlan.c | ||
403 | </sect1> | ||
404 | <sect1><title>I2O message devices</title> | ||
405 | !Iinclude/linux/i2o.h | ||
406 | !Idrivers/message/i2o/core.h | ||
407 | !Edrivers/message/i2o/iop.c | ||
408 | !Idrivers/message/i2o/iop.c | ||
409 | !Idrivers/message/i2o/config-osm.c | ||
410 | !Edrivers/message/i2o/exec-osm.c | ||
411 | !Idrivers/message/i2o/exec-osm.c | ||
412 | !Idrivers/message/i2o/bus-osm.c | ||
413 | !Edrivers/message/i2o/device.c | ||
414 | !Idrivers/message/i2o/device.c | ||
415 | !Idrivers/message/i2o/driver.c | ||
416 | !Idrivers/message/i2o/pci.c | ||
417 | !Idrivers/message/i2o/i2o_block.c | ||
418 | !Idrivers/message/i2o/i2o_scsi.c | ||
419 | !Idrivers/message/i2o/i2o_proc.c | ||
420 | </sect1> | ||
421 | </chapter> | ||
422 | |||
423 | <chapter id="snddev"> | ||
424 | <title>Sound Devices</title> | ||
425 | !Iinclude/sound/core.h | ||
426 | !Esound/sound_core.c | ||
427 | !Iinclude/sound/pcm.h | ||
428 | !Esound/core/pcm.c | ||
429 | !Esound/core/device.c | ||
430 | !Esound/core/info.c | ||
431 | !Esound/core/rawmidi.c | ||
432 | !Esound/core/sound.c | ||
433 | !Esound/core/memory.c | ||
434 | !Esound/core/pcm_memory.c | ||
435 | !Esound/core/init.c | ||
436 | !Esound/core/isadma.c | ||
437 | !Esound/core/control.c | ||
438 | !Esound/core/pcm_lib.c | ||
439 | !Esound/core/hwdep.c | ||
440 | !Esound/core/pcm_native.c | ||
441 | !Esound/core/memalloc.c | ||
442 | <!-- FIXME: Removed for now since no structured comments in source | ||
443 | X!Isound/sound_firmware.c | ||
444 | --> | ||
445 | </chapter> | ||
446 | |||
447 | <chapter id="uart16x50"> | ||
448 | <title>16x50 UART Driver</title> | ||
449 | !Iinclude/linux/serial_core.h | ||
450 | !Edrivers/serial/serial_core.c | ||
451 | !Edrivers/serial/8250.c | ||
452 | </chapter> | ||
453 | |||
454 | <chapter id="fbdev"> | ||
455 | <title>Frame Buffer Library</title> | ||
456 | |||
457 | <para> | ||
458 | The frame buffer drivers depend heavily on four data structures. | ||
459 | These structures are declared in include/linux/fb.h. They are | ||
460 | fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs. | ||
461 | The last three can be made available to and from userland. | ||
462 | </para> | ||
463 | |||
464 | <para> | ||
465 | fb_info defines the current state of a particular video card. | ||
466 | Inside fb_info, there exists a fb_ops structure which is a | ||
467 | collection of needed functions to make fbdev and fbcon work. | ||
468 | fb_info is only visible to the kernel. | ||
469 | </para> | ||
470 | |||
471 | <para> | ||
472 | fb_var_screeninfo is used to describe the features of a video card | ||
473 | that are user defined. With fb_var_screeninfo, things such as | ||
474 | depth and the resolution may be defined. | ||
475 | </para> | ||
476 | |||
477 | <para> | ||
478 | The next structure is fb_fix_screeninfo. This defines the | ||
479 | properties of a card that are created when a mode is set and can't | ||
480 | be changed otherwise. A good example of this is the start of the | ||
481 | frame buffer memory. This "locks" the address of the frame buffer | ||
482 | memory, so that it cannot be changed or moved. | ||
483 | </para> | ||
484 | |||
485 | <para> | ||
486 | The last structure is fb_monospecs. In the old API, there was | ||
487 | little importance for fb_monospecs. This allowed for forbidden things | ||
488 | such as setting a mode of 800x600 on a fix frequency monitor. With | ||
489 | the new API, fb_monospecs prevents such things, and if used | ||
490 | correctly, can prevent a monitor from being cooked. fb_monospecs | ||
491 | will not be useful until kernels 2.5.x. | ||
492 | </para> | ||
493 | |||
494 | <sect1><title>Frame Buffer Memory</title> | ||
495 | !Edrivers/video/fbmem.c | ||
496 | </sect1> | ||
497 | <!-- | ||
498 | <sect1><title>Frame Buffer Console</title> | ||
499 | X!Edrivers/video/console/fbcon.c | ||
500 | </sect1> | ||
501 | --> | ||
502 | <sect1><title>Frame Buffer Colormap</title> | ||
503 | !Edrivers/video/fbcmap.c | ||
504 | </sect1> | ||
505 | <!-- FIXME: | ||
506 | drivers/video/fbgen.c has no docs, which stuffs up the sgml. Comment | ||
507 | out until somebody adds docs. KAO | ||
508 | <sect1><title>Frame Buffer Generic Functions</title> | ||
509 | X!Idrivers/video/fbgen.c | ||
510 | </sect1> | ||
511 | KAO --> | ||
512 | <sect1><title>Frame Buffer Video Mode Database</title> | ||
513 | !Idrivers/video/modedb.c | ||
514 | !Edrivers/video/modedb.c | ||
515 | </sect1> | ||
516 | <sect1><title>Frame Buffer Macintosh Video Mode Database</title> | ||
517 | !Edrivers/video/macmodes.c | ||
518 | </sect1> | ||
519 | <sect1><title>Frame Buffer Fonts</title> | ||
520 | <para> | ||
521 | Refer to the file drivers/video/console/fonts.c for more information. | ||
522 | </para> | ||
523 | <!-- FIXME: Removed for now since no structured comments in source | ||
524 | X!Idrivers/video/console/fonts.c | ||
525 | --> | ||
526 | </sect1> | ||
527 | </chapter> | ||
528 | |||
529 | <chapter id="input_subsystem"> | ||
530 | <title>Input Subsystem</title> | ||
531 | !Iinclude/linux/input.h | ||
532 | !Edrivers/input/input.c | ||
533 | !Edrivers/input/ff-core.c | ||
534 | !Edrivers/input/ff-memless.c | ||
535 | </chapter> | ||
536 | |||
537 | <chapter id="spi"> | ||
538 | <title>Serial Peripheral Interface (SPI)</title> | ||
539 | <para> | ||
540 | SPI is the "Serial Peripheral Interface", widely used with | ||
541 | embedded systems because it is a simple and efficient | ||
542 | interface: basically a multiplexed shift register. | ||
543 | Its three signal wires hold a clock (SCK, often in the range | ||
544 | of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and | ||
545 | a "Master In, Slave Out" (MISO) data line. | ||
546 | SPI is a full duplex protocol; for each bit shifted out the | ||
547 | MOSI line (one per clock) another is shifted in on the MISO line. | ||
548 | Those bits are assembled into words of various sizes on the | ||
549 | way to and from system memory. | ||
550 | An additional chipselect line is usually active-low (nCS); | ||
551 | four signals are normally used for each peripheral, plus | ||
552 | sometimes an interrupt. | ||
553 | </para> | ||
554 | <para> | ||
555 | The SPI bus facilities listed here provide a generalized | ||
556 | interface to declare SPI busses and devices, manage them | ||
557 | according to the standard Linux driver model, and perform | ||
558 | input/output operations. | ||
559 | At this time, only "master" side interfaces are supported, | ||
560 | where Linux talks to SPI peripherals and does not implement | ||
561 | such a peripheral itself. | ||
562 | (Interfaces to support implementing SPI slaves would | ||
563 | necessarily look different.) | ||
564 | </para> | ||
565 | <para> | ||
566 | The programming interface is structured around two kinds of driver, | ||
567 | and two kinds of device. | ||
568 | A "Controller Driver" abstracts the controller hardware, which may | ||
569 | be as simple as a set of GPIO pins or as complex as a pair of FIFOs | ||
570 | connected to dual DMA engines on the other side of the SPI shift | ||
571 | register (maximizing throughput). Such drivers bridge between | ||
572 | whatever bus they sit on (often the platform bus) and SPI, and | ||
573 | expose the SPI side of their device as a | ||
574 | <structname>struct spi_master</structname>. | ||
575 | SPI devices are children of that master, represented as a | ||
576 | <structname>struct spi_device</structname> and manufactured from | ||
577 | <structname>struct spi_board_info</structname> descriptors which | ||
578 | are usually provided by board-specific initialization code. | ||
579 | A <structname>struct spi_driver</structname> is called a | ||
580 | "Protocol Driver", and is bound to a spi_device using normal | ||
581 | driver model calls. | ||
582 | </para> | ||
583 | <para> | ||
584 | The I/O model is a set of queued messages. Protocol drivers | ||
585 | submit one or more <structname>struct spi_message</structname> | ||
586 | objects, which are processed and completed asynchronously. | ||
587 | (There are synchronous wrappers, however.) Messages are | ||
588 | built from one or more <structname>struct spi_transfer</structname> | ||
589 | objects, each of which wraps a full duplex SPI transfer. | ||
590 | A variety of protocol tweaking options are needed, because | ||
591 | different chips adopt very different policies for how they | ||
592 | use the bits transferred with SPI. | ||
593 | </para> | ||
594 | !Iinclude/linux/spi/spi.h | ||
595 | !Fdrivers/spi/spi.c spi_register_board_info | ||
596 | !Edrivers/spi/spi.c | ||
597 | </chapter> | ||
598 | |||
599 | <chapter id="i2c"> | ||
600 | <title>I<superscript>2</superscript>C and SMBus Subsystem</title> | ||
601 | |||
602 | <para> | ||
603 | I<superscript>2</superscript>C (or without fancy typography, "I2C") | ||
604 | is an acronym for the "Inter-IC" bus, a simple bus protocol which is | ||
605 | widely used where low data rate communications suffice. | ||
606 | Since it's also a licensed trademark, some vendors use another | ||
607 | name (such as "Two-Wire Interface", TWI) for the same bus. | ||
608 | I2C only needs two signals (SCL for clock, SDA for data), conserving | ||
609 | board real estate and minimizing signal quality issues. | ||
610 | Most I2C devices use seven bit addresses, and bus speeds of up | ||
611 | to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet | ||
612 | found wide use. | ||
613 | I2C is a multi-master bus; open drain signaling is used to | ||
614 | arbitrate between masters, as well as to handshake and to | ||
615 | synchronize clocks from slower clients. | ||
616 | </para> | ||
617 | |||
618 | <para> | ||
619 | The Linux I2C programming interfaces support only the master | ||
620 | side of bus interactions, not the slave side. | ||
621 | The programming interface is structured around two kinds of driver, | ||
622 | and two kinds of device. | ||
623 | An I2C "Adapter Driver" abstracts the controller hardware; it binds | ||
624 | to a physical device (perhaps a PCI device or platform_device) and | ||
625 | exposes a <structname>struct i2c_adapter</structname> representing | ||
626 | each I2C bus segment it manages. | ||
627 | On each I2C bus segment will be I2C devices represented by a | ||
628 | <structname>struct i2c_client</structname>. Those devices will | ||
629 | be bound to a <structname>struct i2c_driver</structname>, | ||
630 | which should follow the standard Linux driver model. | ||
631 | (At this writing, a legacy model is more widely used.) | ||
632 | There are functions to perform various I2C protocol operations; at | ||
633 | this writing all such functions are usable only from task context. | ||
634 | </para> | ||
635 | |||
636 | <para> | ||
637 | The System Management Bus (SMBus) is a sibling protocol. Most SMBus | ||
638 | systems are also I2C conformant. The electrical constraints are | ||
639 | tighter for SMBus, and it standardizes particular protocol messages | ||
640 | and idioms. Controllers that support I2C can also support most | ||
641 | SMBus operations, but SMBus controllers don't support all the protocol | ||
642 | options that an I2C controller will. | ||
643 | There are functions to perform various SMBus protocol operations, | ||
644 | either using I2C primitives or by issuing SMBus commands to | ||
645 | i2c_adapter devices which don't support those I2C operations. | ||
646 | </para> | ||
647 | |||
648 | !Iinclude/linux/i2c.h | ||
649 | !Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info | ||
650 | !Edrivers/i2c/i2c-core.c | ||
651 | </chapter> | ||
652 | |||
653 | <chapter id="clk"> | 277 | <chapter id="clk"> |
654 | <title>Clock Framework</title> | 278 | <title>Clock Framework</title> |
655 | 279 | ||
diff --git a/Documentation/DocBook/mac80211.tmpl b/Documentation/DocBook/mac80211.tmpl index 77c3c202991b..fbeaffc1dcc3 100644 --- a/Documentation/DocBook/mac80211.tmpl +++ b/Documentation/DocBook/mac80211.tmpl | |||
@@ -17,8 +17,7 @@ | |||
17 | </authorgroup> | 17 | </authorgroup> |
18 | 18 | ||
19 | <copyright> | 19 | <copyright> |
20 | <year>2007</year> | 20 | <year>2007-2009</year> |
21 | <year>2008</year> | ||
22 | <holder>Johannes Berg</holder> | 21 | <holder>Johannes Berg</holder> |
23 | </copyright> | 22 | </copyright> |
24 | 23 | ||
@@ -165,8 +164,8 @@ usage should require reading the full document. | |||
165 | !Pinclude/net/mac80211.h Frame format | 164 | !Pinclude/net/mac80211.h Frame format |
166 | </sect1> | 165 | </sect1> |
167 | <sect1> | 166 | <sect1> |
168 | <title>Alignment issues</title> | 167 | <title>Packet alignment</title> |
169 | <para>TBD</para> | 168 | !Pnet/mac80211/rx.c Packet alignment |
170 | </sect1> | 169 | </sect1> |
171 | <sect1> | 170 | <sect1> |
172 | <title>Calling into mac80211 from interrupts</title> | 171 | <title>Calling into mac80211 from interrupts</title> |
@@ -223,6 +222,17 @@ usage should require reading the full document. | |||
223 | !Finclude/net/mac80211.h ieee80211_key_flags | 222 | !Finclude/net/mac80211.h ieee80211_key_flags |
224 | </chapter> | 223 | </chapter> |
225 | 224 | ||
225 | <chapter id="powersave"> | ||
226 | <title>Powersave support</title> | ||
227 | !Pinclude/net/mac80211.h Powersave support | ||
228 | </chapter> | ||
229 | |||
230 | <chapter id="beacon-filter"> | ||
231 | <title>Beacon filter support</title> | ||
232 | !Pinclude/net/mac80211.h Beacon filter support | ||
233 | !Finclude/net/mac80211.h ieee80211_beacon_loss | ||
234 | </chapter> | ||
235 | |||
226 | <chapter id="qos"> | 236 | <chapter id="qos"> |
227 | <title>Multiple queues and QoS support</title> | 237 | <title>Multiple queues and QoS support</title> |
228 | <para>TBD</para> | 238 | <para>TBD</para> |
diff --git a/Documentation/DocBook/procfs_example.c b/Documentation/DocBook/procfs_example.c index 8c6396e4bf31..a5b11793b1e0 100644 --- a/Documentation/DocBook/procfs_example.c +++ b/Documentation/DocBook/procfs_example.c | |||
@@ -117,9 +117,6 @@ static int __init init_procfs_example(void) | |||
117 | rv = -ENOMEM; | 117 | rv = -ENOMEM; |
118 | goto out; | 118 | goto out; |
119 | } | 119 | } |
120 | |||
121 | example_dir->owner = THIS_MODULE; | ||
122 | |||
123 | /* create jiffies using convenience function */ | 120 | /* create jiffies using convenience function */ |
124 | jiffies_file = create_proc_read_entry("jiffies", | 121 | jiffies_file = create_proc_read_entry("jiffies", |
125 | 0444, example_dir, | 122 | 0444, example_dir, |
@@ -130,8 +127,6 @@ static int __init init_procfs_example(void) | |||
130 | goto no_jiffies; | 127 | goto no_jiffies; |
131 | } | 128 | } |
132 | 129 | ||
133 | jiffies_file->owner = THIS_MODULE; | ||
134 | |||
135 | /* create foo and bar files using same callback | 130 | /* create foo and bar files using same callback |
136 | * functions | 131 | * functions |
137 | */ | 132 | */ |
@@ -146,7 +141,6 @@ static int __init init_procfs_example(void) | |||
146 | foo_file->data = &foo_data; | 141 | foo_file->data = &foo_data; |
147 | foo_file->read_proc = proc_read_foobar; | 142 | foo_file->read_proc = proc_read_foobar; |
148 | foo_file->write_proc = proc_write_foobar; | 143 | foo_file->write_proc = proc_write_foobar; |
149 | foo_file->owner = THIS_MODULE; | ||
150 | 144 | ||
151 | bar_file = create_proc_entry("bar", 0644, example_dir); | 145 | bar_file = create_proc_entry("bar", 0644, example_dir); |
152 | if(bar_file == NULL) { | 146 | if(bar_file == NULL) { |
@@ -159,7 +153,6 @@ static int __init init_procfs_example(void) | |||
159 | bar_file->data = &bar_data; | 153 | bar_file->data = &bar_data; |
160 | bar_file->read_proc = proc_read_foobar; | 154 | bar_file->read_proc = proc_read_foobar; |
161 | bar_file->write_proc = proc_write_foobar; | 155 | bar_file->write_proc = proc_write_foobar; |
162 | bar_file->owner = THIS_MODULE; | ||
163 | 156 | ||
164 | /* create symlink */ | 157 | /* create symlink */ |
165 | symlink = proc_symlink("jiffies_too", example_dir, | 158 | symlink = proc_symlink("jiffies_too", example_dir, |
@@ -169,8 +162,6 @@ static int __init init_procfs_example(void) | |||
169 | goto no_symlink; | 162 | goto no_symlink; |
170 | } | 163 | } |
171 | 164 | ||
172 | symlink->owner = THIS_MODULE; | ||
173 | |||
174 | /* everything OK */ | 165 | /* everything OK */ |
175 | printk(KERN_INFO "%s %s initialised\n", | 166 | printk(KERN_INFO "%s %s initialised\n", |
176 | MODULE_NAME, MODULE_VERS); | 167 | MODULE_NAME, MODULE_VERS); |
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index 52e1b79ce0e6..8f6e3b2403c7 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl | |||
@@ -42,6 +42,13 @@ GPL version 2. | |||
42 | 42 | ||
43 | <revhistory> | 43 | <revhistory> |
44 | <revision> | 44 | <revision> |
45 | <revnumber>0.8</revnumber> | ||
46 | <date>2008-12-24</date> | ||
47 | <authorinitials>hjk</authorinitials> | ||
48 | <revremark>Added name attributes in mem and portio sysfs directories. | ||
49 | </revremark> | ||
50 | </revision> | ||
51 | <revision> | ||
45 | <revnumber>0.7</revnumber> | 52 | <revnumber>0.7</revnumber> |
46 | <date>2008-12-23</date> | 53 | <date>2008-12-23</date> |
47 | <authorinitials>hjk</authorinitials> | 54 | <authorinitials>hjk</authorinitials> |
@@ -303,12 +310,19 @@ interested in translating it, please email me | |||
303 | appear if the size of the mapping is not 0. | 310 | appear if the size of the mapping is not 0. |
304 | </para> | 311 | </para> |
305 | <para> | 312 | <para> |
306 | Each <filename>mapX/</filename> directory contains two read-only files | 313 | Each <filename>mapX/</filename> directory contains four read-only files |
307 | that show start address and size of the memory: | 314 | that show attributes of the memory: |
308 | </para> | 315 | </para> |
309 | <itemizedlist> | 316 | <itemizedlist> |
310 | <listitem> | 317 | <listitem> |
311 | <para> | 318 | <para> |
319 | <filename>name</filename>: A string identifier for this mapping. This | ||
320 | is optional, the string can be empty. Drivers can set this to make it | ||
321 | easier for userspace to find the correct mapping. | ||
322 | </para> | ||
323 | </listitem> | ||
324 | <listitem> | ||
325 | <para> | ||
312 | <filename>addr</filename>: The address of memory that can be mapped. | 326 | <filename>addr</filename>: The address of memory that can be mapped. |
313 | </para> | 327 | </para> |
314 | </listitem> | 328 | </listitem> |
@@ -366,12 +380,19 @@ offset = N * getpagesize(); | |||
366 | <filename>/sys/class/uio/uioX/portio/</filename>. | 380 | <filename>/sys/class/uio/uioX/portio/</filename>. |
367 | </para> | 381 | </para> |
368 | <para> | 382 | <para> |
369 | Each <filename>portX/</filename> directory contains three read-only | 383 | Each <filename>portX/</filename> directory contains four read-only |
370 | files that show start, size, and type of the port region: | 384 | files that show name, start, size, and type of the port region: |
371 | </para> | 385 | </para> |
372 | <itemizedlist> | 386 | <itemizedlist> |
373 | <listitem> | 387 | <listitem> |
374 | <para> | 388 | <para> |
389 | <filename>name</filename>: A string identifier for this port region. | ||
390 | The string is optional and can be empty. Drivers can set it to make it | ||
391 | easier for userspace to find a certain port region. | ||
392 | </para> | ||
393 | </listitem> | ||
394 | <listitem> | ||
395 | <para> | ||
375 | <filename>start</filename>: The first port of this region. | 396 | <filename>start</filename>: The first port of this region. |
376 | </para> | 397 | </para> |
377 | </listitem> | 398 | </listitem> |
diff --git a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl index 87a7c07ab658..7a2e0e98986a 100644 --- a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl | |||
@@ -1,11 +1,11 @@ | |||
1 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> | 1 | <?xml version="1.0" encoding="UTF-8"?> |
2 | 2 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" | |
3 | <book> | 3 | "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> |
4 | <?dbhtml filename="index.html"> | ||
5 | 4 | ||
6 | <!-- ****************************************************** --> | 5 | <!-- ****************************************************** --> |
7 | <!-- Header --> | 6 | <!-- Header --> |
8 | <!-- ****************************************************** --> | 7 | <!-- ****************************************************** --> |
8 | <book id="Writing-an-ALSA-Driver"> | ||
9 | <bookinfo> | 9 | <bookinfo> |
10 | <title>Writing an ALSA Driver</title> | 10 | <title>Writing an ALSA Driver</title> |
11 | <author> | 11 | <author> |
@@ -492,9 +492,9 @@ | |||
492 | } | 492 | } |
493 | 493 | ||
494 | /* (2) */ | 494 | /* (2) */ |
495 | card = snd_card_new(index[dev], id[dev], THIS_MODULE, 0); | 495 | err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card); |
496 | if (card == NULL) | 496 | if (err < 0) |
497 | return -ENOMEM; | 497 | return err; |
498 | 498 | ||
499 | /* (3) */ | 499 | /* (3) */ |
500 | err = snd_mychip_create(card, pci, &chip); | 500 | err = snd_mychip_create(card, pci, &chip); |
@@ -590,8 +590,9 @@ | |||
590 | <programlisting> | 590 | <programlisting> |
591 | <![CDATA[ | 591 | <![CDATA[ |
592 | struct snd_card *card; | 592 | struct snd_card *card; |
593 | int err; | ||
593 | .... | 594 | .... |
594 | card = snd_card_new(index[dev], id[dev], THIS_MODULE, 0); | 595 | err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card); |
595 | ]]> | 596 | ]]> |
596 | </programlisting> | 597 | </programlisting> |
597 | </informalexample> | 598 | </informalexample> |
@@ -809,26 +810,28 @@ | |||
809 | 810 | ||
810 | <para> | 811 | <para> |
811 | As mentioned above, to create a card instance, call | 812 | As mentioned above, to create a card instance, call |
812 | <function>snd_card_new()</function>. | 813 | <function>snd_card_create()</function>. |
813 | 814 | ||
814 | <informalexample> | 815 | <informalexample> |
815 | <programlisting> | 816 | <programlisting> |
816 | <![CDATA[ | 817 | <![CDATA[ |
817 | struct snd_card *card; | 818 | struct snd_card *card; |
818 | card = snd_card_new(index, id, module, extra_size); | 819 | int err; |
820 | err = snd_card_create(index, id, module, extra_size, &card); | ||
819 | ]]> | 821 | ]]> |
820 | </programlisting> | 822 | </programlisting> |
821 | </informalexample> | 823 | </informalexample> |
822 | </para> | 824 | </para> |
823 | 825 | ||
824 | <para> | 826 | <para> |
825 | The function takes four arguments, the card-index number, the | 827 | The function takes five arguments, the card-index number, the |
826 | id string, the module pointer (usually | 828 | id string, the module pointer (usually |
827 | <constant>THIS_MODULE</constant>), | 829 | <constant>THIS_MODULE</constant>), |
828 | and the size of extra-data space. The last argument is used to | 830 | the size of extra-data space, and the pointer to return the |
831 | card instance. The extra_size argument is used to | ||
829 | allocate card->private_data for the | 832 | allocate card->private_data for the |
830 | chip-specific data. Note that these data | 833 | chip-specific data. Note that these data |
831 | are allocated by <function>snd_card_new()</function>. | 834 | are allocated by <function>snd_card_create()</function>. |
832 | </para> | 835 | </para> |
833 | </section> | 836 | </section> |
834 | 837 | ||
@@ -915,15 +918,16 @@ | |||
915 | </para> | 918 | </para> |
916 | 919 | ||
917 | <section id="card-management-chip-specific-snd-card-new"> | 920 | <section id="card-management-chip-specific-snd-card-new"> |
918 | <title>1. Allocating via <function>snd_card_new()</function>.</title> | 921 | <title>1. Allocating via <function>snd_card_create()</function>.</title> |
919 | <para> | 922 | <para> |
920 | As mentioned above, you can pass the extra-data-length | 923 | As mentioned above, you can pass the extra-data-length |
921 | to the 4th argument of <function>snd_card_new()</function>, i.e. | 924 | to the 4th argument of <function>snd_card_create()</function>, i.e. |
922 | 925 | ||
923 | <informalexample> | 926 | <informalexample> |
924 | <programlisting> | 927 | <programlisting> |
925 | <![CDATA[ | 928 | <![CDATA[ |
926 | card = snd_card_new(index[dev], id[dev], THIS_MODULE, sizeof(struct mychip)); | 929 | err = snd_card_create(index[dev], id[dev], THIS_MODULE, |
930 | sizeof(struct mychip), &card); | ||
927 | ]]> | 931 | ]]> |
928 | </programlisting> | 932 | </programlisting> |
929 | </informalexample> | 933 | </informalexample> |
@@ -952,8 +956,8 @@ | |||
952 | 956 | ||
953 | <para> | 957 | <para> |
954 | After allocating a card instance via | 958 | After allocating a card instance via |
955 | <function>snd_card_new()</function> (with | 959 | <function>snd_card_create()</function> (with |
956 | <constant>NULL</constant> on the 4th arg), call | 960 | <constant>0</constant> on the 4th arg), call |
957 | <function>kzalloc()</function>. | 961 | <function>kzalloc()</function>. |
958 | 962 | ||
959 | <informalexample> | 963 | <informalexample> |
@@ -961,7 +965,7 @@ | |||
961 | <![CDATA[ | 965 | <![CDATA[ |
962 | struct snd_card *card; | 966 | struct snd_card *card; |
963 | struct mychip *chip; | 967 | struct mychip *chip; |
964 | card = snd_card_new(index[dev], id[dev], THIS_MODULE, NULL); | 968 | err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card); |
965 | ..... | 969 | ..... |
966 | chip = kzalloc(sizeof(*chip), GFP_KERNEL); | 970 | chip = kzalloc(sizeof(*chip), GFP_KERNEL); |
967 | ]]> | 971 | ]]> |
@@ -1133,8 +1137,8 @@ | |||
1133 | if (err < 0) | 1137 | if (err < 0) |
1134 | return err; | 1138 | return err; |
1135 | /* check PCI availability (28bit DMA) */ | 1139 | /* check PCI availability (28bit DMA) */ |
1136 | if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 || | 1140 | if (pci_set_dma_mask(pci, DMA_BIT_MASK(28)) < 0 || |
1137 | pci_set_consistent_dma_mask(pci, DMA_28BIT_MASK) < 0) { | 1141 | pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(28)) < 0) { |
1138 | printk(KERN_ERR "error to set 28bit mask DMA\n"); | 1142 | printk(KERN_ERR "error to set 28bit mask DMA\n"); |
1139 | pci_disable_device(pci); | 1143 | pci_disable_device(pci); |
1140 | return -ENXIO; | 1144 | return -ENXIO; |
@@ -1248,8 +1252,8 @@ | |||
1248 | err = pci_enable_device(pci); | 1252 | err = pci_enable_device(pci); |
1249 | if (err < 0) | 1253 | if (err < 0) |
1250 | return err; | 1254 | return err; |
1251 | if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 || | 1255 | if (pci_set_dma_mask(pci, DMA_BIT_MASK(28)) < 0 || |
1252 | pci_set_consistent_dma_mask(pci, DMA_28BIT_MASK) < 0) { | 1256 | pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(28)) < 0) { |
1253 | printk(KERN_ERR "error to set 28bit mask DMA\n"); | 1257 | printk(KERN_ERR "error to set 28bit mask DMA\n"); |
1254 | pci_disable_device(pci); | 1258 | pci_disable_device(pci); |
1255 | return -ENXIO; | 1259 | return -ENXIO; |
@@ -5750,8 +5754,9 @@ struct _snd_pcm_runtime { | |||
5750 | .... | 5754 | .... |
5751 | struct snd_card *card; | 5755 | struct snd_card *card; |
5752 | struct mychip *chip; | 5756 | struct mychip *chip; |
5757 | int err; | ||
5753 | .... | 5758 | .... |
5754 | card = snd_card_new(index[dev], id[dev], THIS_MODULE, NULL); | 5759 | err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card); |
5755 | .... | 5760 | .... |
5756 | chip = kzalloc(sizeof(*chip), GFP_KERNEL); | 5761 | chip = kzalloc(sizeof(*chip), GFP_KERNEL); |
5757 | .... | 5762 | .... |
@@ -5763,7 +5768,7 @@ struct _snd_pcm_runtime { | |||
5763 | </informalexample> | 5768 | </informalexample> |
5764 | 5769 | ||
5765 | When you created the chip data with | 5770 | When you created the chip data with |
5766 | <function>snd_card_new()</function>, it's anyway accessible | 5771 | <function>snd_card_create()</function>, it's anyway accessible |
5767 | via <structfield>private_data</structfield> field. | 5772 | via <structfield>private_data</structfield> field. |
5768 | 5773 | ||
5769 | <informalexample> | 5774 | <informalexample> |
@@ -5775,9 +5780,10 @@ struct _snd_pcm_runtime { | |||
5775 | .... | 5780 | .... |
5776 | struct snd_card *card; | 5781 | struct snd_card *card; |
5777 | struct mychip *chip; | 5782 | struct mychip *chip; |
5783 | int err; | ||
5778 | .... | 5784 | .... |
5779 | card = snd_card_new(index[dev], id[dev], THIS_MODULE, | 5785 | err = snd_card_create(index[dev], id[dev], THIS_MODULE, |
5780 | sizeof(struct mychip)); | 5786 | sizeof(struct mychip), &card); |
5781 | .... | 5787 | .... |
5782 | chip = card->private_data; | 5788 | chip = card->private_data; |
5783 | .... | 5789 | .... |
diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt index 256defd7e174..dcf7acc720e1 100644 --- a/Documentation/PCI/MSI-HOWTO.txt +++ b/Documentation/PCI/MSI-HOWTO.txt | |||
@@ -4,506 +4,356 @@ | |||
4 | Revised Feb 12, 2004 by Martine Silbermann | 4 | Revised Feb 12, 2004 by Martine Silbermann |
5 | email: Martine.Silbermann@hp.com | 5 | email: Martine.Silbermann@hp.com |
6 | Revised Jun 25, 2004 by Tom L Nguyen | 6 | Revised Jun 25, 2004 by Tom L Nguyen |
7 | Revised Jul 9, 2008 by Matthew Wilcox <willy@linux.intel.com> | ||
8 | Copyright 2003, 2008 Intel Corporation | ||
7 | 9 | ||
8 | 1. About this guide | 10 | 1. About this guide |
9 | 11 | ||
10 | This guide describes the basics of Message Signaled Interrupts (MSI), | 12 | This guide describes the basics of Message Signaled Interrupts (MSIs), |
11 | the advantages of using MSI over traditional interrupt mechanisms, | 13 | the advantages of using MSI over traditional interrupt mechanisms, how |
12 | and how to enable your driver to use MSI or MSI-X. Also included is | 14 | to change your driver to use MSI or MSI-X and some basic diagnostics to |
13 | a Frequently Asked Questions (FAQ) section. | 15 | try if a device doesn't support MSIs. |
14 | |||
15 | 1.1 Terminology | ||
16 | |||
17 | PCI devices can be single-function or multi-function. In either case, | ||
18 | when this text talks about enabling or disabling MSI on a "device | ||
19 | function," it is referring to one specific PCI device and function and | ||
20 | not to all functions on a PCI device (unless the PCI device has only | ||
21 | one function). | ||
22 | |||
23 | 2. Copyright 2003 Intel Corporation | ||
24 | |||
25 | 3. What is MSI/MSI-X? | ||
26 | |||
27 | Message Signaled Interrupt (MSI), as described in the PCI Local Bus | ||
28 | Specification Revision 2.3 or later, is an optional feature, and a | ||
29 | required feature for PCI Express devices. MSI enables a device function | ||
30 | to request service by sending an Inbound Memory Write on its PCI bus to | ||
31 | the FSB as a Message Signal Interrupt transaction. Because MSI is | ||
32 | generated in the form of a Memory Write, all transaction conditions, | ||
33 | such as a Retry, Master-Abort, Target-Abort or normal completion, are | ||
34 | supported. | ||
35 | |||
36 | A PCI device that supports MSI must also support pin IRQ assertion | ||
37 | interrupt mechanism to provide backward compatibility for systems that | ||
38 | do not support MSI. In systems which support MSI, the bus driver is | ||
39 | responsible for initializing the message address and message data of | ||
40 | the device function's MSI/MSI-X capability structure during device | ||
41 | initial configuration. | ||
42 | |||
43 | An MSI capable device function indicates MSI support by implementing | ||
44 | the MSI/MSI-X capability structure in its PCI capability list. The | ||
45 | device function may implement both the MSI capability structure and | ||
46 | the MSI-X capability structure; however, the bus driver should not | ||
47 | enable both. | ||
48 | |||
49 | The MSI capability structure contains Message Control register, | ||
50 | Message Address register and Message Data register. These registers | ||
51 | provide the bus driver control over MSI. The Message Control register | ||
52 | indicates the MSI capability supported by the device. The Message | ||
53 | Address register specifies the target address and the Message Data | ||
54 | register specifies the characteristics of the message. To request | ||
55 | service, the device function writes the content of the Message Data | ||
56 | register to the target address. The device and its software driver | ||
57 | are prohibited from writing to these registers. | ||
58 | |||
59 | The MSI-X capability structure is an optional extension to MSI. It | ||
60 | uses an independent and separate capability structure. There are | ||
61 | some key advantages to implementing the MSI-X capability structure | ||
62 | over the MSI capability structure as described below. | ||
63 | |||
64 | - Support a larger maximum number of vectors per function. | ||
65 | |||
66 | - Provide the ability for system software to configure | ||
67 | each vector with an independent message address and message | ||
68 | data, specified by a table that resides in Memory Space. | ||
69 | |||
70 | - MSI and MSI-X both support per-vector masking. Per-vector | ||
71 | masking is an optional extension of MSI but a required | ||
72 | feature for MSI-X. Per-vector masking provides the kernel the | ||
73 | ability to mask/unmask a single MSI while running its | ||
74 | interrupt service routine. If per-vector masking is | ||
75 | not supported, then the device driver should provide the | ||
76 | hardware/software synchronization to ensure that the device | ||
77 | generates MSI when the driver wants it to do so. | ||
78 | |||
79 | 4. Why use MSI? | ||
80 | |||
81 | As a benefit to the simplification of board design, MSI allows board | ||
82 | designers to remove out-of-band interrupt routing. MSI is another | ||
83 | step towards a legacy-free environment. | ||
84 | |||
85 | Due to increasing pressure on chipset and processor packages to | ||
86 | reduce pin count, the need for interrupt pins is expected to | ||
87 | diminish over time. Devices, due to pin constraints, may implement | ||
88 | messages to increase performance. | ||
89 | |||
90 | PCI Express endpoints uses INTx emulation (in-band messages) instead | ||
91 | of IRQ pin assertion. Using INTx emulation requires interrupt | ||
92 | sharing among devices connected to the same node (PCI bridge) while | ||
93 | MSI is unique (non-shared) and does not require BIOS configuration | ||
94 | support. As a result, the PCI Express technology requires MSI | ||
95 | support for better interrupt performance. | ||
96 | |||
97 | Using MSI enables the device functions to support two or more | ||
98 | vectors, which can be configured to target different CPUs to | ||
99 | increase scalability. | ||
100 | |||
101 | 5. Configuring a driver to use MSI/MSI-X | ||
102 | |||
103 | By default, the kernel will not enable MSI/MSI-X on all devices that | ||
104 | support this capability. The CONFIG_PCI_MSI kernel option | ||
105 | must be selected to enable MSI/MSI-X support. | ||
106 | |||
107 | 5.1 Including MSI/MSI-X support into the kernel | ||
108 | |||
109 | To allow MSI/MSI-X capable device drivers to selectively enable | ||
110 | MSI/MSI-X (using pci_enable_msi()/pci_enable_msix() as described | ||
111 | below), the VECTOR based scheme needs to be enabled by setting | ||
112 | CONFIG_PCI_MSI during kernel config. | ||
113 | |||
114 | Since the target of the inbound message is the local APIC, providing | ||
115 | CONFIG_X86_LOCAL_APIC must be enabled as well as CONFIG_PCI_MSI. | ||
116 | |||
117 | 5.2 Configuring for MSI support | ||
118 | |||
119 | Due to the non-contiguous fashion in vector assignment of the | ||
120 | existing Linux kernel, this version does not support multiple | ||
121 | messages regardless of a device function is capable of supporting | ||
122 | more than one vector. To enable MSI on a device function's MSI | ||
123 | capability structure requires a device driver to call the function | ||
124 | pci_enable_msi() explicitly. | ||
125 | |||
126 | 5.2.1 API pci_enable_msi | ||
127 | 16 | ||
128 | int pci_enable_msi(struct pci_dev *dev) | ||
129 | 17 | ||
130 | With this new API, a device driver that wants to have MSI | 18 | 2. What are MSIs? |
131 | enabled on its device function must call this API to enable MSI. | ||
132 | A successful call will initialize the MSI capability structure | ||
133 | with ONE vector, regardless of whether a device function is | ||
134 | capable of supporting multiple messages. This vector replaces the | ||
135 | pre-assigned dev->irq with a new MSI vector. To avoid a conflict | ||
136 | of the new assigned vector with existing pre-assigned vector requires | ||
137 | a device driver to call this API before calling request_irq(). | ||
138 | 19 | ||
139 | 5.2.2 API pci_disable_msi | 20 | A Message Signaled Interrupt is a write from the device to a special |
21 | address which causes an interrupt to be received by the CPU. | ||
140 | 22 | ||
141 | void pci_disable_msi(struct pci_dev *dev) | 23 | The MSI capability was first specified in PCI 2.2 and was later enhanced |
24 | in PCI 3.0 to allow each interrupt to be masked individually. The MSI-X | ||
25 | capability was also introduced with PCI 3.0. It supports more interrupts | ||
26 | per device than MSI and allows interrupts to be independently configured. | ||
142 | 27 | ||
143 | This API should always be used to undo the effect of pci_enable_msi() | 28 | Devices may support both MSI and MSI-X, but only one can be enabled at |
144 | when a device driver is unloading. This API restores dev->irq with | 29 | a time. |
145 | the pre-assigned IOAPIC vector and switches a device's interrupt | ||
146 | mode to PCI pin-irq assertion/INTx emulation mode. | ||
147 | |||
148 | Note that a device driver should always call free_irq() on the MSI vector | ||
149 | that it has done request_irq() on before calling this API. Failure to do | ||
150 | so results in a BUG_ON() and a device will be left with MSI enabled and | ||
151 | leaks its vector. | ||
152 | |||
153 | 5.2.3 MSI mode vs. legacy mode diagram | ||
154 | |||
155 | The below diagram shows the events which switch the interrupt | ||
156 | mode on the MSI-capable device function between MSI mode and | ||
157 | PIN-IRQ assertion mode. | ||
158 | |||
159 | ------------ pci_enable_msi ------------------------ | ||
160 | | | <=============== | | | ||
161 | | MSI MODE | | PIN-IRQ ASSERTION MODE | | ||
162 | | | ===============> | | | ||
163 | ------------ pci_disable_msi ------------------------ | ||
164 | |||
165 | |||
166 | Figure 1. MSI Mode vs. Legacy Mode | ||
167 | |||
168 | In Figure 1, a device operates by default in legacy mode. Legacy | ||
169 | in this context means PCI pin-irq assertion or PCI-Express INTx | ||
170 | emulation. A successful MSI request (using pci_enable_msi()) switches | ||
171 | a device's interrupt mode to MSI mode. A pre-assigned IOAPIC vector | ||
172 | stored in dev->irq will be saved by the PCI subsystem and a new | ||
173 | assigned MSI vector will replace dev->irq. | ||
174 | |||
175 | To return back to its default mode, a device driver should always call | ||
176 | pci_disable_msi() to undo the effect of pci_enable_msi(). Note that a | ||
177 | device driver should always call free_irq() on the MSI vector it has | ||
178 | done request_irq() on before calling pci_disable_msi(). Failure to do | ||
179 | so results in a BUG_ON() and a device will be left with MSI enabled and | ||
180 | leaks its vector. Otherwise, the PCI subsystem restores a device's | ||
181 | dev->irq with a pre-assigned IOAPIC vector and marks the released | ||
182 | MSI vector as unused. | ||
183 | |||
184 | Once being marked as unused, there is no guarantee that the PCI | ||
185 | subsystem will reserve this MSI vector for a device. Depending on | ||
186 | the availability of current PCI vector resources and the number of | ||
187 | MSI/MSI-X requests from other drivers, this MSI may be re-assigned. | ||
188 | |||
189 | For the case where the PCI subsystem re-assigns this MSI vector to | ||
190 | another driver, a request to switch back to MSI mode may result | ||
191 | in being assigned a different MSI vector or a failure if no more | ||
192 | vectors are available. | ||
193 | |||
194 | 5.3 Configuring for MSI-X support | ||
195 | |||
196 | Due to the ability of the system software to configure each vector of | ||
197 | the MSI-X capability structure with an independent message address | ||
198 | and message data, the non-contiguous fashion in vector assignment of | ||
199 | the existing Linux kernel has no impact on supporting multiple | ||
200 | messages on an MSI-X capable device functions. To enable MSI-X on | ||
201 | a device function's MSI-X capability structure requires its device | ||
202 | driver to call the function pci_enable_msix() explicitly. | ||
203 | |||
204 | The function pci_enable_msix(), once invoked, enables either | ||
205 | all or nothing, depending on the current availability of PCI vector | ||
206 | resources. If the PCI vector resources are available for the number | ||
207 | of vectors requested by a device driver, this function will configure | ||
208 | the MSI-X table of the MSI-X capability structure of a device with | ||
209 | requested messages. To emphasize this reason, for example, a device | ||
210 | may be capable for supporting the maximum of 32 vectors while its | ||
211 | software driver usually may request 4 vectors. It is recommended | ||
212 | that the device driver should call this function once during the | ||
213 | initialization phase of the device driver. | ||
214 | |||
215 | Unlike the function pci_enable_msi(), the function pci_enable_msix() | ||
216 | does not replace the pre-assigned IOAPIC dev->irq with a new MSI | ||
217 | vector because the PCI subsystem writes the 1:1 vector-to-entry mapping | ||
218 | into the field vector of each element contained in a second argument. | ||
219 | Note that the pre-assigned IOAPIC dev->irq is valid only if the device | ||
220 | operates in PIN-IRQ assertion mode. In MSI-X mode, any attempt at | ||
221 | using dev->irq by the device driver to request for interrupt service | ||
222 | may result in unpredictable behavior. | ||
223 | |||
224 | For each MSI-X vector granted, a device driver is responsible for calling | ||
225 | other functions like request_irq(), enable_irq(), etc. to enable | ||
226 | this vector with its corresponding interrupt service handler. It is | ||
227 | a device driver's choice to assign all vectors with the same | ||
228 | interrupt service handler or each vector with a unique interrupt | ||
229 | service handler. | ||
230 | |||
231 | 5.3.1 Handling MMIO address space of MSI-X Table | ||
232 | |||
233 | The PCI 3.0 specification has implementation notes that MMIO address | ||
234 | space for a device's MSI-X structure should be isolated so that the | ||
235 | software system can set different pages for controlling accesses to the | ||
236 | MSI-X structure. The implementation of MSI support requires the PCI | ||
237 | subsystem, not a device driver, to maintain full control of the MSI-X | ||
238 | table/MSI-X PBA (Pending Bit Array) and MMIO address space of the MSI-X | ||
239 | table/MSI-X PBA. A device driver should not access the MMIO address | ||
240 | space of the MSI-X table/MSI-X PBA. | ||
241 | |||
242 | 5.3.2 API pci_enable_msix | ||
243 | 30 | ||
244 | int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec) | ||
245 | 31 | ||
246 | This API enables a device driver to request the PCI subsystem | 32 | 3. Why use MSIs? |
247 | to enable MSI-X messages on its hardware device. Depending on | 33 | |
248 | the availability of PCI vectors resources, the PCI subsystem enables | 34 | There are three reasons why using MSIs can give an advantage over |
249 | either all or none of the requested vectors. | 35 | traditional pin-based interrupts. |
36 | |||
37 | Pin-based PCI interrupts are often shared amongst several devices. | ||
38 | To support this, the kernel must call each interrupt handler associated | ||
39 | with an interrupt, which leads to reduced performance for the system as | ||
40 | a whole. MSIs are never shared, so this problem cannot arise. | ||
41 | |||
42 | When a device writes data to memory, then raises a pin-based interrupt, | ||
43 | it is possible that the interrupt may arrive before all the data has | ||
44 | arrived in memory (this becomes more likely with devices behind PCI-PCI | ||
45 | bridges). In order to ensure that all the data has arrived in memory, | ||
46 | the interrupt handler must read a register on the device which raised | ||
47 | the interrupt. PCI transaction ordering rules require that all the data | ||
48 | arrives in memory before the value can be returned from the register. | ||
49 | Using MSIs avoids this problem as the interrupt-generating write cannot | ||
50 | pass the data writes, so by the time the interrupt is raised, the driver | ||
51 | knows that all the data has arrived in memory. | ||
52 | |||
53 | PCI devices can only support a single pin-based interrupt per function. | ||
54 | Often drivers have to query the device to find out what event has | ||
55 | occurred, slowing down interrupt handling for the common case. With | ||
56 | MSIs, a device can support more interrupts, allowing each interrupt | ||
57 | to be specialised to a different purpose. One possible design gives | ||
58 | infrequent conditions (such as errors) their own interrupt which allows | ||
59 | the driver to handle the normal interrupt handling path more efficiently. | ||
60 | Other possible designs include giving one interrupt to each packet queue | ||
61 | in a network card or each port in a storage controller. | ||
62 | |||
63 | |||
64 | 4. How to use MSIs | ||
65 | |||
66 | PCI devices are initialised to use pin-based interrupts. The device | ||
67 | driver has to set up the device to use MSI or MSI-X. Not all machines | ||
68 | support MSIs correctly, and for those machines, the APIs described below | ||
69 | will simply fail and the device will continue to use pin-based interrupts. | ||
70 | |||
71 | 4.1 Include kernel support for MSIs | ||
72 | |||
73 | To support MSI or MSI-X, the kernel must be built with the CONFIG_PCI_MSI | ||
74 | option enabled. This option is only available on some architectures, | ||
75 | and it may depend on some other options also being set. For example, | ||
76 | on x86, you must also enable X86_UP_APIC or SMP in order to see the | ||
77 | CONFIG_PCI_MSI option. | ||
78 | |||
79 | 4.2 Using MSI | ||
80 | |||
81 | Most of the hard work is done for the driver in the PCI layer. It simply | ||
82 | has to request that the PCI layer set up the MSI capability for this | ||
83 | device. | ||
84 | |||
85 | 4.2.1 pci_enable_msi | ||
86 | |||
87 | int pci_enable_msi(struct pci_dev *dev) | ||
88 | |||
89 | A successful call will allocate ONE interrupt to the device, regardless | ||
90 | of how many MSIs the device supports. The device will be switched from | ||
91 | pin-based interrupt mode to MSI mode. The dev->irq number is changed | ||
92 | to a new number which represents the message signaled interrupt. | ||
93 | This function should be called before the driver calls request_irq() | ||
94 | since enabling MSIs disables the pin-based IRQ and the driver will not | ||
95 | receive interrupts on the old interrupt. | ||
96 | |||
97 | 4.2.2 pci_enable_msi_block | ||
98 | |||
99 | int pci_enable_msi_block(struct pci_dev *dev, int count) | ||
100 | |||
101 | This variation on the above call allows a device driver to request multiple | ||
102 | MSIs. The MSI specification only allows interrupts to be allocated in | ||
103 | powers of two, up to a maximum of 2^5 (32). | ||
104 | |||
105 | If this function returns 0, it has succeeded in allocating at least as many | ||
106 | interrupts as the driver requested (it may have allocated more in order | ||
107 | to satisfy the power-of-two requirement). In this case, the function | ||
108 | enables MSI on this device and updates dev->irq to be the lowest of | ||
109 | the new interrupts assigned to it. The other interrupts assigned to | ||
110 | the device are in the range dev->irq to dev->irq + count - 1. | ||
111 | |||
112 | If this function returns a negative number, it indicates an error and | ||
113 | the driver should not attempt to request any more MSI interrupts for | ||
114 | this device. If this function returns a positive number, it will be | ||
115 | less than 'count' and indicate the number of interrupts that could have | ||
116 | been allocated. In neither case will the irq value have been | ||
117 | updated, nor will the device have been switched into MSI mode. | ||
118 | |||
119 | The device driver must decide what action to take if | ||
120 | pci_enable_msi_block() returns a value less than the number asked for. | ||
121 | Some devices can make use of fewer interrupts than the maximum they | ||
122 | request; in this case the driver should call pci_enable_msi_block() | ||
123 | again. Note that it is not guaranteed to succeed, even when the | ||
124 | 'count' has been reduced to the value returned from a previous call to | ||
125 | pci_enable_msi_block(). This is because there are multiple constraints | ||
126 | on the number of vectors that can be allocated; pci_enable_msi_block() | ||
127 | will return as soon as it finds any constraint that doesn't allow the | ||
128 | call to succeed. | ||
129 | |||
130 | 4.2.3 pci_disable_msi | ||
131 | |||
132 | void pci_disable_msi(struct pci_dev *dev) | ||
250 | 133 | ||
251 | Argument 'dev' points to the device (pci_dev) structure. | 134 | This function should be used to undo the effect of pci_enable_msi() or |
135 | pci_enable_msi_block(). Calling it restores dev->irq to the pin-based | ||
136 | interrupt number and frees the previously allocated message signaled | ||
137 | interrupt(s). The interrupt may subsequently be assigned to another | ||
138 | device, so drivers should not cache the value of dev->irq. | ||
252 | 139 | ||
253 | Argument 'entries' is a pointer to an array of msix_entry structs. | 140 | A device driver must always call free_irq() on the interrupt(s) |
254 | The number of entries is indicated in argument 'nvec'. | 141 | for which it has called request_irq() before calling this function. |
255 | struct msix_entry is defined in /driver/pci/msi.h: | 142 | Failure to do so will result in a BUG_ON(), the device will be left with |
143 | MSI enabled and will leak its vector. | ||
144 | |||
145 | 4.3 Using MSI-X | ||
146 | |||
147 | The MSI-X capability is much more flexible than the MSI capability. | ||
148 | It supports up to 2048 interrupts, each of which can be controlled | ||
149 | independently. To support this flexibility, drivers must use an array of | ||
150 | `struct msix_entry': | ||
256 | 151 | ||
257 | struct msix_entry { | 152 | struct msix_entry { |
258 | u16 vector; /* kernel uses to write alloc vector */ | 153 | u16 vector; /* kernel uses to write alloc vector */ |
259 | u16 entry; /* driver uses to specify entry */ | 154 | u16 entry; /* driver uses to specify entry */ |
260 | }; | 155 | }; |
261 | 156 | ||
262 | A device driver is responsible for initializing the field 'entry' of | 157 | This allows for the device to use these interrupts in a sparse fashion; |
263 | each element with a unique entry supported by MSI-X table. Otherwise, | 158 | for example it could use interrupts 3 and 1027 and allocate only a |
264 | -EINVAL will be returned as a result. A successful return of zero | 159 | two-element array. The driver is expected to fill in the 'entry' value |
265 | indicates the PCI subsystem completed initializing each of the requested | 160 | in each element of the array to indicate which entries it wants the kernel |
266 | entries of the MSI-X table with message address and message data. | 161 | to assign interrupts for. It is invalid to fill in two entries with the |
267 | Last but not least, the PCI subsystem will write the 1:1 | 162 | same number. |
268 | vector-to-entry mapping into the field 'vector' of each element. A | 163 | |
269 | device driver is responsible for keeping track of allocated MSI-X | 164 | 4.3.1 pci_enable_msix |
270 | vectors in its internal data structure. | 165 | |
271 | 166 | int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec) | |
272 | A return of zero indicates that the number of MSI-X vectors was | 167 | |
273 | successfully allocated. A return of greater than zero indicates | 168 | Calling this function asks the PCI subsystem to allocate 'nvec' MSIs. |
274 | MSI-X vector shortage. Or a return of less than zero indicates | 169 | The 'entries' argument is a pointer to an array of msix_entry structs |
275 | a failure. This failure may be a result of duplicate entries | 170 | which should be at least 'nvec' entries in size. On success, the |
276 | specified in second argument, or a result of no available vector, | 171 | function will return 0 and the device will have been switched into |
277 | or a result of failing to initialize MSI-X table entries. | 172 | MSI-X interrupt mode. The 'vector' elements in each entry will have |
278 | 173 | been filled in with the interrupt number. The driver should then call | |
279 | 5.3.3 API pci_disable_msix | 174 | request_irq() for each 'vector' that it decides to use. |
175 | |||
176 | If this function returns a negative number, it indicates an error and | ||
177 | the driver should not attempt to allocate any more MSI-X interrupts for | ||
178 | this device. If it returns a positive number, it indicates the maximum | ||
179 | number of interrupt vectors that could have been allocated. See example | ||
180 | below. | ||
181 | |||
182 | This function, in contrast with pci_enable_msi(), does not adjust | ||
183 | dev->irq. The device will not generate interrupts for this interrupt | ||
184 | number once MSI-X is enabled. The device driver is responsible for | ||
185 | keeping track of the interrupts assigned to the MSI-X vectors so it can | ||
186 | free them again later. | ||
187 | |||
188 | Device drivers should normally call this function once per device | ||
189 | during the initialization phase. | ||
190 | |||
191 | It is ideal if drivers can cope with a variable number of MSI-X interrupts, | ||
192 | there are many reasons why the platform may not be able to provide the | ||
193 | exact number a driver asks for. | ||
194 | |||
195 | A request loop to achieve that might look like: | ||
196 | |||
197 | static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec) | ||
198 | { | ||
199 | while (nvec >= FOO_DRIVER_MINIMUM_NVEC) { | ||
200 | rc = pci_enable_msix(adapter->pdev, | ||
201 | adapter->msix_entries, nvec); | ||
202 | if (rc > 0) | ||
203 | nvec = rc; | ||
204 | else | ||
205 | return rc; | ||
206 | } | ||
207 | |||
208 | return -ENOSPC; | ||
209 | } | ||
210 | |||
211 | 4.3.2 pci_disable_msix | ||
280 | 212 | ||
281 | void pci_disable_msix(struct pci_dev *dev) | 213 | void pci_disable_msix(struct pci_dev *dev) |
282 | 214 | ||
283 | This API should always be used to undo the effect of pci_enable_msix() | 215 | This API should be used to undo the effect of pci_enable_msix(). It frees |
284 | when a device driver is unloading. Note that a device driver should | 216 | the previously allocated message signaled interrupts. The interrupts may |
285 | always call free_irq() on all MSI-X vectors it has done request_irq() | 217 | subsequently be assigned to another device, so drivers should not cache |
286 | on before calling this API. Failure to do so results in a BUG_ON() and | 218 | the value of the 'vector' elements over a call to pci_disable_msix(). |
287 | a device will be left with MSI-X enabled and leaks its vectors. | 219 | |
288 | 220 | A device driver must always call free_irq() on the interrupt(s) | |
289 | 5.3.4 MSI-X mode vs. legacy mode diagram | 221 | for which it has called request_irq() before calling this function. |
290 | 222 | Failure to do so will result in a BUG_ON(), the device will be left with | |
291 | The below diagram shows the events which switch the interrupt | 223 | MSI enabled and will leak its vector. |
292 | mode on the MSI-X capable device function between MSI-X mode and | 224 | |
293 | PIN-IRQ assertion mode (legacy). | 225 | 4.3.3 The MSI-X Table |
294 | 226 | ||
295 | ------------ pci_enable_msix(,,n) ------------------------ | 227 | The MSI-X capability specifies a BAR and offset within that BAR for the |
296 | | | <=============== | | | 228 | MSI-X Table. This address is mapped by the PCI subsystem, and should not |
297 | | MSI-X MODE | | PIN-IRQ ASSERTION MODE | | 229 | be accessed directly by the device driver. If the driver wishes to |
298 | | | ===============> | | | 230 | mask or unmask an interrupt, it should call disable_irq() / enable_irq(). |
299 | ------------ pci_disable_msix ------------------------ | 231 | |
300 | 232 | 4.4 Handling devices implementing both MSI and MSI-X capabilities | |
301 | Figure 2. MSI-X Mode vs. Legacy Mode | 233 | |
302 | 234 | If a device implements both MSI and MSI-X capabilities, it can | |
303 | In Figure 2, a device operates by default in legacy mode. A | 235 | run in either MSI mode or MSI-X mode but not both simultaneously. |
304 | successful MSI-X request (using pci_enable_msix()) switches a | 236 | This is a requirement of the PCI spec, and it is enforced by the |
305 | device's interrupt mode to MSI-X mode. A pre-assigned IOAPIC vector | 237 | PCI layer. Calling pci_enable_msi() when MSI-X is already enabled or |
306 | stored in dev->irq will be saved by the PCI subsystem; however, | 238 | pci_enable_msix() when MSI is already enabled will result in an error. |
307 | unlike MSI mode, the PCI subsystem will not replace dev->irq with | 239 | If a device driver wishes to switch between MSI and MSI-X at runtime, |
308 | assigned MSI-X vector because the PCI subsystem already writes the 1:1 | 240 | it must first quiesce the device, then switch it back to pin-interrupt |
309 | vector-to-entry mapping into the field 'vector' of each element | 241 | mode, before calling pci_enable_msi() or pci_enable_msix() and resuming |
310 | specified in second argument. | 242 | operation. This is not expected to be a common operation but may be |
311 | 243 | useful for debugging or testing during development. | |
312 | To return back to its default mode, a device driver should always call | 244 | |
313 | pci_disable_msix() to undo the effect of pci_enable_msix(). Note that | 245 | 4.5 Considerations when using MSIs |
314 | a device driver should always call free_irq() on all MSI-X vectors it | 246 | |
315 | has done request_irq() on before calling pci_disable_msix(). Failure | 247 | 4.5.1 Choosing between MSI-X and MSI |
316 | to do so results in a BUG_ON() and a device will be left with MSI-X | 248 | |
317 | enabled and leaks its vectors. Otherwise, the PCI subsystem switches a | 249 | If your device supports both MSI-X and MSI capabilities, you should use |
318 | device function's interrupt mode from MSI-X mode to legacy mode and | 250 | the MSI-X facilities in preference to the MSI facilities. As mentioned |
319 | marks all allocated MSI-X vectors as unused. | 251 | above, MSI-X supports any number of interrupts between 1 and 2048. |
320 | 252 | In constrast, MSI is restricted to a maximum of 32 interrupts (and | |
321 | Once being marked as unused, there is no guarantee that the PCI | 253 | must be a power of two). In addition, the MSI interrupt vectors must |
322 | subsystem will reserve these MSI-X vectors for a device. Depending on | 254 | be allocated consecutively, so the system may not be able to allocate |
323 | the availability of current PCI vector resources and the number of | 255 | as many vectors for MSI as it could for MSI-X. On some platforms, MSI |
324 | MSI/MSI-X requests from other drivers, these MSI-X vectors may be | 256 | interrupts must all be targetted at the same set of CPUs whereas MSI-X |
325 | re-assigned. | 257 | interrupts can all be targetted at different CPUs. |
326 | 258 | ||
327 | For the case where the PCI subsystem re-assigned these MSI-X vectors | 259 | 4.5.2 Spinlocks |
328 | to other drivers, a request to switch back to MSI-X mode may result | 260 | |
329 | being assigned with another set of MSI-X vectors or a failure if no | 261 | Most device drivers have a per-device spinlock which is taken in the |
330 | more vectors are available. | 262 | interrupt handler. With pin-based interrupts or a single MSI, it is not |
331 | 263 | necessary to disable interrupts (Linux guarantees the same interrupt will | |
332 | 5.4 Handling function implementing both MSI and MSI-X capabilities | 264 | not be re-entered). If a device uses multiple interrupts, the driver |
333 | 265 | must disable interrupts while the lock is held. If the device sends | |
334 | For the case where a function implements both MSI and MSI-X | 266 | a different interrupt, the driver will deadlock trying to recursively |
335 | capabilities, the PCI subsystem enables a device to run either in MSI | 267 | acquire the spinlock. |
336 | mode or MSI-X mode but not both. A device driver determines whether it | 268 | |
337 | wants MSI or MSI-X enabled on its hardware device. Once a device | 269 | There are two solutions. The first is to take the lock with |
338 | driver requests for MSI, for example, it is prohibited from requesting | 270 | spin_lock_irqsave() or spin_lock_irq() (see |
339 | MSI-X; in other words, a device driver is not permitted to ping-pong | 271 | Documentation/DocBook/kernel-locking). The second is to specify |
340 | between MSI mod MSI-X mode during a run-time. | 272 | IRQF_DISABLED to request_irq() so that the kernel runs the entire |
341 | 273 | interrupt routine with interrupts disabled. | |
342 | 5.5 Hardware requirements for MSI/MSI-X support | 274 | |
343 | 275 | If your MSI interrupt routine does not hold the lock for the whole time | |
344 | MSI/MSI-X support requires support from both system hardware and | 276 | it is running, the first solution may be best. The second solution is |
345 | individual hardware device functions. | 277 | normally preferred as it avoids making two transitions from interrupt |
346 | 278 | disabled to enabled and back again. | |
347 | 5.5.1 Required x86 hardware support | 279 | |
348 | 280 | 4.6 How to tell whether MSI/MSI-X is enabled on a device | |
349 | Since the target of MSI address is the local APIC CPU, enabling | 281 | |
350 | MSI/MSI-X support in the Linux kernel is dependent on whether existing | 282 | Using 'lspci -v' (as root) may show some devices with "MSI", "Message |
351 | system hardware supports local APIC. Users should verify that their | 283 | Signalled Interrupts" or "MSI-X" capabilities. Each of these capabilities |
352 | system supports local APIC operation by testing that it runs when | 284 | has an 'Enable' flag which will be followed with either "+" (enabled) |
353 | CONFIG_X86_LOCAL_APIC=y. | 285 | or "-" (disabled). |
354 | 286 | ||
355 | In SMP environment, CONFIG_X86_LOCAL_APIC is automatically set; | 287 | |
356 | however, in UP environment, users must manually set | 288 | 5. MSI quirks |
357 | CONFIG_X86_LOCAL_APIC. Once CONFIG_X86_LOCAL_APIC=y, setting | 289 | |
358 | CONFIG_PCI_MSI enables the VECTOR based scheme and the option for | 290 | Several PCI chipsets or devices are known not to support MSIs. |
359 | MSI-capable device drivers to selectively enable MSI/MSI-X. | 291 | The PCI stack provides three ways to disable MSIs: |
360 | 292 | ||
361 | Note that CONFIG_X86_IO_APIC setting is irrelevant because MSI/MSI-X | 293 | 1. globally |
362 | vector is allocated new during runtime and MSI/MSI-X support does not | 294 | 2. on all devices behind a specific bridge |
363 | depend on BIOS support. This key independency enables MSI/MSI-X | 295 | 3. on a single device |
364 | support on future IOxAPIC free platforms. | 296 | |
365 | 297 | 5.1. Disabling MSIs globally | |
366 | 5.5.2 Device hardware support | 298 | |
367 | 299 | Some host chipsets simply don't support MSIs properly. If we're | |
368 | The hardware device function supports MSI by indicating the | 300 | lucky, the manufacturer knows this and has indicated it in the ACPI |
369 | MSI/MSI-X capability structure on its PCI capability list. By | 301 | FADT table. In this case, Linux will automatically disable MSIs. |
370 | default, this capability structure will not be initialized by | 302 | Some boards don't include this information in the table and so we have |
371 | the kernel to enable MSI during the system boot. In other words, | 303 | to detect them ourselves. The complete list of these is found near the |
372 | the device function is running on its default pin assertion mode. | 304 | quirk_disable_all_msi() function in drivers/pci/quirks.c. |
373 | Note that in many cases the hardware supporting MSI have bugs, | 305 | |
374 | which may result in system hangs. The software driver of specific | 306 | If you have a board which has problems with MSIs, you can pass pci=nomsi |
375 | MSI-capable hardware is responsible for deciding whether to call | 307 | on the kernel command line to disable MSIs on all devices. It would be |
376 | pci_enable_msi or not. A return of zero indicates the kernel | 308 | in your best interests to report the problem to linux-pci@vger.kernel.org |
377 | successfully initialized the MSI/MSI-X capability structure of the | 309 | including a full 'lspci -v' so we can add the quirks to the kernel. |
378 | device function. The device function is now running on MSI/MSI-X mode. | 310 | |
379 | 311 | 5.2. Disabling MSIs below a bridge | |
380 | 5.6 How to tell whether MSI/MSI-X is enabled on device function | 312 | |
381 | 313 | Some PCI bridges are not able to route MSIs between busses properly. | |
382 | At the driver level, a return of zero from the function call of | 314 | In this case, MSIs must be disabled on all devices behind the bridge. |
383 | pci_enable_msi()/pci_enable_msix() indicates to a device driver that | 315 | |
384 | its device function is initialized successfully and ready to run in | 316 | Some bridges allow you to enable MSIs by changing some bits in their |
385 | MSI/MSI-X mode. | 317 | PCI configuration space (especially the Hypertransport chipsets such |
386 | 318 | as the nVidia nForce and Serverworks HT2000). As with host chipsets, | |
387 | At the user level, users can use the command 'cat /proc/interrupts' | 319 | Linux mostly knows about them and automatically enables MSIs if it can. |
388 | to display the vectors allocated for devices and their interrupt | 320 | If you have a bridge which Linux doesn't yet know about, you can enable |
389 | MSI/MSI-X modes ("PCI-MSI"/"PCI-MSI-X"). Below shows MSI mode is | 321 | MSIs in configuration space using whatever method you know works, then |
390 | enabled on a SCSI Adaptec 39320D Ultra320 controller. | 322 | enable MSIs on that bridge by doing: |
391 | 323 | ||
392 | CPU0 CPU1 | 324 | echo 1 > /sys/bus/pci/devices/$bridge/msi_bus |
393 | 0: 324639 0 IO-APIC-edge timer | 325 | |
394 | 1: 1186 0 IO-APIC-edge i8042 | 326 | where $bridge is the PCI address of the bridge you've enabled (eg |
395 | 2: 0 0 XT-PIC cascade | 327 | 0000:00:0e.0). |
396 | 12: 2797 0 IO-APIC-edge i8042 | 328 | |
397 | 14: 6543 0 IO-APIC-edge ide0 | 329 | To disable MSIs, echo 0 instead of 1. Changing this value should be |
398 | 15: 1 0 IO-APIC-edge ide1 | 330 | done with caution as it can break interrupt handling for all devices |
399 | 169: 0 0 IO-APIC-level uhci-hcd | 331 | below this bridge. |
400 | 185: 0 0 IO-APIC-level uhci-hcd | 332 | |
401 | 193: 138 10 PCI-MSI aic79xx | 333 | Again, please notify linux-pci@vger.kernel.org of any bridges that need |
402 | 201: 30 0 PCI-MSI aic79xx | 334 | special handling. |
403 | 225: 30 0 IO-APIC-level aic7xxx | 335 | |
404 | 233: 30 0 IO-APIC-level aic7xxx | 336 | 5.3. Disabling MSIs on a single device |
405 | NMI: 0 0 | 337 | |
406 | LOC: 324553 325068 | 338 | Some devices are known to have faulty MSI implementations. Usually this |
407 | ERR: 0 | 339 | is handled in the individual device driver but occasionally it's necessary |
408 | MIS: 0 | 340 | to handle this with a quirk. Some drivers have an option to disable use |
409 | 341 | of MSI. While this is a convenient workaround for the driver author, | |
410 | 6. MSI quirks | 342 | it is not good practise, and should not be emulated. |
411 | 343 | ||
412 | Several PCI chipsets or devices are known to not support MSI. | 344 | 5.4. Finding why MSIs are disabled on a device |
413 | The PCI stack provides 3 possible levels of MSI disabling: | 345 | |
414 | * on a single device | 346 | From the above three sections, you can see that there are many reasons |
415 | * on all devices behind a specific bridge | 347 | why MSIs may not be enabled for a given device. Your first step should |
416 | * globally | 348 | be to examine your dmesg carefully to determine whether MSIs are enabled |
417 | 349 | for your machine. You should also check your .config to be sure you | |
418 | 6.1. Disabling MSI on a single device | 350 | have enabled CONFIG_PCI_MSI. |
419 | 351 | ||
420 | Under some circumstances it might be required to disable MSI on a | 352 | Then, 'lspci -t' gives the list of bridges above a device. Reading |
421 | single device. This may be achieved by either not calling pci_enable_msi() | 353 | /sys/bus/pci/devices/*/msi_bus will tell you whether MSI are enabled (1) |
422 | or all, or setting the pci_dev->no_msi flag before (most of the time | 354 | or disabled (0). If 0 is found in any of the msi_bus files belonging |
423 | in a quirk). | 355 | to bridges between the PCI root and the device, MSIs are disabled. |
424 | 356 | ||
425 | 6.2. Disabling MSI below a bridge | 357 | It is also worth checking the device driver to see whether it supports MSIs. |
426 | 358 | For example, it may contain calls to pci_enable_msi(), pci_enable_msix() or | |
427 | The vast majority of MSI quirks are required by PCI bridges not | 359 | pci_enable_msi_block(). |
428 | being able to route MSI between busses. In this case, MSI have to be | ||
429 | disabled on all devices behind this bridge. It is achieves by setting | ||
430 | the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge | ||
431 | subordinate bus. There is no need to set the same flag on bridges that | ||
432 | are below the broken bridge. When pci_enable_msi() is called to enable | ||
433 | MSI on a device, pci_msi_supported() takes care of checking the NO_MSI | ||
434 | flag in all parent busses of the device. | ||
435 | |||
436 | Some bridges actually support dynamic MSI support enabling/disabling | ||
437 | by changing some bits in their PCI configuration space (especially | ||
438 | the Hypertransport chipsets such as the nVidia nForce and Serverworks | ||
439 | HT2000). It may then be required to update the NO_MSI flag on the | ||
440 | corresponding devices in the sysfs hierarchy. To enable MSI support | ||
441 | on device "0000:00:0e", do: | ||
442 | |||
443 | echo 1 > /sys/bus/pci/devices/0000:00:0e/msi_bus | ||
444 | |||
445 | To disable MSI support, echo 0 instead of 1. Note that it should be | ||
446 | used with caution since changing this value might break interrupts. | ||
447 | |||
448 | 6.3. Disabling MSI globally | ||
449 | |||
450 | Some extreme cases may require to disable MSI globally on the system. | ||
451 | For now, the only known case is a Serverworks PCI-X chipsets (MSI are | ||
452 | not supported on several busses that are not all connected to the | ||
453 | chipset in the Linux PCI hierarchy). In the vast majority of other | ||
454 | cases, disabling only behind a specific bridge is enough. | ||
455 | |||
456 | For debugging purpose, the user may also pass pci=nomsi on the kernel | ||
457 | command-line to explicitly disable MSI globally. But, once the appro- | ||
458 | priate quirks are added to the kernel, this option should not be | ||
459 | required anymore. | ||
460 | |||
461 | 6.4. Finding why MSI cannot be enabled on a device | ||
462 | |||
463 | Assuming that MSI are not enabled on a device, you should look at | ||
464 | dmesg to find messages that quirks may output when disabling MSI | ||
465 | on some devices, some bridges or even globally. | ||
466 | Then, lspci -t gives the list of bridges above a device. Reading | ||
467 | /sys/bus/pci/devices/0000:00:0e/msi_bus will tell you whether MSI | ||
468 | are enabled (1) or disabled (0). In 0 is found in a single bridge | ||
469 | msi_bus file above the device, MSI cannot be enabled. | ||
470 | |||
471 | 7. FAQ | ||
472 | |||
473 | Q1. Are there any limitations on using the MSI? | ||
474 | |||
475 | A1. If the PCI device supports MSI and conforms to the | ||
476 | specification and the platform supports the APIC local bus, | ||
477 | then using MSI should work. | ||
478 | |||
479 | Q2. Will it work on all the Pentium processors (P3, P4, Xeon, | ||
480 | AMD processors)? In P3 IPI's are transmitted on the APIC local | ||
481 | bus and in P4 and Xeon they are transmitted on the system | ||
482 | bus. Are there any implications with this? | ||
483 | |||
484 | A2. MSI support enables a PCI device sending an inbound | ||
485 | memory write (0xfeexxxxx as target address) on its PCI bus | ||
486 | directly to the FSB. Since the message address has a | ||
487 | redirection hint bit cleared, it should work. | ||
488 | |||
489 | Q3. The target address 0xfeexxxxx will be translated by the | ||
490 | Host Bridge into an interrupt message. Are there any | ||
491 | limitations on the chipsets such as Intel 8xx, Intel e7xxx, | ||
492 | or VIA? | ||
493 | |||
494 | A3. If these chipsets support an inbound memory write with | ||
495 | target address set as 0xfeexxxxx, as conformed to PCI | ||
496 | specification 2.3 or latest, then it should work. | ||
497 | |||
498 | Q4. From the driver point of view, if the MSI is lost because | ||
499 | of errors occurring during inbound memory write, then it may | ||
500 | wait forever. Is there a mechanism for it to recover? | ||
501 | |||
502 | A4. Since the target of the transaction is an inbound memory | ||
503 | write, all transaction termination conditions (Retry, | ||
504 | Master-Abort, Target-Abort, or normal completion) are | ||
505 | supported. A device sending an MSI must abide by all the PCI | ||
506 | rules and conditions regarding that inbound memory write. So, | ||
507 | if a retry is signaled it must retry, etc... We believe that | ||
508 | the recommendation for Abort is also a retry (refer to PCI | ||
509 | specification 2.3 or latest). | ||
diff --git a/Documentation/PCI/PCIEBUS-HOWTO.txt b/Documentation/PCI/PCIEBUS-HOWTO.txt index 9a07e38631b0..6bd5f372adec 100644 --- a/Documentation/PCI/PCIEBUS-HOWTO.txt +++ b/Documentation/PCI/PCIEBUS-HOWTO.txt | |||
@@ -93,7 +93,7 @@ the PCI Express Port Bus driver from loading a service driver. | |||
93 | 93 | ||
94 | int pcie_port_service_register(struct pcie_port_service_driver *new) | 94 | int pcie_port_service_register(struct pcie_port_service_driver *new) |
95 | 95 | ||
96 | This API replaces the Linux Driver Model's pci_module_init API. A | 96 | This API replaces the Linux Driver Model's pci_register_driver API. A |
97 | service driver should always calls pcie_port_service_register at | 97 | service driver should always calls pcie_port_service_register at |
98 | module init. Note that after service driver being loaded, calls | 98 | module init. Note that after service driver being loaded, calls |
99 | such as pci_enable_device(dev) and pci_set_master(dev) are no longer | 99 | such as pci_enable_device(dev) and pci_set_master(dev) are no longer |
diff --git a/Documentation/PCI/pci-iov-howto.txt b/Documentation/PCI/pci-iov-howto.txt new file mode 100644 index 000000000000..fc73ef5d65b8 --- /dev/null +++ b/Documentation/PCI/pci-iov-howto.txt | |||
@@ -0,0 +1,99 @@ | |||
1 | PCI Express I/O Virtualization Howto | ||
2 | Copyright (C) 2009 Intel Corporation | ||
3 | Yu Zhao <yu.zhao@intel.com> | ||
4 | |||
5 | |||
6 | 1. Overview | ||
7 | |||
8 | 1.1 What is SR-IOV | ||
9 | |||
10 | Single Root I/O Virtualization (SR-IOV) is a PCI Express Extended | ||
11 | capability which makes one physical device appear as multiple virtual | ||
12 | devices. The physical device is referred to as Physical Function (PF) | ||
13 | while the virtual devices are referred to as Virtual Functions (VF). | ||
14 | Allocation of the VF can be dynamically controlled by the PF via | ||
15 | registers encapsulated in the capability. By default, this feature is | ||
16 | not enabled and the PF behaves as traditional PCIe device. Once it's | ||
17 | turned on, each VF's PCI configuration space can be accessed by its own | ||
18 | Bus, Device and Function Number (Routing ID). And each VF also has PCI | ||
19 | Memory Space, which is used to map its register set. VF device driver | ||
20 | operates on the register set so it can be functional and appear as a | ||
21 | real existing PCI device. | ||
22 | |||
23 | 2. User Guide | ||
24 | |||
25 | 2.1 How can I enable SR-IOV capability | ||
26 | |||
27 | The device driver (PF driver) will control the enabling and disabling | ||
28 | of the capability via API provided by SR-IOV core. If the hardware | ||
29 | has SR-IOV capability, loading its PF driver would enable it and all | ||
30 | VFs associated with the PF. | ||
31 | |||
32 | 2.2 How can I use the Virtual Functions | ||
33 | |||
34 | The VF is treated as hot-plugged PCI devices in the kernel, so they | ||
35 | should be able to work in the same way as real PCI devices. The VF | ||
36 | requires device driver that is same as a normal PCI device's. | ||
37 | |||
38 | 3. Developer Guide | ||
39 | |||
40 | 3.1 SR-IOV API | ||
41 | |||
42 | To enable SR-IOV capability: | ||
43 | int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn); | ||
44 | 'nr_virtfn' is number of VFs to be enabled. | ||
45 | |||
46 | To disable SR-IOV capability: | ||
47 | void pci_disable_sriov(struct pci_dev *dev); | ||
48 | |||
49 | To notify SR-IOV core of Virtual Function Migration: | ||
50 | irqreturn_t pci_sriov_migration(struct pci_dev *dev); | ||
51 | |||
52 | 3.2 Usage example | ||
53 | |||
54 | Following piece of code illustrates the usage of the SR-IOV API. | ||
55 | |||
56 | static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id) | ||
57 | { | ||
58 | pci_enable_sriov(dev, NR_VIRTFN); | ||
59 | |||
60 | ... | ||
61 | |||
62 | return 0; | ||
63 | } | ||
64 | |||
65 | static void __devexit dev_remove(struct pci_dev *dev) | ||
66 | { | ||
67 | pci_disable_sriov(dev); | ||
68 | |||
69 | ... | ||
70 | } | ||
71 | |||
72 | static int dev_suspend(struct pci_dev *dev, pm_message_t state) | ||
73 | { | ||
74 | ... | ||
75 | |||
76 | return 0; | ||
77 | } | ||
78 | |||
79 | static int dev_resume(struct pci_dev *dev) | ||
80 | { | ||
81 | ... | ||
82 | |||
83 | return 0; | ||
84 | } | ||
85 | |||
86 | static void dev_shutdown(struct pci_dev *dev) | ||
87 | { | ||
88 | ... | ||
89 | } | ||
90 | |||
91 | static struct pci_driver dev_driver = { | ||
92 | .name = "SR-IOV Physical Function driver", | ||
93 | .id_table = dev_id_table, | ||
94 | .probe = dev_probe, | ||
95 | .remove = __devexit_p(dev_remove), | ||
96 | .suspend = dev_suspend, | ||
97 | .resume = dev_resume, | ||
98 | .shutdown = dev_shutdown, | ||
99 | }; | ||
diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 6e253407b3dc..accfe2f5247d 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt | |||
@@ -298,3 +298,15 @@ over a rather long period of time, but improvements are always welcome! | |||
298 | 298 | ||
299 | Note that, rcu_assign_pointer() and rcu_dereference() relate to | 299 | Note that, rcu_assign_pointer() and rcu_dereference() relate to |
300 | SRCU just as they do to other forms of RCU. | 300 | SRCU just as they do to other forms of RCU. |
301 | |||
302 | 15. The whole point of call_rcu(), synchronize_rcu(), and friends | ||
303 | is to wait until all pre-existing readers have finished before | ||
304 | carrying out some otherwise-destructive operation. It is | ||
305 | therefore critically important to -first- remove any path | ||
306 | that readers can follow that could be affected by the | ||
307 | destructive operation, and -only- -then- invoke call_rcu(), | ||
308 | synchronize_rcu(), or friends. | ||
309 | |||
310 | Because these primitives only wait for pre-existing readers, | ||
311 | it is the caller's responsibility to guarantee safety to | ||
312 | any subsequent readers. | ||
diff --git a/Documentation/RCU/listRCU.txt b/Documentation/RCU/listRCU.txt index 1fd175368a87..4349c1487e91 100644 --- a/Documentation/RCU/listRCU.txt +++ b/Documentation/RCU/listRCU.txt | |||
@@ -118,7 +118,7 @@ Following are the RCU equivalents for these two functions: | |||
118 | list_for_each_entry(e, list, list) { | 118 | list_for_each_entry(e, list, list) { |
119 | if (!audit_compare_rule(rule, &e->rule)) { | 119 | if (!audit_compare_rule(rule, &e->rule)) { |
120 | list_del_rcu(&e->list); | 120 | list_del_rcu(&e->list); |
121 | call_rcu(&e->rcu, audit_free_rule, e); | 121 | call_rcu(&e->rcu, audit_free_rule); |
122 | return 0; | 122 | return 0; |
123 | } | 123 | } |
124 | } | 124 | } |
@@ -206,7 +206,7 @@ RCU ("read-copy update") its name. The RCU code is as follows: | |||
206 | ne->rule.action = newaction; | 206 | ne->rule.action = newaction; |
207 | ne->rule.file_count = newfield_count; | 207 | ne->rule.file_count = newfield_count; |
208 | list_replace_rcu(e, ne); | 208 | list_replace_rcu(e, ne); |
209 | call_rcu(&e->rcu, audit_free_rule, e); | 209 | call_rcu(&e->rcu, audit_free_rule); |
210 | return 0; | 210 | return 0; |
211 | } | 211 | } |
212 | } | 212 | } |
@@ -283,7 +283,7 @@ flag under the spinlock as follows: | |||
283 | list_del_rcu(&e->list); | 283 | list_del_rcu(&e->list); |
284 | e->deleted = 1; | 284 | e->deleted = 1; |
285 | spin_unlock(&e->lock); | 285 | spin_unlock(&e->lock); |
286 | call_rcu(&e->rcu, audit_free_rule, e); | 286 | call_rcu(&e->rcu, audit_free_rule); |
287 | return 0; | 287 | return 0; |
288 | } | 288 | } |
289 | } | 289 | } |
diff --git a/Documentation/RCU/rcu.txt b/Documentation/RCU/rcu.txt index 95821a29ae41..7aa2002ade77 100644 --- a/Documentation/RCU/rcu.txt +++ b/Documentation/RCU/rcu.txt | |||
@@ -81,7 +81,7 @@ o I hear that RCU needs work in order to support realtime kernels? | |||
81 | This work is largely completed. Realtime-friendly RCU can be | 81 | This work is largely completed. Realtime-friendly RCU can be |
82 | enabled via the CONFIG_PREEMPT_RCU kernel configuration parameter. | 82 | enabled via the CONFIG_PREEMPT_RCU kernel configuration parameter. |
83 | However, work is in progress for enabling priority boosting of | 83 | However, work is in progress for enabling priority boosting of |
84 | preempted RCU read-side critical sections.This is needed if you | 84 | preempted RCU read-side critical sections. This is needed if you |
85 | have CPU-bound realtime threads. | 85 | have CPU-bound realtime threads. |
86 | 86 | ||
87 | o Where can I find more information on RCU? | 87 | o Where can I find more information on RCU? |
diff --git a/Documentation/RCU/rculist_nulls.txt b/Documentation/RCU/rculist_nulls.txt index 239f542d48ba..6389dec33459 100644 --- a/Documentation/RCU/rculist_nulls.txt +++ b/Documentation/RCU/rculist_nulls.txt | |||
@@ -21,7 +21,7 @@ if (obj) { | |||
21 | /* | 21 | /* |
22 | * Because a writer could delete object, and a writer could | 22 | * Because a writer could delete object, and a writer could |
23 | * reuse these object before the RCU grace period, we | 23 | * reuse these object before the RCU grace period, we |
24 | * must check key after geting the reference on object | 24 | * must check key after getting the reference on object |
25 | */ | 25 | */ |
26 | if (obj->key != key) { // not the object we expected | 26 | if (obj->key != key) { // not the object we expected |
27 | put_ref(obj); | 27 | put_ref(obj); |
@@ -117,7 +117,7 @@ a race (some writer did a delete and/or a move of an object | |||
117 | to another chain) checking the final 'nulls' value if | 117 | to another chain) checking the final 'nulls' value if |
118 | the lookup met the end of chain. If final 'nulls' value | 118 | the lookup met the end of chain. If final 'nulls' value |
119 | is not the slot number, then we must restart the lookup at | 119 | is not the slot number, then we must restart the lookup at |
120 | the begining. If the object was moved to same chain, | 120 | the beginning. If the object was moved to the same chain, |
121 | then the reader doesnt care : It might eventually | 121 | then the reader doesnt care : It might eventually |
122 | scan the list again without harm. | 122 | scan the list again without harm. |
123 | 123 | ||
diff --git a/Documentation/Smack.txt b/Documentation/Smack.txt index 989c2fcd8111..629c92e99783 100644 --- a/Documentation/Smack.txt +++ b/Documentation/Smack.txt | |||
@@ -184,14 +184,16 @@ length. Single character labels using special characters, that being anything | |||
184 | other than a letter or digit, are reserved for use by the Smack development | 184 | other than a letter or digit, are reserved for use by the Smack development |
185 | team. Smack labels are unstructured, case sensitive, and the only operation | 185 | team. Smack labels are unstructured, case sensitive, and the only operation |
186 | ever performed on them is comparison for equality. Smack labels cannot | 186 | ever performed on them is comparison for equality. Smack labels cannot |
187 | contain unprintable characters or the "/" (slash) character. | 187 | contain unprintable characters or the "/" (slash) character. Smack labels |
188 | cannot begin with a '-', which is reserved for special options. | ||
188 | 189 | ||
189 | There are some predefined labels: | 190 | There are some predefined labels: |
190 | 191 | ||
191 | _ Pronounced "floor", a single underscore character. | 192 | _ Pronounced "floor", a single underscore character. |
192 | ^ Pronounced "hat", a single circumflex character. | 193 | ^ Pronounced "hat", a single circumflex character. |
193 | * Pronounced "star", a single asterisk character. | 194 | * Pronounced "star", a single asterisk character. |
194 | ? Pronounced "huh", a single question mark character. | 195 | ? Pronounced "huh", a single question mark character. |
196 | @ Pronounced "Internet", a single at sign character. | ||
195 | 197 | ||
196 | Every task on a Smack system is assigned a label. System tasks, such as | 198 | Every task on a Smack system is assigned a label. System tasks, such as |
197 | init(8) and systems daemons, are run with the floor ("_") label. User tasks | 199 | init(8) and systems daemons, are run with the floor ("_") label. User tasks |
@@ -412,6 +414,36 @@ sockets. | |||
412 | A privileged program may set this to match the label of another | 414 | A privileged program may set this to match the label of another |
413 | task with which it hopes to communicate. | 415 | task with which it hopes to communicate. |
414 | 416 | ||
417 | Smack Netlabel Exceptions | ||
418 | |||
419 | You will often find that your labeled application has to talk to the outside, | ||
420 | unlabeled world. To do this there's a special file /smack/netlabel where you can | ||
421 | add some exceptions in the form of : | ||
422 | @IP1 LABEL1 or | ||
423 | @IP2/MASK LABEL2 | ||
424 | |||
425 | It means that your application will have unlabeled access to @IP1 if it has | ||
426 | write access on LABEL1, and access to the subnet @IP2/MASK if it has write | ||
427 | access on LABEL2. | ||
428 | |||
429 | Entries in the /smack/netlabel file are matched by longest mask first, like in | ||
430 | classless IPv4 routing. | ||
431 | |||
432 | A special label '@' and an option '-CIPSO' can be used there : | ||
433 | @ means Internet, any application with any label has access to it | ||
434 | -CIPSO means standard CIPSO networking | ||
435 | |||
436 | If you don't know what CIPSO is and don't plan to use it, you can just do : | ||
437 | echo 127.0.0.1 -CIPSO > /smack/netlabel | ||
438 | echo 0.0.0.0/0 @ > /smack/netlabel | ||
439 | |||
440 | If you use CIPSO on your 192.168.0.0/16 local network and need also unlabeled | ||
441 | Internet access, you can have : | ||
442 | echo 127.0.0.1 -CIPSO > /smack/netlabel | ||
443 | echo 192.168.0.0/16 -CIPSO > /smack/netlabel | ||
444 | echo 0.0.0.0/0 @ > /smack/netlabel | ||
445 | |||
446 | |||
415 | Writing Applications for Smack | 447 | Writing Applications for Smack |
416 | 448 | ||
417 | There are three sorts of applications that will run on a Smack system. How an | 449 | There are three sorts of applications that will run on a Smack system. How an |
diff --git a/Documentation/arm/Samsung-S3C24XX/Suspend.txt b/Documentation/arm/Samsung-S3C24XX/Suspend.txt index 0dab6e32c130..a30fe510572b 100644 --- a/Documentation/arm/Samsung-S3C24XX/Suspend.txt +++ b/Documentation/arm/Samsung-S3C24XX/Suspend.txt | |||
@@ -40,13 +40,13 @@ Resuming | |||
40 | Machine Support | 40 | Machine Support |
41 | --------------- | 41 | --------------- |
42 | 42 | ||
43 | The machine specific functions must call the s3c2410_pm_init() function | 43 | The machine specific functions must call the s3c_pm_init() function |
44 | to say that its bootloader is capable of resuming. This can be as | 44 | to say that its bootloader is capable of resuming. This can be as |
45 | simple as adding the following to the machine's definition: | 45 | simple as adding the following to the machine's definition: |
46 | 46 | ||
47 | INITMACHINE(s3c2410_pm_init) | 47 | INITMACHINE(s3c_pm_init) |
48 | 48 | ||
49 | A board can do its own setup before calling s3c2410_pm_init, if it | 49 | A board can do its own setup before calling s3c_pm_init, if it |
50 | needs to setup anything else for power management support. | 50 | needs to setup anything else for power management support. |
51 | 51 | ||
52 | There is currently no support for over-riding the default method of | 52 | There is currently no support for over-riding the default method of |
@@ -74,7 +74,7 @@ statuc void __init machine_init(void) | |||
74 | 74 | ||
75 | enable_irq_wake(IRQ_EINT0); | 75 | enable_irq_wake(IRQ_EINT0); |
76 | 76 | ||
77 | s3c2410_pm_init(); | 77 | s3c_pm_init(); |
78 | } | 78 | } |
79 | 79 | ||
80 | 80 | ||
diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt index dc6045577a8b..43cb1004d35f 100644 --- a/Documentation/arm/memory.txt +++ b/Documentation/arm/memory.txt | |||
@@ -29,7 +29,14 @@ ffff0000 ffff0fff CPU vector page. | |||
29 | CPU supports vector relocation (control | 29 | CPU supports vector relocation (control |
30 | register V bit.) | 30 | register V bit.) |
31 | 31 | ||
32 | ffc00000 fffeffff DMA memory mapping region. Memory returned | 32 | fffe0000 fffeffff XScale cache flush area. This is used |
33 | in proc-xscale.S to flush the whole data | ||
34 | cache. Free for other usage on non-XScale. | ||
35 | |||
36 | fff00000 fffdffff Fixmap mapping region. Addresses provided | ||
37 | by fix_to_virt() will be located here. | ||
38 | |||
39 | ffc00000 ffefffff DMA memory mapping region. Memory returned | ||
33 | by the dma_alloc_xxx functions will be | 40 | by the dma_alloc_xxx functions will be |
34 | dynamically mapped here. | 41 | dynamically mapped here. |
35 | 42 | ||
diff --git a/Documentation/block/switching-sched.txt b/Documentation/block/switching-sched.txt index 634c952e1964..d5af3f630814 100644 --- a/Documentation/block/switching-sched.txt +++ b/Documentation/block/switching-sched.txt | |||
@@ -35,9 +35,3 @@ noop anticipatory deadline [cfq] | |||
35 | # echo anticipatory > /sys/block/hda/queue/scheduler | 35 | # echo anticipatory > /sys/block/hda/queue/scheduler |
36 | # cat /sys/block/hda/queue/scheduler | 36 | # cat /sys/block/hda/queue/scheduler |
37 | noop [anticipatory] deadline cfq | 37 | noop [anticipatory] deadline cfq |
38 | |||
39 | Each io queue has a set of io scheduler tunables associated with it. These | ||
40 | tunables control how the io scheduler works. You can find these entries | ||
41 | in: | ||
42 | |||
43 | /sys/block/<device>/queue/iosched | ||
diff --git a/Documentation/blockdev/00-INDEX b/Documentation/blockdev/00-INDEX index 86f054c47013..c08df56dd91b 100644 --- a/Documentation/blockdev/00-INDEX +++ b/Documentation/blockdev/00-INDEX | |||
@@ -8,6 +8,8 @@ cpqarray.txt | |||
8 | - info on using Compaq's SMART2 Intelligent Disk Array Controllers. | 8 | - info on using Compaq's SMART2 Intelligent Disk Array Controllers. |
9 | floppy.txt | 9 | floppy.txt |
10 | - notes and driver options for the floppy disk driver. | 10 | - notes and driver options for the floppy disk driver. |
11 | mflash.txt | ||
12 | - info on mGine m(g)flash driver for linux. | ||
11 | nbd.txt | 13 | nbd.txt |
12 | - info on a TCP implementation of a network block device. | 14 | - info on a TCP implementation of a network block device. |
13 | paride.txt | 15 | paride.txt |
diff --git a/Documentation/blockdev/mflash.txt b/Documentation/blockdev/mflash.txt new file mode 100644 index 000000000000..1f610ecf698a --- /dev/null +++ b/Documentation/blockdev/mflash.txt | |||
@@ -0,0 +1,84 @@ | |||
1 | This document describes m[g]flash support in linux. | ||
2 | |||
3 | Contents | ||
4 | 1. Overview | ||
5 | 2. Reserved area configuration | ||
6 | 3. Example of mflash platform driver registration | ||
7 | |||
8 | 1. Overview | ||
9 | |||
10 | Mflash and gflash are embedded flash drive. The only difference is mflash is | ||
11 | MCP(Multi Chip Package) device. These two device operate exactly same way. | ||
12 | So the rest mflash repersents mflash and gflash altogether. | ||
13 | |||
14 | Internally, mflash has nand flash and other hardware logics and supports | ||
15 | 2 different operation (ATA, IO) modes. ATA mode doesn't need any new | ||
16 | driver and currently works well under standard IDE subsystem. Actually it's | ||
17 | one chip SSD. IO mode is ATA-like custom mode for the host that doesn't have | ||
18 | IDE interface. | ||
19 | |||
20 | Followings are brief descriptions about IO mode. | ||
21 | A. IO mode based on ATA protocol and uses some custom command. (read confirm, | ||
22 | write confirm) | ||
23 | B. IO mode uses SRAM bus interface. | ||
24 | C. IO mode supports 4kB boot area, so host can boot from mflash. | ||
25 | |||
26 | 2. Reserved area configuration | ||
27 | If host boot from mflash, usually needs raw area for boot loader image. All of | ||
28 | the mflash's block device operation will be taken this value as start offset. | ||
29 | Note that boot loader's size of reserved area and kernel configuration value | ||
30 | must be same. | ||
31 | |||
32 | 3. Example of mflash platform driver registration | ||
33 | Working mflash is very straight forward. Adding platform device stuff to board | ||
34 | configuration file is all. Here is some pseudo example. | ||
35 | |||
36 | static struct mg_drv_data mflash_drv_data = { | ||
37 | /* If you want to polling driver set to 1 */ | ||
38 | .use_polling = 0, | ||
39 | /* device attribution */ | ||
40 | .dev_attr = MG_BOOT_DEV | ||
41 | }; | ||
42 | |||
43 | static struct resource mg_mflash_rsc[] = { | ||
44 | /* Base address of mflash */ | ||
45 | [0] = { | ||
46 | .start = 0x08000000, | ||
47 | .end = 0x08000000 + SZ_64K - 1, | ||
48 | .flags = IORESOURCE_MEM | ||
49 | }, | ||
50 | /* mflash interrupt pin */ | ||
51 | [1] = { | ||
52 | .start = IRQ_GPIO(84), | ||
53 | .end = IRQ_GPIO(84), | ||
54 | .flags = IORESOURCE_IRQ | ||
55 | }, | ||
56 | /* mflash reset pin */ | ||
57 | [2] = { | ||
58 | .start = 43, | ||
59 | .end = 43, | ||
60 | .name = MG_RST_PIN, | ||
61 | .flags = IORESOURCE_IO | ||
62 | }, | ||
63 | /* mflash reset-out pin | ||
64 | * If you use mflash as storage device (i.e. other than MG_BOOT_DEV), | ||
65 | * should assign this */ | ||
66 | [3] = { | ||
67 | .start = 51, | ||
68 | .end = 51, | ||
69 | .name = MG_RSTOUT_PIN, | ||
70 | .flags = IORESOURCE_IO | ||
71 | } | ||
72 | }; | ||
73 | |||
74 | static struct platform_device mflash_dev = { | ||
75 | .name = MG_DEV_NAME, | ||
76 | .id = -1, | ||
77 | .dev = { | ||
78 | .platform_data = &mflash_drv_data, | ||
79 | }, | ||
80 | .num_resources = ARRAY_SIZE(mg_mflash_rsc), | ||
81 | .resource = mg_mflash_rsc | ||
82 | }; | ||
83 | |||
84 | platform_device_register(&mflash_dev); | ||
diff --git a/Documentation/cgroups/00-INDEX b/Documentation/cgroups/00-INDEX new file mode 100644 index 000000000000..3f58fa3d6d00 --- /dev/null +++ b/Documentation/cgroups/00-INDEX | |||
@@ -0,0 +1,18 @@ | |||
1 | 00-INDEX | ||
2 | - this file | ||
3 | cgroups.txt | ||
4 | - Control Groups definition, implementation details, examples and API. | ||
5 | cpuacct.txt | ||
6 | - CPU Accounting Controller; account CPU usage for groups of tasks. | ||
7 | cpusets.txt | ||
8 | - documents the cpusets feature; assign CPUs and Mem to a set of tasks. | ||
9 | devices.txt | ||
10 | - Device Whitelist Controller; description, interface and security. | ||
11 | freezer-subsystem.txt | ||
12 | - checkpointing; rationale to not use signals, interface. | ||
13 | memcg_test.txt | ||
14 | - Memory Resource Controller; implementation details. | ||
15 | memory.txt | ||
16 | - Memory Resource Controller; design, accounting, interface, testing. | ||
17 | resource_counter.txt | ||
18 | - Resource Counter API. | ||
diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index d9e5d6f41b92..6eb1a97e88ce 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt | |||
@@ -56,7 +56,7 @@ hierarchy, and a set of subsystems; each subsystem has system-specific | |||
56 | state attached to each cgroup in the hierarchy. Each hierarchy has | 56 | state attached to each cgroup in the hierarchy. Each hierarchy has |
57 | an instance of the cgroup virtual filesystem associated with it. | 57 | an instance of the cgroup virtual filesystem associated with it. |
58 | 58 | ||
59 | At any one time there may be multiple active hierachies of task | 59 | At any one time there may be multiple active hierarchies of task |
60 | cgroups. Each hierarchy is a partition of all tasks in the system. | 60 | cgroups. Each hierarchy is a partition of all tasks in the system. |
61 | 61 | ||
62 | User level code may create and destroy cgroups by name in an | 62 | User level code may create and destroy cgroups by name in an |
@@ -124,10 +124,10 @@ following lines: | |||
124 | / \ | 124 | / \ |
125 | Prof (15%) students (5%) | 125 | Prof (15%) students (5%) |
126 | 126 | ||
127 | Browsers like firefox/lynx go into the WWW network class, while (k)nfsd go | 127 | Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go |
128 | into NFS network class. | 128 | into NFS network class. |
129 | 129 | ||
130 | At the same time firefox/lynx will share an appropriate CPU/Memory class | 130 | At the same time Firefox/Lynx will share an appropriate CPU/Memory class |
131 | depending on who launched it (prof/student). | 131 | depending on who launched it (prof/student). |
132 | 132 | ||
133 | With the ability to classify tasks differently for different resources | 133 | With the ability to classify tasks differently for different resources |
@@ -252,10 +252,8 @@ cgroup file system directories. | |||
252 | When a task is moved from one cgroup to another, it gets a new | 252 | When a task is moved from one cgroup to another, it gets a new |
253 | css_set pointer - if there's an already existing css_set with the | 253 | css_set pointer - if there's an already existing css_set with the |
254 | desired collection of cgroups then that group is reused, else a new | 254 | desired collection of cgroups then that group is reused, else a new |
255 | css_set is allocated. Note that the current implementation uses a | 255 | css_set is allocated. The appropriate existing css_set is located by |
256 | linear search to locate an appropriate existing css_set, so isn't | 256 | looking into a hash table. |
257 | very efficient. A future version will use a hash table for better | ||
258 | performance. | ||
259 | 257 | ||
260 | To allow access from a cgroup to the css_sets (and hence tasks) | 258 | To allow access from a cgroup to the css_sets (and hence tasks) |
261 | that comprise it, a set of cg_cgroup_link objects form a lattice; | 259 | that comprise it, a set of cg_cgroup_link objects form a lattice; |
@@ -327,7 +325,7 @@ and then start a subshell 'sh' in that cgroup: | |||
327 | Creating, modifying, using the cgroups can be done through the cgroup | 325 | Creating, modifying, using the cgroups can be done through the cgroup |
328 | virtual filesystem. | 326 | virtual filesystem. |
329 | 327 | ||
330 | To mount a cgroup hierarchy will all available subsystems, type: | 328 | To mount a cgroup hierarchy with all available subsystems, type: |
331 | # mount -t cgroup xxx /dev/cgroup | 329 | # mount -t cgroup xxx /dev/cgroup |
332 | 330 | ||
333 | The "xxx" is not interpreted by the cgroup code, but will appear in | 331 | The "xxx" is not interpreted by the cgroup code, but will appear in |
@@ -335,12 +333,23 @@ The "xxx" is not interpreted by the cgroup code, but will appear in | |||
335 | 333 | ||
336 | To mount a cgroup hierarchy with just the cpuset and numtasks | 334 | To mount a cgroup hierarchy with just the cpuset and numtasks |
337 | subsystems, type: | 335 | subsystems, type: |
338 | # mount -t cgroup -o cpuset,numtasks hier1 /dev/cgroup | 336 | # mount -t cgroup -o cpuset,memory hier1 /dev/cgroup |
339 | 337 | ||
340 | To change the set of subsystems bound to a mounted hierarchy, just | 338 | To change the set of subsystems bound to a mounted hierarchy, just |
341 | remount with different options: | 339 | remount with different options: |
340 | # mount -o remount,cpuset,ns hier1 /dev/cgroup | ||
342 | 341 | ||
343 | # mount -o remount,cpuset,ns /dev/cgroup | 342 | Now memory is removed from the hierarchy and ns is added. |
343 | |||
344 | Note this will add ns to the hierarchy but won't remove memory or | ||
345 | cpuset, because the new options are appended to the old ones: | ||
346 | # mount -o remount,ns /dev/cgroup | ||
347 | |||
348 | To Specify a hierarchy's release_agent: | ||
349 | # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \ | ||
350 | xxx /dev/cgroup | ||
351 | |||
352 | Note that specifying 'release_agent' more than once will return failure. | ||
344 | 353 | ||
345 | Note that changing the set of subsystems is currently only supported | 354 | Note that changing the set of subsystems is currently only supported |
346 | when the hierarchy consists of a single (root) cgroup. Supporting | 355 | when the hierarchy consists of a single (root) cgroup. Supporting |
@@ -351,6 +360,11 @@ Then under /dev/cgroup you can find a tree that corresponds to the | |||
351 | tree of the cgroups in the system. For instance, /dev/cgroup | 360 | tree of the cgroups in the system. For instance, /dev/cgroup |
352 | is the cgroup that holds the whole system. | 361 | is the cgroup that holds the whole system. |
353 | 362 | ||
363 | If you want to change the value of release_agent: | ||
364 | # echo "/sbin/new_release_agent" > /dev/cgroup/release_agent | ||
365 | |||
366 | It can also be changed via remount. | ||
367 | |||
354 | If you want to create a new cgroup under /dev/cgroup: | 368 | If you want to create a new cgroup under /dev/cgroup: |
355 | # cd /dev/cgroup | 369 | # cd /dev/cgroup |
356 | # mkdir my_cgroup | 370 | # mkdir my_cgroup |
@@ -478,11 +492,13 @@ cgroup->parent is still valid. (Note - can also be called for a | |||
478 | newly-created cgroup if an error occurs after this subsystem's | 492 | newly-created cgroup if an error occurs after this subsystem's |
479 | create() method has been called for the new cgroup). | 493 | create() method has been called for the new cgroup). |
480 | 494 | ||
481 | void pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp); | 495 | int pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp); |
482 | 496 | ||
483 | Called before checking the reference count on each subsystem. This may | 497 | Called before checking the reference count on each subsystem. This may |
484 | be useful for subsystems which have some extra references even if | 498 | be useful for subsystems which have some extra references even if |
485 | there are not tasks in the cgroup. | 499 | there are not tasks in the cgroup. If pre_destroy() returns error code, |
500 | rmdir() will fail with it. From this behavior, pre_destroy() can be | ||
501 | called multiple times against a cgroup. | ||
486 | 502 | ||
487 | int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, | 503 | int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, |
488 | struct task_struct *task) | 504 | struct task_struct *task) |
@@ -523,7 +539,7 @@ always handled well. | |||
523 | void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp) | 539 | void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp) |
524 | (cgroup_mutex held by caller) | 540 | (cgroup_mutex held by caller) |
525 | 541 | ||
526 | Called at the end of cgroup_clone() to do any paramater | 542 | Called at the end of cgroup_clone() to do any parameter |
527 | initialization which might be required before a task could attach. For | 543 | initialization which might be required before a task could attach. For |
528 | example in cpusets, no task may attach before 'cpus' and 'mems' are set | 544 | example in cpusets, no task may attach before 'cpus' and 'mems' are set |
529 | up. | 545 | up. |
diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt index 5c86c258c791..f9ca389dddf4 100644 --- a/Documentation/cgroups/cpusets.txt +++ b/Documentation/cgroups/cpusets.txt | |||
@@ -131,7 +131,7 @@ Cpusets extends these two mechanisms as follows: | |||
131 | - The hierarchy of cpusets can be mounted at /dev/cpuset, for | 131 | - The hierarchy of cpusets can be mounted at /dev/cpuset, for |
132 | browsing and manipulation from user space. | 132 | browsing and manipulation from user space. |
133 | - A cpuset may be marked exclusive, which ensures that no other | 133 | - A cpuset may be marked exclusive, which ensures that no other |
134 | cpuset (except direct ancestors and descendents) may contain | 134 | cpuset (except direct ancestors and descendants) may contain |
135 | any overlapping CPUs or Memory Nodes. | 135 | any overlapping CPUs or Memory Nodes. |
136 | - You can list all the tasks (by pid) attached to any cpuset. | 136 | - You can list all the tasks (by pid) attached to any cpuset. |
137 | 137 | ||
@@ -142,7 +142,7 @@ into the rest of the kernel, none in performance critical paths: | |||
142 | - in fork and exit, to attach and detach a task from its cpuset. | 142 | - in fork and exit, to attach and detach a task from its cpuset. |
143 | - in sched_setaffinity, to mask the requested CPUs by what's | 143 | - in sched_setaffinity, to mask the requested CPUs by what's |
144 | allowed in that tasks cpuset. | 144 | allowed in that tasks cpuset. |
145 | - in sched.c migrate_all_tasks(), to keep migrating tasks within | 145 | - in sched.c migrate_live_tasks(), to keep migrating tasks within |
146 | the CPUs allowed by their cpuset, if possible. | 146 | the CPUs allowed by their cpuset, if possible. |
147 | - in the mbind and set_mempolicy system calls, to mask the requested | 147 | - in the mbind and set_mempolicy system calls, to mask the requested |
148 | Memory Nodes by what's allowed in that tasks cpuset. | 148 | Memory Nodes by what's allowed in that tasks cpuset. |
@@ -175,6 +175,10 @@ files describing that cpuset: | |||
175 | - mem_exclusive flag: is memory placement exclusive? | 175 | - mem_exclusive flag: is memory placement exclusive? |
176 | - mem_hardwall flag: is memory allocation hardwalled | 176 | - mem_hardwall flag: is memory allocation hardwalled |
177 | - memory_pressure: measure of how much paging pressure in cpuset | 177 | - memory_pressure: measure of how much paging pressure in cpuset |
178 | - memory_spread_page flag: if set, spread page cache evenly on allowed nodes | ||
179 | - memory_spread_slab flag: if set, spread slab cache evenly on allowed nodes | ||
180 | - sched_load_balance flag: if set, load balance within CPUs on that cpuset | ||
181 | - sched_relax_domain_level: the searching range when migrating tasks | ||
178 | 182 | ||
179 | In addition, the root cpuset only has the following file: | 183 | In addition, the root cpuset only has the following file: |
180 | - memory_pressure_enabled flag: compute memory_pressure? | 184 | - memory_pressure_enabled flag: compute memory_pressure? |
@@ -222,7 +226,7 @@ nodes with memory--using the cpuset_track_online_nodes() hook. | |||
222 | -------------------------------- | 226 | -------------------------------- |
223 | 227 | ||
224 | If a cpuset is cpu or mem exclusive, no other cpuset, other than | 228 | If a cpuset is cpu or mem exclusive, no other cpuset, other than |
225 | a direct ancestor or descendent, may share any of the same CPUs or | 229 | a direct ancestor or descendant, may share any of the same CPUs or |
226 | Memory Nodes. | 230 | Memory Nodes. |
227 | 231 | ||
228 | A cpuset that is mem_exclusive *or* mem_hardwall is "hardwalled", | 232 | A cpuset that is mem_exclusive *or* mem_hardwall is "hardwalled", |
@@ -252,7 +256,7 @@ is causing. | |||
252 | 256 | ||
253 | This is useful both on tightly managed systems running a wide mix of | 257 | This is useful both on tightly managed systems running a wide mix of |
254 | submitted jobs, which may choose to terminate or re-prioritize jobs that | 258 | submitted jobs, which may choose to terminate or re-prioritize jobs that |
255 | are trying to use more memory than allowed on the nodes assigned them, | 259 | are trying to use more memory than allowed on the nodes assigned to them, |
256 | and with tightly coupled, long running, massively parallel scientific | 260 | and with tightly coupled, long running, massively parallel scientific |
257 | computing jobs that will dramatically fail to meet required performance | 261 | computing jobs that will dramatically fail to meet required performance |
258 | goals if they start to use more memory than allowed to them. | 262 | goals if they start to use more memory than allowed to them. |
@@ -378,7 +382,7 @@ as cpusets and sched_setaffinity. | |||
378 | The algorithmic cost of load balancing and its impact on key shared | 382 | The algorithmic cost of load balancing and its impact on key shared |
379 | kernel data structures such as the task list increases more than | 383 | kernel data structures such as the task list increases more than |
380 | linearly with the number of CPUs being balanced. So the scheduler | 384 | linearly with the number of CPUs being balanced. So the scheduler |
381 | has support to partition the systems CPUs into a number of sched | 385 | has support to partition the systems CPUs into a number of sched |
382 | domains such that it only load balances within each sched domain. | 386 | domains such that it only load balances within each sched domain. |
383 | Each sched domain covers some subset of the CPUs in the system; | 387 | Each sched domain covers some subset of the CPUs in the system; |
384 | no two sched domains overlap; some CPUs might not be in any sched | 388 | no two sched domains overlap; some CPUs might not be in any sched |
@@ -423,7 +427,7 @@ child cpusets have this flag enabled. | |||
423 | When doing this, you don't usually want to leave any unpinned tasks in | 427 | When doing this, you don't usually want to leave any unpinned tasks in |
424 | the top cpuset that might use non-trivial amounts of CPU, as such tasks | 428 | the top cpuset that might use non-trivial amounts of CPU, as such tasks |
425 | may be artificially constrained to some subset of CPUs, depending on | 429 | may be artificially constrained to some subset of CPUs, depending on |
426 | the particulars of this flag setting in descendent cpusets. Even if | 430 | the particulars of this flag setting in descendant cpusets. Even if |
427 | such a task could use spare CPU cycles in some other CPUs, the kernel | 431 | such a task could use spare CPU cycles in some other CPUs, the kernel |
428 | scheduler might not consider the possibility of load balancing that | 432 | scheduler might not consider the possibility of load balancing that |
429 | task to that underused CPU. | 433 | task to that underused CPU. |
@@ -485,17 +489,22 @@ of CPUs allowed to a cpuset having 'sched_load_balance' enabled. | |||
485 | The internal kernel cpuset to scheduler interface passes from the | 489 | The internal kernel cpuset to scheduler interface passes from the |
486 | cpuset code to the scheduler code a partition of the load balanced | 490 | cpuset code to the scheduler code a partition of the load balanced |
487 | CPUs in the system. This partition is a set of subsets (represented | 491 | CPUs in the system. This partition is a set of subsets (represented |
488 | as an array of cpumask_t) of CPUs, pairwise disjoint, that cover all | 492 | as an array of struct cpumask) of CPUs, pairwise disjoint, that cover |
489 | the CPUs that must be load balanced. | 493 | all the CPUs that must be load balanced. |
490 | 494 | ||
491 | Whenever the 'sched_load_balance' flag changes, or CPUs come or go | 495 | The cpuset code builds a new such partition and passes it to the |
492 | from a cpuset with this flag enabled, or a cpuset with this flag | 496 | scheduler sched domain setup code, to have the sched domains rebuilt |
493 | enabled is removed, the cpuset code builds a new such partition and | 497 | as necessary, whenever: |
494 | passes it to the scheduler sched domain setup code, to have the sched | 498 | - the 'sched_load_balance' flag of a cpuset with non-empty CPUs changes, |
495 | domains rebuilt as necessary. | 499 | - or CPUs come or go from a cpuset with this flag enabled, |
500 | - or 'sched_relax_domain_level' value of a cpuset with non-empty CPUs | ||
501 | and with this flag enabled changes, | ||
502 | - or a cpuset with non-empty CPUs and with this flag enabled is removed, | ||
503 | - or a cpu is offlined/onlined. | ||
496 | 504 | ||
497 | This partition exactly defines what sched domains the scheduler should | 505 | This partition exactly defines what sched domains the scheduler should |
498 | setup - one sched domain for each element (cpumask_t) in the partition. | 506 | setup - one sched domain for each element (struct cpumask) in the |
507 | partition. | ||
499 | 508 | ||
500 | The scheduler remembers the currently active sched domain partitions. | 509 | The scheduler remembers the currently active sched domain partitions. |
501 | When the scheduler routine partition_sched_domains() is invoked from | 510 | When the scheduler routine partition_sched_domains() is invoked from |
@@ -522,9 +531,9 @@ be idle. | |||
522 | 531 | ||
523 | Of course it takes some searching cost to find movable tasks and/or | 532 | Of course it takes some searching cost to find movable tasks and/or |
524 | idle CPUs, the scheduler might not search all CPUs in the domain | 533 | idle CPUs, the scheduler might not search all CPUs in the domain |
525 | everytime. In fact, in some architectures, the searching ranges on | 534 | every time. In fact, in some architectures, the searching ranges on |
526 | events are limited in the same socket or node where the CPU locates, | 535 | events are limited in the same socket or node where the CPU locates, |
527 | while the load balance on tick searchs all. | 536 | while the load balance on tick searches all. |
528 | 537 | ||
529 | For example, assume CPU Z is relatively far from CPU X. Even if CPU Z | 538 | For example, assume CPU Z is relatively far from CPU X. Even if CPU Z |
530 | is idle while CPU X and the siblings are busy, scheduler can't migrate | 539 | is idle while CPU X and the siblings are busy, scheduler can't migrate |
@@ -559,7 +568,7 @@ domain, the largest value among those is used. Be careful, if one | |||
559 | requests 0 and others are -1 then 0 is used. | 568 | requests 0 and others are -1 then 0 is used. |
560 | 569 | ||
561 | Note that modifying this file will have both good and bad effects, | 570 | Note that modifying this file will have both good and bad effects, |
562 | and whether it is acceptable or not will be depend on your situation. | 571 | and whether it is acceptable or not depends on your situation. |
563 | Don't modify this file if you are not sure. | 572 | Don't modify this file if you are not sure. |
564 | 573 | ||
565 | If your situation is: | 574 | If your situation is: |
@@ -592,7 +601,7 @@ its new cpuset, then the task will continue to use whatever subset | |||
592 | of MPOL_BIND nodes are still allowed in the new cpuset. If the task | 601 | of MPOL_BIND nodes are still allowed in the new cpuset. If the task |
593 | was using MPOL_BIND and now none of its MPOL_BIND nodes are allowed | 602 | was using MPOL_BIND and now none of its MPOL_BIND nodes are allowed |
594 | in the new cpuset, then the task will be essentially treated as if it | 603 | in the new cpuset, then the task will be essentially treated as if it |
595 | was MPOL_BIND bound to the new cpuset (even though its numa placement, | 604 | was MPOL_BIND bound to the new cpuset (even though its NUMA placement, |
596 | as queried by get_mempolicy(), doesn't change). If a task is moved | 605 | as queried by get_mempolicy(), doesn't change). If a task is moved |
597 | from one cpuset to another, then the kernel will adjust the tasks | 606 | from one cpuset to another, then the kernel will adjust the tasks |
598 | memory placement, as above, the next time that the kernel attempts | 607 | memory placement, as above, the next time that the kernel attempts |
@@ -600,19 +609,15 @@ to allocate a page of memory for that task. | |||
600 | 609 | ||
601 | If a cpuset has its 'cpus' modified, then each task in that cpuset | 610 | If a cpuset has its 'cpus' modified, then each task in that cpuset |
602 | will have its allowed CPU placement changed immediately. Similarly, | 611 | will have its allowed CPU placement changed immediately. Similarly, |
603 | if a tasks pid is written to a cpusets 'tasks' file, in either its | 612 | if a tasks pid is written to another cpusets 'tasks' file, then its |
604 | current cpuset or another cpuset, then its allowed CPU placement is | 613 | allowed CPU placement is changed immediately. If such a task had been |
605 | changed immediately. If such a task had been bound to some subset | 614 | bound to some subset of its cpuset using the sched_setaffinity() call, |
606 | of its cpuset using the sched_setaffinity() call, the task will be | 615 | the task will be allowed to run on any CPU allowed in its new cpuset, |
607 | allowed to run on any CPU allowed in its new cpuset, negating the | 616 | negating the effect of the prior sched_setaffinity() call. |
608 | affect of the prior sched_setaffinity() call. | ||
609 | 617 | ||
610 | In summary, the memory placement of a task whose cpuset is changed is | 618 | In summary, the memory placement of a task whose cpuset is changed is |
611 | updated by the kernel, on the next allocation of a page for that task, | 619 | updated by the kernel, on the next allocation of a page for that task, |
612 | but the processor placement is not updated, until that tasks pid is | 620 | and the processor placement is updated immediately. |
613 | rewritten to the 'tasks' file of its cpuset. This is done to avoid | ||
614 | impacting the scheduler code in the kernel with a check for changes | ||
615 | in a tasks processor placement. | ||
616 | 621 | ||
617 | Normally, once a page is allocated (given a physical page | 622 | Normally, once a page is allocated (given a physical page |
618 | of main memory) then that page stays on whatever node it | 623 | of main memory) then that page stays on whatever node it |
@@ -681,10 +686,14 @@ and then start a subshell 'sh' in that cpuset: | |||
681 | # The next line should display '/Charlie' | 686 | # The next line should display '/Charlie' |
682 | cat /proc/self/cpuset | 687 | cat /proc/self/cpuset |
683 | 688 | ||
684 | In the future, a C library interface to cpusets will likely be | 689 | There are ways to query or modify cpusets: |
685 | available. For now, the only way to query or modify cpusets is | 690 | - via the cpuset file system directly, using the various cd, mkdir, echo, |
686 | via the cpuset file system, using the various cd, mkdir, echo, cat, | 691 | cat, rmdir commands from the shell, or their equivalent from C. |
687 | rmdir commands from the shell, or their equivalent from C. | 692 | - via the C library libcpuset. |
693 | - via the C library libcgroup. | ||
694 | (http://sourceforge.net/proects/libcg/) | ||
695 | - via the python application cset. | ||
696 | (http://developer.novell.com/wiki/index.php/Cpuset) | ||
688 | 697 | ||
689 | The sched_setaffinity calls can also be done at the shell prompt using | 698 | The sched_setaffinity calls can also be done at the shell prompt using |
690 | SGI's runon or Robert Love's taskset. The mbind and set_mempolicy | 699 | SGI's runon or Robert Love's taskset. The mbind and set_mempolicy |
@@ -756,7 +765,7 @@ mount -t cpuset X /dev/cpuset | |||
756 | 765 | ||
757 | is equivalent to | 766 | is equivalent to |
758 | 767 | ||
759 | mount -t cgroup -ocpuset X /dev/cpuset | 768 | mount -t cgroup -ocpuset,noprefix X /dev/cpuset |
760 | echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent | 769 | echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent |
761 | 770 | ||
762 | 2.2 Adding/removing cpus | 771 | 2.2 Adding/removing cpus |
diff --git a/Documentation/cgroups/devices.txt b/Documentation/cgroups/devices.txt index 7cc6e6a60672..57ca4c89fe5c 100644 --- a/Documentation/cgroups/devices.txt +++ b/Documentation/cgroups/devices.txt | |||
@@ -42,7 +42,7 @@ suffice, but we can decide the best way to adequately restrict | |||
42 | movement as people get some experience with this. We may just want | 42 | movement as people get some experience with this. We may just want |
43 | to require CAP_SYS_ADMIN, which at least is a separate bit from | 43 | to require CAP_SYS_ADMIN, which at least is a separate bit from |
44 | CAP_MKNOD. We may want to just refuse moving to a cgroup which | 44 | CAP_MKNOD. We may want to just refuse moving to a cgroup which |
45 | isn't a descendent of the current one. Or we may want to use | 45 | isn't a descendant of the current one. Or we may want to use |
46 | CAP_MAC_ADMIN, since we really are trying to lock down root. | 46 | CAP_MAC_ADMIN, since we really are trying to lock down root. |
47 | 47 | ||
48 | CAP_SYS_ADMIN is needed to modify the whitelist or move another | 48 | CAP_SYS_ADMIN is needed to modify the whitelist or move another |
diff --git a/Documentation/cgroups/memcg_test.txt b/Documentation/cgroups/memcg_test.txt index 523a9c16c400..72db89ed0609 100644 --- a/Documentation/cgroups/memcg_test.txt +++ b/Documentation/cgroups/memcg_test.txt | |||
@@ -1,5 +1,5 @@ | |||
1 | Memory Resource Controller(Memcg) Implementation Memo. | 1 | Memory Resource Controller(Memcg) Implementation Memo. |
2 | Last Updated: 2009/1/19 | 2 | Last Updated: 2009/1/20 |
3 | Base Kernel Version: based on 2.6.29-rc2. | 3 | Base Kernel Version: based on 2.6.29-rc2. |
4 | 4 | ||
5 | Because VM is getting complex (one of reasons is memcg...), memcg's behavior | 5 | Because VM is getting complex (one of reasons is memcg...), memcg's behavior |
@@ -356,7 +356,25 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. | |||
356 | (Shell-B) | 356 | (Shell-B) |
357 | # move all tasks in /cgroup/test to /cgroup | 357 | # move all tasks in /cgroup/test to /cgroup |
358 | # /sbin/swapoff -a | 358 | # /sbin/swapoff -a |
359 | # rmdir /test/cgroup | 359 | # rmdir /cgroup/test |
360 | # kill malloc task. | 360 | # kill malloc task. |
361 | 361 | ||
362 | Of course, tmpfs v.s. swapoff test should be tested, too. | 362 | Of course, tmpfs v.s. swapoff test should be tested, too. |
363 | |||
364 | 9.8 OOM-Killer | ||
365 | Out-of-memory caused by memcg's limit will kill tasks under | ||
366 | the memcg. When hierarchy is used, a task under hierarchy | ||
367 | will be killed by the kernel. | ||
368 | In this case, panic_on_oom shouldn't be invoked and tasks | ||
369 | in other groups shouldn't be killed. | ||
370 | |||
371 | It's not difficult to cause OOM under memcg as following. | ||
372 | Case A) when you can swapoff | ||
373 | #swapoff -a | ||
374 | #echo 50M > /memory.limit_in_bytes | ||
375 | run 51M of malloc | ||
376 | |||
377 | Case B) when you use mem+swap limitation. | ||
378 | #echo 50M > memory.limit_in_bytes | ||
379 | #echo 50M > memory.memsw.limit_in_bytes | ||
380 | run 51M of malloc | ||
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index e1501964df1e..a98a7fe7aabb 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt | |||
@@ -302,7 +302,7 @@ will be charged as a new owner of it. | |||
302 | unevictable - # of pages cannot be reclaimed.(mlocked etc) | 302 | unevictable - # of pages cannot be reclaimed.(mlocked etc) |
303 | 303 | ||
304 | Below is depend on CONFIG_DEBUG_VM. | 304 | Below is depend on CONFIG_DEBUG_VM. |
305 | inactive_ratio - VM inernal parameter. (see mm/page_alloc.c) | 305 | inactive_ratio - VM internal parameter. (see mm/page_alloc.c) |
306 | recent_rotated_anon - VM internal parameter. (see mm/vmscan.c) | 306 | recent_rotated_anon - VM internal parameter. (see mm/vmscan.c) |
307 | recent_rotated_file - VM internal parameter. (see mm/vmscan.c) | 307 | recent_rotated_file - VM internal parameter. (see mm/vmscan.c) |
308 | recent_scanned_anon - VM internal parameter. (see mm/vmscan.c) | 308 | recent_scanned_anon - VM internal parameter. (see mm/vmscan.c) |
diff --git a/Documentation/connector/cn_test.c b/Documentation/connector/cn_test.c index be7af146dd30..6977c178729a 100644 --- a/Documentation/connector/cn_test.c +++ b/Documentation/connector/cn_test.c | |||
@@ -137,7 +137,7 @@ static void cn_test_timer_func(unsigned long __data) | |||
137 | 137 | ||
138 | memcpy(m + 1, data, m->len); | 138 | memcpy(m + 1, data, m->len); |
139 | 139 | ||
140 | cn_netlink_send(m, 0, gfp_any()); | 140 | cn_netlink_send(m, 0, GFP_ATOMIC); |
141 | kfree(m); | 141 | kfree(m); |
142 | } | 142 | } |
143 | 143 | ||
@@ -160,10 +160,8 @@ static int cn_test_init(void) | |||
160 | goto err_out; | 160 | goto err_out; |
161 | } | 161 | } |
162 | 162 | ||
163 | init_timer(&cn_test_timer); | 163 | setup_timer(&cn_test_timer, cn_test_timer_func, 0); |
164 | cn_test_timer.function = cn_test_timer_func; | ||
165 | cn_test_timer.expires = jiffies + HZ; | 164 | cn_test_timer.expires = jiffies + HZ; |
166 | cn_test_timer.data = 0; | ||
167 | add_timer(&cn_test_timer); | 165 | add_timer(&cn_test_timer); |
168 | 166 | ||
169 | return 0; | 167 | return 0; |
diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index 5b0cfa67aff9..ce73f3eb5ddb 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt | |||
@@ -117,10 +117,28 @@ accessible parameters: | |||
117 | sampling_rate: measured in uS (10^-6 seconds), this is how often you | 117 | sampling_rate: measured in uS (10^-6 seconds), this is how often you |
118 | want the kernel to look at the CPU usage and to make decisions on | 118 | want the kernel to look at the CPU usage and to make decisions on |
119 | what to do about the frequency. Typically this is set to values of | 119 | what to do about the frequency. Typically this is set to values of |
120 | around '10000' or more. | 120 | around '10000' or more. It's default value is (cmp. with users-guide.txt): |
121 | 121 | transition_latency * 1000 | |
122 | show_sampling_rate_(min|max): the minimum and maximum sampling rates | 122 | The lowest value you can set is: |
123 | available that you may set 'sampling_rate' to. | 123 | transition_latency * 100 or it may get restricted to a value where it |
124 | makes not sense for the kernel anymore to poll that often which depends | ||
125 | on your HZ config variable (HZ=1000: max=20000us, HZ=250: max=5000). | ||
126 | Be aware that transition latency is in ns and sampling_rate is in us, so you | ||
127 | get the same sysfs value by default. | ||
128 | Sampling rate should always get adjusted considering the transition latency | ||
129 | To set the sampling rate 750 times as high as the transition latency | ||
130 | in the bash (as said, 1000 is default), do: | ||
131 | echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) \ | ||
132 | >ondemand/sampling_rate | ||
133 | |||
134 | show_sampling_rate_(min|max): THIS INTERFACE IS DEPRECATED, DON'T USE IT. | ||
135 | You can use wider ranges now and the general | ||
136 | cpuinfo_transition_latency variable (cmp. with user-guide.txt) can be | ||
137 | used to obtain exactly the same info: | ||
138 | show_sampling_rate_min = transtition_latency * 500 / 1000 | ||
139 | show_sampling_rate_max = transtition_latency * 500000 / 1000 | ||
140 | (divided by 1000 is to illustrate that sampling rate is in us and | ||
141 | transition latency is exported ns). | ||
124 | 142 | ||
125 | up_threshold: defines what the average CPU usage between the samplings | 143 | up_threshold: defines what the average CPU usage between the samplings |
126 | of 'sampling_rate' needs to be for the kernel to make a decision on | 144 | of 'sampling_rate' needs to be for the kernel to make a decision on |
diff --git a/Documentation/cpu-freq/user-guide.txt b/Documentation/cpu-freq/user-guide.txt index e3443ddcfb89..75f41193f3e1 100644 --- a/Documentation/cpu-freq/user-guide.txt +++ b/Documentation/cpu-freq/user-guide.txt | |||
@@ -152,6 +152,18 @@ cpuinfo_min_freq : this file shows the minimum operating | |||
152 | frequency the processor can run at(in kHz) | 152 | frequency the processor can run at(in kHz) |
153 | cpuinfo_max_freq : this file shows the maximum operating | 153 | cpuinfo_max_freq : this file shows the maximum operating |
154 | frequency the processor can run at(in kHz) | 154 | frequency the processor can run at(in kHz) |
155 | cpuinfo_transition_latency The time it takes on this CPU to | ||
156 | switch between two frequencies in nano | ||
157 | seconds. If unknown or known to be | ||
158 | that high that the driver does not | ||
159 | work with the ondemand governor, -1 | ||
160 | (CPUFREQ_ETERNAL) will be returned. | ||
161 | Using this information can be useful | ||
162 | to choose an appropriate polling | ||
163 | frequency for a kernel governor or | ||
164 | userspace daemon. Make sure to not | ||
165 | switch the frequency too often | ||
166 | resulting in performance loss. | ||
155 | scaling_driver : this file shows what cpufreq driver is | 167 | scaling_driver : this file shows what cpufreq driver is |
156 | used to set the frequency on this CPU | 168 | used to set the frequency on this CPU |
157 | 169 | ||
@@ -195,19 +207,3 @@ scaling_setspeed. By "echoing" a new frequency into this | |||
195 | you can change the speed of the CPU, | 207 | you can change the speed of the CPU, |
196 | but only within the limits of | 208 | but only within the limits of |
197 | scaling_min_freq and scaling_max_freq. | 209 | scaling_min_freq and scaling_max_freq. |
198 | |||
199 | |||
200 | 3.2 Deprecated Interfaces | ||
201 | ------------------------- | ||
202 | |||
203 | Depending on your kernel configuration, you might find the following | ||
204 | cpufreq-related files: | ||
205 | /proc/cpufreq | ||
206 | /proc/sys/cpu/*/speed | ||
207 | /proc/sys/cpu/*/speed-min | ||
208 | /proc/sys/cpu/*/speed-max | ||
209 | |||
210 | These are files for deprecated interfaces to cpufreq, which offer far | ||
211 | less functionality. Because of this, these interfaces aren't described | ||
212 | here. | ||
213 | |||
diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt index 45932ec21cee..b41f3e58aefa 100644 --- a/Documentation/cputopology.txt +++ b/Documentation/cputopology.txt | |||
@@ -18,11 +18,11 @@ For an architecture to support this feature, it must define some of | |||
18 | these macros in include/asm-XXX/topology.h: | 18 | these macros in include/asm-XXX/topology.h: |
19 | #define topology_physical_package_id(cpu) | 19 | #define topology_physical_package_id(cpu) |
20 | #define topology_core_id(cpu) | 20 | #define topology_core_id(cpu) |
21 | #define topology_thread_siblings(cpu) | 21 | #define topology_thread_cpumask(cpu) |
22 | #define topology_core_siblings(cpu) | 22 | #define topology_core_cpumask(cpu) |
23 | 23 | ||
24 | The type of **_id is int. | 24 | The type of **_id is int. |
25 | The type of siblings is cpumask_t. | 25 | The type of siblings is (const) struct cpumask *. |
26 | 26 | ||
27 | To be consistent on all architectures, include/linux/topology.h | 27 | To be consistent on all architectures, include/linux/topology.h |
28 | provides default definitions for any of the above macros that are | 28 | provides default definitions for any of the above macros that are |
diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 2be08240ee80..53d64d382343 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt | |||
@@ -1,9 +1,9 @@ | |||
1 | 1 | ||
2 | LINUX ALLOCATED DEVICES (2.6+ version) | 2 | LINUX ALLOCATED DEVICES (2.6+ version) |
3 | 3 | ||
4 | Maintained by Torben Mathiasen <device@lanana.org> | 4 | Maintained by Alan Cox <device@lanana.org> |
5 | 5 | ||
6 | Last revised: 29 November 2006 | 6 | Last revised: 6th April 2009 |
7 | 7 | ||
8 | This list is the Linux Device List, the official registry of allocated | 8 | This list is the Linux Device List, the official registry of allocated |
9 | device numbers and /dev directory nodes for the Linux operating | 9 | device numbers and /dev directory nodes for the Linux operating |
@@ -67,6 +67,11 @@ up to date. Due to the number of registrations I have to maintain it | |||
67 | in "batch mode", so there is likely additional registrations that | 67 | in "batch mode", so there is likely additional registrations that |
68 | haven't been listed yet. | 68 | haven't been listed yet. |
69 | 69 | ||
70 | Fourth, remember that Linux now has extensive support for dynamic allocation | ||
71 | of device numbering and can use sysfs and udev to handle the naming needs. | ||
72 | There are still some exceptions in the serial and boot device area. Before | ||
73 | asking for a device number make sure you actually need one. | ||
74 | |||
70 | Finally, sometimes I have to play "namespace police." Please don't be | 75 | Finally, sometimes I have to play "namespace police." Please don't be |
71 | offended. I often get submissions for /dev names that would be bound | 76 | offended. I often get submissions for /dev names that would be bound |
72 | to cause conflicts down the road. I am trying to avoid getting in a | 77 | to cause conflicts down the road. I am trying to avoid getting in a |
@@ -101,7 +106,7 @@ Your cooperation is appreciated. | |||
101 | 0 = /dev/ram0 First RAM disk | 106 | 0 = /dev/ram0 First RAM disk |
102 | 1 = /dev/ram1 Second RAM disk | 107 | 1 = /dev/ram1 Second RAM disk |
103 | ... | 108 | ... |
104 | 250 = /dev/initrd Initial RAM disk {2.6} | 109 | 250 = /dev/initrd Initial RAM disk |
105 | 110 | ||
106 | Older kernels had /dev/ramdisk (1, 1) here. | 111 | Older kernels had /dev/ramdisk (1, 1) here. |
107 | /dev/initrd refers to a RAM disk which was preloaded | 112 | /dev/initrd refers to a RAM disk which was preloaded |
@@ -340,7 +345,7 @@ Your cooperation is appreciated. | |||
340 | 14 = /dev/touchscreen/ucb1x00 UCB 1x00 touchscreen | 345 | 14 = /dev/touchscreen/ucb1x00 UCB 1x00 touchscreen |
341 | 15 = /dev/touchscreen/mk712 MK712 touchscreen | 346 | 15 = /dev/touchscreen/mk712 MK712 touchscreen |
342 | 128 = /dev/beep Fancy beep device | 347 | 128 = /dev/beep Fancy beep device |
343 | 129 = /dev/modreq Kernel module load request {2.6} | 348 | 129 = |
344 | 130 = /dev/watchdog Watchdog timer port | 349 | 130 = /dev/watchdog Watchdog timer port |
345 | 131 = /dev/temperature Machine internal temperature | 350 | 131 = /dev/temperature Machine internal temperature |
346 | 132 = /dev/hwtrap Hardware fault trap | 351 | 132 = /dev/hwtrap Hardware fault trap |
@@ -350,10 +355,10 @@ Your cooperation is appreciated. | |||
350 | 139 = /dev/openprom SPARC OpenBoot PROM | 355 | 139 = /dev/openprom SPARC OpenBoot PROM |
351 | 140 = /dev/relay8 Berkshire Products Octal relay card | 356 | 140 = /dev/relay8 Berkshire Products Octal relay card |
352 | 141 = /dev/relay16 Berkshire Products ISO-16 relay card | 357 | 141 = /dev/relay16 Berkshire Products ISO-16 relay card |
353 | 142 = /dev/msr x86 model-specific registers {2.6} | 358 | 142 = |
354 | 143 = /dev/pciconf PCI configuration space | 359 | 143 = /dev/pciconf PCI configuration space |
355 | 144 = /dev/nvram Non-volatile configuration RAM | 360 | 144 = /dev/nvram Non-volatile configuration RAM |
356 | 145 = /dev/hfmodem Soundcard shortwave modem control {2.6} | 361 | 145 = /dev/hfmodem Soundcard shortwave modem control |
357 | 146 = /dev/graphics Linux/SGI graphics device | 362 | 146 = /dev/graphics Linux/SGI graphics device |
358 | 147 = /dev/opengl Linux/SGI OpenGL pipe | 363 | 147 = /dev/opengl Linux/SGI OpenGL pipe |
359 | 148 = /dev/gfx Linux/SGI graphics effects device | 364 | 148 = /dev/gfx Linux/SGI graphics effects device |
@@ -435,6 +440,9 @@ Your cooperation is appreciated. | |||
435 | 228 = /dev/hpet HPET driver | 440 | 228 = /dev/hpet HPET driver |
436 | 229 = /dev/fuse Fuse (virtual filesystem in user-space) | 441 | 229 = /dev/fuse Fuse (virtual filesystem in user-space) |
437 | 230 = /dev/midishare MidiShare driver | 442 | 230 = /dev/midishare MidiShare driver |
443 | 231 = /dev/snapshot System memory snapshot device | ||
444 | 232 = /dev/kvm Kernel-based virtual machine (hardware virtualization extensions) | ||
445 | 233 = /dev/kmview View-OS A process with a view | ||
438 | 240-254 Reserved for local use | 446 | 240-254 Reserved for local use |
439 | 255 Reserved for MISC_DYNAMIC_MINOR | 447 | 255 Reserved for MISC_DYNAMIC_MINOR |
440 | 448 | ||
@@ -466,10 +474,7 @@ Your cooperation is appreciated. | |||
466 | The device names specified are proposed -- if there | 474 | The device names specified are proposed -- if there |
467 | are "standard" names for these devices, please let me know. | 475 | are "standard" names for these devices, please let me know. |
468 | 476 | ||
469 | 12 block MSCDEX CD-ROM callback support {2.6} | 477 | 12 block |
470 | 0 = /dev/dos_cd0 First MSCDEX CD-ROM | ||
471 | 1 = /dev/dos_cd1 Second MSCDEX CD-ROM | ||
472 | ... | ||
473 | 478 | ||
474 | 13 char Input core | 479 | 13 char Input core |
475 | 0 = /dev/input/js0 First joystick | 480 | 0 = /dev/input/js0 First joystick |
@@ -498,7 +503,7 @@ Your cooperation is appreciated. | |||
498 | 2 = /dev/midi00 First MIDI port | 503 | 2 = /dev/midi00 First MIDI port |
499 | 3 = /dev/dsp Digital audio | 504 | 3 = /dev/dsp Digital audio |
500 | 4 = /dev/audio Sun-compatible digital audio | 505 | 4 = /dev/audio Sun-compatible digital audio |
501 | 6 = /dev/sndstat Sound card status information {2.6} | 506 | 6 = |
502 | 7 = /dev/audioctl SPARC audio control device | 507 | 7 = /dev/audioctl SPARC audio control device |
503 | 8 = /dev/sequencer2 Sequencer -- alternate device | 508 | 8 = /dev/sequencer2 Sequencer -- alternate device |
504 | 16 = /dev/mixer1 Second soundcard mixer control | 509 | 16 = /dev/mixer1 Second soundcard mixer control |
@@ -510,14 +515,7 @@ Your cooperation is appreciated. | |||
510 | 34 = /dev/midi02 Third MIDI port | 515 | 34 = /dev/midi02 Third MIDI port |
511 | 50 = /dev/midi03 Fourth MIDI port | 516 | 50 = /dev/midi03 Fourth MIDI port |
512 | 517 | ||
513 | 14 block BIOS harddrive callback support {2.6} | 518 | 14 block |
514 | 0 = /dev/dos_hda First BIOS harddrive whole disk | ||
515 | 64 = /dev/dos_hdb Second BIOS harddrive whole disk | ||
516 | 128 = /dev/dos_hdc Third BIOS harddrive whole disk | ||
517 | 192 = /dev/dos_hdd Fourth BIOS harddrive whole disk | ||
518 | |||
519 | Partitions are handled in the same way as IDE disks | ||
520 | (see major number 3). | ||
521 | 519 | ||
522 | 15 char Joystick | 520 | 15 char Joystick |
523 | 0 = /dev/js0 First analog joystick | 521 | 0 = /dev/js0 First analog joystick |
@@ -535,14 +533,14 @@ Your cooperation is appreciated. | |||
535 | 16 block GoldStar CD-ROM | 533 | 16 block GoldStar CD-ROM |
536 | 0 = /dev/gscd GoldStar CD-ROM | 534 | 0 = /dev/gscd GoldStar CD-ROM |
537 | 535 | ||
538 | 17 char Chase serial card | 536 | 17 char OBSOLETE (was Chase serial card) |
539 | 0 = /dev/ttyH0 First Chase port | 537 | 0 = /dev/ttyH0 First Chase port |
540 | 1 = /dev/ttyH1 Second Chase port | 538 | 1 = /dev/ttyH1 Second Chase port |
541 | ... | 539 | ... |
542 | 17 block Optics Storage CD-ROM | 540 | 17 block Optics Storage CD-ROM |
543 | 0 = /dev/optcd Optics Storage CD-ROM | 541 | 0 = /dev/optcd Optics Storage CD-ROM |
544 | 542 | ||
545 | 18 char Chase serial card - alternate devices | 543 | 18 char OBSOLETE (was Chase serial card - alternate devices) |
546 | 0 = /dev/cuh0 Callout device for ttyH0 | 544 | 0 = /dev/cuh0 Callout device for ttyH0 |
547 | 1 = /dev/cuh1 Callout device for ttyH1 | 545 | 1 = /dev/cuh1 Callout device for ttyH1 |
548 | ... | 546 | ... |
@@ -644,8 +642,7 @@ Your cooperation is appreciated. | |||
644 | 2 = /dev/sbpcd2 Panasonic CD-ROM controller 0 unit 2 | 642 | 2 = /dev/sbpcd2 Panasonic CD-ROM controller 0 unit 2 |
645 | 3 = /dev/sbpcd3 Panasonic CD-ROM controller 0 unit 3 | 643 | 3 = /dev/sbpcd3 Panasonic CD-ROM controller 0 unit 3 |
646 | 644 | ||
647 | 26 char Quanta WinVision frame grabber {2.6} | 645 | 26 char |
648 | 0 = /dev/wvisfgrab Quanta WinVision frame grabber | ||
649 | 646 | ||
650 | 26 block Second Matsushita (Panasonic/SoundBlaster) CD-ROM | 647 | 26 block Second Matsushita (Panasonic/SoundBlaster) CD-ROM |
651 | 0 = /dev/sbpcd4 Panasonic CD-ROM controller 1 unit 0 | 648 | 0 = /dev/sbpcd4 Panasonic CD-ROM controller 1 unit 0 |
@@ -872,7 +869,7 @@ Your cooperation is appreciated. | |||
872 | and "user level packet I/O." This board is also | 869 | and "user level packet I/O." This board is also |
873 | accessible as a standard networking "eth" device. | 870 | accessible as a standard networking "eth" device. |
874 | 871 | ||
875 | 38 block Reserved for Linux/AP+ | 872 | 38 block OBSOLETE (was Linux/AP+) |
876 | 873 | ||
877 | 39 char ML-16P experimental I/O board | 874 | 39 char ML-16P experimental I/O board |
878 | 0 = /dev/ml16pa-a0 First card, first analog channel | 875 | 0 = /dev/ml16pa-a0 First card, first analog channel |
@@ -892,29 +889,16 @@ Your cooperation is appreciated. | |||
892 | 50 = /dev/ml16pb-c1 Second card, second counter/timer | 889 | 50 = /dev/ml16pb-c1 Second card, second counter/timer |
893 | 51 = /dev/ml16pb-c2 Second card, third counter/timer | 890 | 51 = /dev/ml16pb-c2 Second card, third counter/timer |
894 | ... | 891 | ... |
895 | 39 block Reserved for Linux/AP+ | 892 | 39 block |
896 | 893 | ||
897 | 40 char Matrox Meteor frame grabber {2.6} | 894 | 40 char |
898 | 0 = /dev/mmetfgrab Matrox Meteor frame grabber | ||
899 | 895 | ||
900 | 40 block Syquest EZ135 parallel port removable drive | 896 | 40 block |
901 | 0 = /dev/eza Parallel EZ135 drive, whole disk | ||
902 | |||
903 | This device is obsolete and will be removed in a | ||
904 | future version of Linux. It has been replaced with | ||
905 | the parallel port IDE disk driver at major number 45. | ||
906 | Partitions are handled in the same way as IDE disks | ||
907 | (see major number 3). | ||
908 | 897 | ||
909 | 41 char Yet Another Micro Monitor | 898 | 41 char Yet Another Micro Monitor |
910 | 0 = /dev/yamm Yet Another Micro Monitor | 899 | 0 = /dev/yamm Yet Another Micro Monitor |
911 | 900 | ||
912 | 41 block MicroSolutions BackPack parallel port CD-ROM | 901 | 41 block |
913 | 0 = /dev/bpcd BackPack CD-ROM | ||
914 | |||
915 | This device is obsolete and will be removed in a | ||
916 | future version of Linux. It has been replaced with | ||
917 | the parallel port ATAPI CD-ROM driver at major number 46. | ||
918 | 902 | ||
919 | 42 char Demo/sample use | 903 | 42 char Demo/sample use |
920 | 904 | ||
@@ -1681,13 +1665,7 @@ Your cooperation is appreciated. | |||
1681 | disks (see major number 3) except that the limit on | 1665 | disks (see major number 3) except that the limit on |
1682 | partitions is 15. | 1666 | partitions is 15. |
1683 | 1667 | ||
1684 | 93 char IBM Smart Capture Card frame grabber {2.6} | 1668 | 93 char |
1685 | 0 = /dev/iscc0 First Smart Capture Card | ||
1686 | 1 = /dev/iscc1 Second Smart Capture Card | ||
1687 | ... | ||
1688 | 128 = /dev/isccctl0 First Smart Capture Card control | ||
1689 | 129 = /dev/isccctl1 Second Smart Capture Card control | ||
1690 | ... | ||
1691 | 1669 | ||
1692 | 93 block NAND Flash Translation Layer filesystem | 1670 | 93 block NAND Flash Translation Layer filesystem |
1693 | 0 = /dev/nftla First NFTL layer | 1671 | 0 = /dev/nftla First NFTL layer |
@@ -1695,10 +1673,7 @@ Your cooperation is appreciated. | |||
1695 | ... | 1673 | ... |
1696 | 240 = /dev/nftlp 16th NTFL layer | 1674 | 240 = /dev/nftlp 16th NTFL layer |
1697 | 1675 | ||
1698 | 94 char miroVIDEO DC10/30 capture/playback device {2.6} | 1676 | 94 char |
1699 | 0 = /dev/dcxx0 First capture card | ||
1700 | 1 = /dev/dcxx1 Second capture card | ||
1701 | ... | ||
1702 | 1677 | ||
1703 | 94 block IBM S/390 DASD block storage | 1678 | 94 block IBM S/390 DASD block storage |
1704 | 0 = /dev/dasda First DASD device, major | 1679 | 0 = /dev/dasda First DASD device, major |
@@ -1791,11 +1766,7 @@ Your cooperation is appreciated. | |||
1791 | ... | 1766 | ... |
1792 | 15 = /dev/amiraid/ar?p15 15th partition | 1767 | 15 = /dev/amiraid/ar?p15 15th partition |
1793 | 1768 | ||
1794 | 102 char Philips SAA5249 Teletext signal decoder {2.6} | 1769 | 102 char |
1795 | 0 = /dev/tlk0 First Teletext decoder | ||
1796 | 1 = /dev/tlk1 Second Teletext decoder | ||
1797 | 2 = /dev/tlk2 Third Teletext decoder | ||
1798 | 3 = /dev/tlk3 Fourth Teletext decoder | ||
1799 | 1770 | ||
1800 | 102 block Compressed block device | 1771 | 102 block Compressed block device |
1801 | 0 = /dev/cbd/a First compressed block device, whole device | 1772 | 0 = /dev/cbd/a First compressed block device, whole device |
@@ -1916,10 +1887,7 @@ Your cooperation is appreciated. | |||
1916 | DAC960 (see major number 48) except that the limit on | 1887 | DAC960 (see major number 48) except that the limit on |
1917 | partitions is 15. | 1888 | partitions is 15. |
1918 | 1889 | ||
1919 | 111 char Philips SAA7146-based audio/video card {2.6} | 1890 | 111 char |
1920 | 0 = /dev/av0 First A/V card | ||
1921 | 1 = /dev/av1 Second A/V card | ||
1922 | ... | ||
1923 | 1891 | ||
1924 | 111 block Compaq Next Generation Drive Array, eighth controller | 1892 | 111 block Compaq Next Generation Drive Array, eighth controller |
1925 | 0 = /dev/cciss/c7d0 First logical drive, whole disk | 1893 | 0 = /dev/cciss/c7d0 First logical drive, whole disk |
@@ -2079,8 +2047,8 @@ Your cooperation is appreciated. | |||
2079 | ... | 2047 | ... |
2080 | 2048 | ||
2081 | 119 char VMware virtual network control | 2049 | 119 char VMware virtual network control |
2082 | 0 = /dev/vmnet0 1st virtual network | 2050 | 0 = /dev/vnet0 1st virtual network |
2083 | 1 = /dev/vmnet1 2nd virtual network | 2051 | 1 = /dev/vnet1 2nd virtual network |
2084 | ... | 2052 | ... |
2085 | 2053 | ||
2086 | 120-127 char LOCAL/EXPERIMENTAL USE | 2054 | 120-127 char LOCAL/EXPERIMENTAL USE |
@@ -2450,7 +2418,7 @@ Your cooperation is appreciated. | |||
2450 | 2 = /dev/raw/raw2 Second raw I/O device | 2418 | 2 = /dev/raw/raw2 Second raw I/O device |
2451 | ... | 2419 | ... |
2452 | 2420 | ||
2453 | 163 char UNASSIGNED (was Radio Tech BIM-XXX-RS232 radio modem - see 51) | 2421 | 163 char |
2454 | 2422 | ||
2455 | 164 char Chase Research AT/PCI-Fast serial card | 2423 | 164 char Chase Research AT/PCI-Fast serial card |
2456 | 0 = /dev/ttyCH0 AT/PCI-Fast board 0, port 0 | 2424 | 0 = /dev/ttyCH0 AT/PCI-Fast board 0, port 0 |
@@ -2542,6 +2510,12 @@ Your cooperation is appreciated. | |||
2542 | 1 = /dev/clanvi1 Second cLAN adapter | 2510 | 1 = /dev/clanvi1 Second cLAN adapter |
2543 | ... | 2511 | ... |
2544 | 2512 | ||
2513 | 179 block MMC block devices | ||
2514 | 0 = /dev/mmcblk0 First SD/MMC card | ||
2515 | 1 = /dev/mmcblk0p1 First partition on first MMC card | ||
2516 | 8 = /dev/mmcblk1 Second SD/MMC card | ||
2517 | ... | ||
2518 | |||
2545 | 179 char CCube DVXChip-based PCI products | 2519 | 179 char CCube DVXChip-based PCI products |
2546 | 0 = /dev/dvxirq0 First DVX device | 2520 | 0 = /dev/dvxirq0 First DVX device |
2547 | 1 = /dev/dvxirq1 Second DVX device | 2521 | 1 = /dev/dvxirq1 Second DVX device |
@@ -2560,6 +2534,9 @@ Your cooperation is appreciated. | |||
2560 | 96 = /dev/usb/hiddev0 1st USB HID device | 2534 | 96 = /dev/usb/hiddev0 1st USB HID device |
2561 | ... | 2535 | ... |
2562 | 111 = /dev/usb/hiddev15 16th USB HID device | 2536 | 111 = /dev/usb/hiddev15 16th USB HID device |
2537 | 112 = /dev/usb/auer0 1st auerswald ISDN device | ||
2538 | ... | ||
2539 | 127 = /dev/usb/auer15 16th auerswald ISDN device | ||
2563 | 128 = /dev/usb/brlvgr0 First Braille Voyager device | 2540 | 128 = /dev/usb/brlvgr0 First Braille Voyager device |
2564 | ... | 2541 | ... |
2565 | 131 = /dev/usb/brlvgr3 Fourth Braille Voyager device | 2542 | 131 = /dev/usb/brlvgr3 Fourth Braille Voyager device |
@@ -2810,6 +2787,20 @@ Your cooperation is appreciated. | |||
2810 | ... | 2787 | ... |
2811 | 190 = /dev/ttyUL3 Xilinx uartlite - port 3 | 2788 | 190 = /dev/ttyUL3 Xilinx uartlite - port 3 |
2812 | 191 = /dev/xvc0 Xen virtual console - port 0 | 2789 | 191 = /dev/xvc0 Xen virtual console - port 0 |
2790 | 192 = /dev/ttyPZ0 pmac_zilog - port 0 | ||
2791 | ... | ||
2792 | 195 = /dev/ttyPZ3 pmac_zilog - port 3 | ||
2793 | 196 = /dev/ttyTX0 TX39/49 serial port 0 | ||
2794 | ... | ||
2795 | 204 = /dev/ttyTX7 TX39/49 serial port 7 | ||
2796 | 205 = /dev/ttySC0 SC26xx serial port 0 | ||
2797 | 206 = /dev/ttySC1 SC26xx serial port 1 | ||
2798 | 207 = /dev/ttySC2 SC26xx serial port 2 | ||
2799 | 208 = /dev/ttySC3 SC26xx serial port 3 | ||
2800 | 209 = /dev/ttyMAX0 MAX3100 serial port 0 | ||
2801 | 210 = /dev/ttyMAX1 MAX3100 serial port 1 | ||
2802 | 211 = /dev/ttyMAX2 MAX3100 serial port 2 | ||
2803 | 212 = /dev/ttyMAX3 MAX3100 serial port 3 | ||
2813 | 2804 | ||
2814 | 205 char Low-density serial ports (alternate device) | 2805 | 205 char Low-density serial ports (alternate device) |
2815 | 0 = /dev/culu0 Callout device for ttyLU0 | 2806 | 0 = /dev/culu0 Callout device for ttyLU0 |
@@ -3145,6 +3136,20 @@ Your cooperation is appreciated. | |||
3145 | 1 = /dev/blockrom1 Second ROM card's translation layer interface | 3136 | 1 = /dev/blockrom1 Second ROM card's translation layer interface |
3146 | ... | 3137 | ... |
3147 | 3138 | ||
3139 | 259 block Block Extended Major | ||
3140 | Used dynamically to hold additional partition minor | ||
3141 | numbers and allow large numbers of partitions per device | ||
3142 | |||
3143 | 259 char FPGA configuration interfaces | ||
3144 | 0 = /dev/icap0 First Xilinx internal configuration | ||
3145 | 1 = /dev/icap1 Second Xilinx internal configuration | ||
3146 | |||
3147 | 260 char OSD (Object-based-device) SCSI Device | ||
3148 | 0 = /dev/osd0 First OSD Device | ||
3149 | 1 = /dev/osd1 Second OSD Device | ||
3150 | ... | ||
3151 | 255 = /dev/osd255 256th OSD Device | ||
3152 | |||
3148 | **** ADDITIONAL /dev DIRECTORY ENTRIES | 3153 | **** ADDITIONAL /dev DIRECTORY ENTRIES |
3149 | 3154 | ||
3150 | This section details additional entries that should or may exist in | 3155 | This section details additional entries that should or may exist in |
diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 1e89a51ea49b..88519daab6e9 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff | |||
@@ -62,7 +62,6 @@ aic7*reg_print.c* | |||
62 | aic7*seq.h* | 62 | aic7*seq.h* |
63 | aicasm | 63 | aicasm |
64 | aicdb.h* | 64 | aicdb.h* |
65 | asm | ||
66 | asm-offsets.h | 65 | asm-offsets.h |
67 | asm_offsets.h | 66 | asm_offsets.h |
68 | autoconf.h* | 67 | autoconf.h* |
diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt index a05ec50f8004..a7cbfff40d07 100644 --- a/Documentation/driver-model/device.txt +++ b/Documentation/driver-model/device.txt | |||
@@ -127,9 +127,11 @@ void unlock_device(struct device * dev); | |||
127 | Attributes | 127 | Attributes |
128 | ~~~~~~~~~~ | 128 | ~~~~~~~~~~ |
129 | struct device_attribute { | 129 | struct device_attribute { |
130 | struct attribute attr; | 130 | struct attribute attr; |
131 | ssize_t (*show)(struct device * dev, char * buf, size_t count, loff_t off); | 131 | ssize_t (*show)(struct device *dev, struct device_attribute *attr, |
132 | ssize_t (*store)(struct device * dev, const char * buf, size_t count, loff_t off); | 132 | char *buf); |
133 | ssize_t (*store)(struct device *dev, struct device_attribute *attr, | ||
134 | const char *buf, size_t count); | ||
133 | }; | 135 | }; |
134 | 136 | ||
135 | Attributes of devices can be exported via drivers using a simple | 137 | Attributes of devices can be exported via drivers using a simple |
diff --git a/Documentation/dvb/README.flexcop b/Documentation/dvb/README.flexcop deleted file mode 100644 index 5515469de7cf..000000000000 --- a/Documentation/dvb/README.flexcop +++ /dev/null | |||
@@ -1,205 +0,0 @@ | |||
1 | This README escorted the skystar2-driver rewriting procedure. It describes the | ||
2 | state of the new flexcop-driver set and some internals are written down here | ||
3 | too. | ||
4 | |||
5 | This document hopefully describes things about the flexcop and its | ||
6 | device-offsprings. Goal was to write an easy-to-write and easy-to-read set of | ||
7 | drivers based on the skystar2.c and other information. | ||
8 | |||
9 | Remark: flexcop-pci.c was a copy of skystar2.c, but every line has been | ||
10 | touched and rewritten. | ||
11 | |||
12 | History & News | ||
13 | ============== | ||
14 | 2005-04-01 - correct USB ISOC transfers (thanks to Vadim Catana) | ||
15 | |||
16 | |||
17 | |||
18 | |||
19 | General coding processing | ||
20 | ========================= | ||
21 | |||
22 | We should proceed as follows (as long as no one complains): | ||
23 | |||
24 | 0) Think before start writing code! | ||
25 | |||
26 | 1) rewriting the skystar2.c with the help of the flexcop register descriptions | ||
27 | and splitting up the files to a pci-bus-part and a flexcop-part. | ||
28 | The new driver will be called b2c2-flexcop-pci.ko/b2c2-flexcop-usb.ko for the | ||
29 | device-specific part and b2c2-flexcop.ko for the common flexcop-functions. | ||
30 | |||
31 | 2) Search for errors in the leftover of flexcop-pci.c (compare with pluto2.c | ||
32 | and other pci drivers) | ||
33 | |||
34 | 3) make some beautification (see 'Improvements when rewriting (refactoring) is | ||
35 | done') | ||
36 | |||
37 | 4) Testing the new driver and maybe substitute the skystar2.c with it, to reach | ||
38 | a wider tester audience. | ||
39 | |||
40 | 5) creating an usb-bus-part using the already written flexcop code for the pci | ||
41 | card. | ||
42 | |||
43 | Idea: create a kernel-object for the flexcop and export all important | ||
44 | functions. This option saves kernel-memory, but maybe a lot of functions have | ||
45 | to be exported to kernel namespace. | ||
46 | |||
47 | |||
48 | Current situation | ||
49 | ================= | ||
50 | |||
51 | 0) Done :) | ||
52 | 1) Done (some minor issues left) | ||
53 | 2) Done | ||
54 | 3) Not ready yet, more information is necessary | ||
55 | 4) next to be done (see the table below) | ||
56 | 5) USB driver is working (yes, there are some minor issues) | ||
57 | |||
58 | What seems to be ready? | ||
59 | ----------------------- | ||
60 | |||
61 | 1) Rewriting | ||
62 | 1a) i2c is cut off from the flexcop-pci.c and seems to work | ||
63 | 1b) moved tuner and demod stuff from flexcop-pci.c to flexcop-tuner-fe.c | ||
64 | 1c) moved lnb and diseqc stuff from flexcop-pci.c to flexcop-tuner-fe.c | ||
65 | 1e) eeprom (reading MAC address) | ||
66 | 1d) sram (no dynamic sll size detection (commented out) (using default as JJ told me)) | ||
67 | 1f) misc. register accesses for reading parameters (e.g. resetting, revision) | ||
68 | 1g) pid/mac filter (flexcop-hw-filter.c) | ||
69 | 1i) dvb-stuff initialization in flexcop.c (done) | ||
70 | 1h) dma stuff (now just using the size-irq, instead of all-together, to be done) | ||
71 | 1j) remove flexcop initialization from flexcop-pci.c completely (done) | ||
72 | 1l) use a well working dma IRQ method (done, see 'Known bugs and problems and TODO') | ||
73 | 1k) cleanup flexcop-files (remove unused EXPORT_SYMBOLs, make static from | ||
74 | non-static where possible, moved code to proper places) | ||
75 | |||
76 | 2) Search for errors in the leftover of flexcop-pci.c (partially done) | ||
77 | 5a) add MAC address reading | ||
78 | 5c) feeding of ISOC data to the software demux (format of the isochronous data | ||
79 | and speed optimization, no real error) (thanks to Vadim Catana) | ||
80 | |||
81 | What to do in the near future? | ||
82 | -------------------------------------- | ||
83 | (no special order here) | ||
84 | |||
85 | 5) USB driver | ||
86 | 5b) optimize isoc-transfer (submitting/killing isoc URBs when transfer is starting) | ||
87 | |||
88 | Testing changes | ||
89 | --------------- | ||
90 | |||
91 | O = item is working | ||
92 | P = item is partially working | ||
93 | X = item is not working | ||
94 | N = item does not apply here | ||
95 | <empty field> = item need to be examined | ||
96 | |||
97 | | PCI | USB | ||
98 | item | mt352 | nxt2002 | stv0299 | mt312 | mt352 | nxt2002 | stv0299 | mt312 | ||
99 | -------+-------+---------+---------+-------+-------+---------+---------+------- | ||
100 | 1a) | O | | | | N | N | N | N | ||
101 | 1b) | O | | | | | | O | | ||
102 | 1c) | N | N | | | N | N | O | | ||
103 | 1d) | O | O | ||
104 | 1e) | O | O | ||
105 | 1f) | P | ||
106 | 1g) | O | ||
107 | 1h) | P | | ||
108 | 1i) | O | N | ||
109 | 1j) | O | N | ||
110 | 1l) | O | N | ||
111 | 2) | O | N | ||
112 | 5a) | N | O | ||
113 | 5b)* | N | | ||
114 | 5c) | N | O | ||
115 | |||
116 | * - not done yet | ||
117 | |||
118 | Known bugs and problems and TODO | ||
119 | -------------------------------- | ||
120 | |||
121 | 1g/h/l) when pid filtering is enabled on the pci card | ||
122 | |||
123 | DMA usage currently: | ||
124 | The DMA is splitted in 2 equal-sized subbuffers. The Flexcop writes to first | ||
125 | address and triggers an IRQ when it's full and starts writing to the second | ||
126 | address. When the second address is full, the IRQ is triggered again, and | ||
127 | the flexcop writes to first address again, and so on. | ||
128 | The buffersize of each address is currently 640*188 bytes. | ||
129 | |||
130 | Problem is, when using hw-pid-filtering and doing some low-bandwidth | ||
131 | operation (like scanning) the buffers won't be filled enough to trigger | ||
132 | the IRQ. That's why: | ||
133 | |||
134 | When PID filtering is activated, the timer IRQ is used. Every 1.97 ms the IRQ | ||
135 | is triggered. Is the current write address of DMA1 different to the one | ||
136 | during the last IRQ, then the data is passed to the demuxer. | ||
137 | |||
138 | There is an additional DMA-IRQ-method: packet count IRQ. This isn't | ||
139 | implemented correctly yet. | ||
140 | |||
141 | The solution is to disable HW PID filtering, but I don't know how the DVB | ||
142 | API software demux behaves on slow systems with 45MBit/s TS. | ||
143 | |||
144 | Solved bugs :) | ||
145 | -------------- | ||
146 | 1g) pid-filtering (somehow pid index 4 and 5 (EMM_PID and ECM_PID) aren't | ||
147 | working) | ||
148 | SOLUTION: also index 0 was affected, because net_translation is done for | ||
149 | these indexes by default | ||
150 | |||
151 | 5b) isochronous transfer does only work in the first attempt (for the Sky2PC | ||
152 | USB, Air2PC is working) SOLUTION: the flexcop was going asleep and never really | ||
153 | woke up again (don't know if this need fixes, see | ||
154 | flexcop-fe-tuner.c:flexcop_sleep) | ||
155 | |||
156 | NEWS: when the driver is loaded and unloaded and loaded again (w/o doing | ||
157 | anything in the while the driver is loaded the first time), no transfers take | ||
158 | place anymore. | ||
159 | |||
160 | Improvements when rewriting (refactoring) is done | ||
161 | ================================================= | ||
162 | |||
163 | - split sleeping of the flexcop (misc_204.ACPI3_sig = 1;) from lnb_control | ||
164 | (enable sleeping for other demods than dvb-s) | ||
165 | - add support for CableStar (stv0297 Microtune 203x/ALPS) (almost done, incompatibilities with the Nexus-CA) | ||
166 | |||
167 | Debugging | ||
168 | --------- | ||
169 | - add verbose debugging to skystar2.c (dump the reg_dw_data) and compare it | ||
170 | with this flexcop, this is important, because i2c is now using the | ||
171 | flexcop_ibi_value union from flexcop-reg.h (do you have a better idea for | ||
172 | that, please tell us so). | ||
173 | |||
174 | Everything which is identical in the following table, can be put into a common | ||
175 | flexcop-module. | ||
176 | |||
177 | PCI USB | ||
178 | ------------------------------------------------------------------------------- | ||
179 | Different: | ||
180 | Register access: accessing IO memory USB control message | ||
181 | I2C bus: I2C bus of the FC USB control message | ||
182 | Data transfer: DMA isochronous transfer | ||
183 | EEPROM transfer: through i2c bus not clear yet | ||
184 | |||
185 | Identical: | ||
186 | Streaming: accessing registers | ||
187 | PID Filtering: accessing registers | ||
188 | Sram destinations: accessing registers | ||
189 | Tuner/Demod: I2C bus | ||
190 | DVB-stuff: can be written for common use | ||
191 | |||
192 | Acknowledgements (just for the rewriting part) | ||
193 | ================ | ||
194 | |||
195 | Bjarne Steinsbo thought a lot in the first place of the pci part for this code | ||
196 | sharing idea. | ||
197 | |||
198 | Andreas Oberritter for providing a recent PCI initialization template | ||
199 | (pluto2.c). | ||
200 | |||
201 | Boleslaw Ciesielski for pointing out a problem with firmware loader. | ||
202 | |||
203 | Vadim Catana for correcting the USB transfer. | ||
204 | |||
205 | comments, critics and ideas to linux-dvb@linuxtv.org. | ||
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index f2e908d7f90d..2f21ecd4c205 100644 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware | |||
@@ -25,7 +25,7 @@ use IO::Handle; | |||
25 | "tda10046lifeview", "av7110", "dec2000t", "dec2540t", | 25 | "tda10046lifeview", "av7110", "dec2000t", "dec2540t", |
26 | "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004", | 26 | "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004", |
27 | "or51211", "or51132_qam", "or51132_vsb", "bluebird", | 27 | "or51211", "or51132_qam", "or51132_vsb", "bluebird", |
28 | "opera1"); | 28 | "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2" ); |
29 | 29 | ||
30 | # Check args | 30 | # Check args |
31 | syntax() if (scalar(@ARGV) != 1); | 31 | syntax() if (scalar(@ARGV) != 1); |
@@ -37,8 +37,8 @@ for ($i=0; $i < scalar(@components); $i++) { | |||
37 | $outfile = eval($cid); | 37 | $outfile = eval($cid); |
38 | die $@ if $@; | 38 | die $@ if $@; |
39 | print STDERR <<EOF; | 39 | print STDERR <<EOF; |
40 | Firmware $outfile extracted successfully. | 40 | Firmware(s) $outfile extracted successfully. |
41 | Now copy it to either /usr/lib/hotplug/firmware or /lib/firmware | 41 | Now copy it(they) to either /usr/lib/hotplug/firmware or /lib/firmware |
42 | (depending on configuration of firmware hotplug). | 42 | (depending on configuration of firmware hotplug). |
43 | EOF | 43 | EOF |
44 | exit(0); | 44 | exit(0); |
@@ -345,6 +345,85 @@ sub or51211 { | |||
345 | $fwfile; | 345 | $fwfile; |
346 | } | 346 | } |
347 | 347 | ||
348 | sub cx231xx { | ||
349 | my $fwfile = "v4l-cx231xx-avcore-01.fw"; | ||
350 | my $url = "http://linuxtv.org/downloads/firmware/$fwfile"; | ||
351 | my $hash = "7d3bb956dc9df0eafded2b56ba57cc42"; | ||
352 | |||
353 | checkstandard(); | ||
354 | |||
355 | wgetfile($fwfile, $url); | ||
356 | verify($fwfile, $hash); | ||
357 | |||
358 | $fwfile; | ||
359 | } | ||
360 | |||
361 | sub cx18 { | ||
362 | my $url = "http://linuxtv.org/downloads/firmware/"; | ||
363 | |||
364 | my %files = ( | ||
365 | 'v4l-cx23418-apu.fw' => '588f081b562f5c653a3db1ad8f65939a', | ||
366 | 'v4l-cx23418-cpu.fw' => 'b6c7ed64bc44b1a6e0840adaeac39d79', | ||
367 | 'v4l-cx23418-dig.fw' => '95bc688d3e7599fd5800161e9971cc55', | ||
368 | ); | ||
369 | |||
370 | checkstandard(); | ||
371 | |||
372 | my $allfiles; | ||
373 | foreach my $fwfile (keys %files) { | ||
374 | wgetfile($fwfile, "$url/$fwfile"); | ||
375 | verify($fwfile, $files{$fwfile}); | ||
376 | $allfiles .= " $fwfile"; | ||
377 | } | ||
378 | |||
379 | $allfiles =~ s/^\s//; | ||
380 | |||
381 | $allfiles; | ||
382 | } | ||
383 | |||
384 | sub cx23885 { | ||
385 | my $url = "http://linuxtv.org/downloads/firmware/"; | ||
386 | |||
387 | my %files = ( | ||
388 | 'v4l-cx23885-avcore-01.fw' => 'a9f8f5d901a7fb42f552e1ee6384f3bb', | ||
389 | 'v4l-cx23885-enc.fw' => 'a9f8f5d901a7fb42f552e1ee6384f3bb', | ||
390 | ); | ||
391 | |||
392 | checkstandard(); | ||
393 | |||
394 | my $allfiles; | ||
395 | foreach my $fwfile (keys %files) { | ||
396 | wgetfile($fwfile, "$url/$fwfile"); | ||
397 | verify($fwfile, $files{$fwfile}); | ||
398 | $allfiles .= " $fwfile"; | ||
399 | } | ||
400 | |||
401 | $allfiles =~ s/^\s//; | ||
402 | |||
403 | $allfiles; | ||
404 | } | ||
405 | |||
406 | sub pvrusb2 { | ||
407 | my $url = "http://linuxtv.org/downloads/firmware/"; | ||
408 | |||
409 | my %files = ( | ||
410 | 'v4l-cx25840.fw' => 'dadb79e9904fc8af96e8111d9cb59320', | ||
411 | ); | ||
412 | |||
413 | checkstandard(); | ||
414 | |||
415 | my $allfiles; | ||
416 | foreach my $fwfile (keys %files) { | ||
417 | wgetfile($fwfile, "$url/$fwfile"); | ||
418 | verify($fwfile, $files{$fwfile}); | ||
419 | $allfiles .= " $fwfile"; | ||
420 | } | ||
421 | |||
422 | $allfiles =~ s/^\s//; | ||
423 | |||
424 | $allfiles; | ||
425 | } | ||
426 | |||
348 | sub or51132_qam { | 427 | sub or51132_qam { |
349 | my $fwfile = "dvb-fe-or51132-qam.fw"; | 428 | my $fwfile = "dvb-fe-or51132-qam.fw"; |
350 | my $url = "http://linuxtv.org/downloads/firmware/$fwfile"; | 429 | my $url = "http://linuxtv.org/downloads/firmware/$fwfile"; |
diff --git a/Documentation/dvb/technisat.txt b/Documentation/dvb/technisat.txt index cdf6ee4b2da1..3f435ffb289c 100644 --- a/Documentation/dvb/technisat.txt +++ b/Documentation/dvb/technisat.txt | |||
@@ -1,5 +1,5 @@ | |||
1 | How to set up the Technisat devices | 1 | How to set up the Technisat/B2C2 Flexcop devices |
2 | =================================== | 2 | ================================================ |
3 | 3 | ||
4 | 1) Find out what device you have | 4 | 1) Find out what device you have |
5 | ================================ | 5 | ================================ |
@@ -16,54 +16,60 @@ DVB: registering frontend 0 (Conexant CX24123/CX24109)... | |||
16 | 16 | ||
17 | If the Technisat is the only TV device in your box get rid of unnecessary modules and check this one: | 17 | If the Technisat is the only TV device in your box get rid of unnecessary modules and check this one: |
18 | "Multimedia devices" => "Customise analog and hybrid tuner modules to build" | 18 | "Multimedia devices" => "Customise analog and hybrid tuner modules to build" |
19 | In this directory uncheck every driver which is activated there. | 19 | In this directory uncheck every driver which is activated there (except "Simple tuner support" for case 9 only). |
20 | 20 | ||
21 | Then please activate: | 21 | Then please activate: |
22 | 2a) Main module part: | 22 | 2a) Main module part: |
23 | 23 | ||
24 | a.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" | 24 | a.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" |
25 | b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card OR | 25 | b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card |
26 | OR | ||
26 | c.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC USB" in case of an USB 1.1 adapter | 27 | c.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC USB" in case of an USB 1.1 adapter |
27 | d.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Enable debug for the B2C2 FlexCop drivers" | 28 | d.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Enable debug for the B2C2 FlexCop drivers" |
28 | Notice: d.) is helpful for troubleshooting | 29 | Notice: d.) is helpful for troubleshooting |
29 | 30 | ||
30 | 2b) Frontend module part: | 31 | 2b) Frontend module part: |
31 | 32 | ||
32 | 1.) Revision 2.3: | 33 | 1.) SkyStar DVB-S Revision 2.3: |
33 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" | 34 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" |
34 | b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink VP310/MT312/ZL10313 based" | 35 | b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink VP310/MT312/ZL10313 based" |
35 | 36 | ||
36 | 2.) Revision 2.6: | 37 | 2.) SkyStar DVB-S Revision 2.6: |
37 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" | 38 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" |
38 | b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0299 based" | 39 | b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0299 based" |
39 | 40 | ||
40 | 3.) Revision 2.7: | 41 | 3.) SkyStar DVB-S Revision 2.7: |
41 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" | 42 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" |
42 | b.)"Multimedia devices" => "Customise DVB frontends" => "Samsung S5H1420 based" | 43 | b.)"Multimedia devices" => "Customise DVB frontends" => "Samsung S5H1420 based" |
43 | c.)"Multimedia devices" => "Customise DVB frontends" => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS" | 44 | c.)"Multimedia devices" => "Customise DVB frontends" => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS" |
44 | d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller" | 45 | d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller" |
45 | 46 | ||
46 | 4.) Revision 2.8: | 47 | 4.) SkyStar DVB-S Revision 2.8: |
47 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" | 48 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" |
48 | b.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24113/CX24128 tuner for DVB-S/DSS" | 49 | b.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24113/CX24128 tuner for DVB-S/DSS" |
49 | c.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24123 based" | 50 | c.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24123 based" |
50 | d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller" | 51 | d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller" |
51 | 52 | ||
52 | 5.) DVB-T card: | 53 | 5.) AirStar DVB-T card: |
53 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" | 54 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" |
54 | b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink MT352 based" | 55 | b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink MT352 based" |
55 | 56 | ||
56 | 6.) DVB-C card: | 57 | 6.) CableStar DVB-C card: |
57 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" | 58 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" |
58 | b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0297 based" | 59 | b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0297 based" |
59 | 60 | ||
60 | 7.) ATSC card 1st generation: | 61 | 7.) AirStar ATSC card 1st generation: |
61 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" | 62 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" |
62 | b.)"Multimedia devices" => "Customise DVB frontends" => "Broadcom BCM3510" | 63 | b.)"Multimedia devices" => "Customise DVB frontends" => "Broadcom BCM3510" |
63 | 64 | ||
64 | 8.) ATSC card 2nd generation: | 65 | 8.) AirStar ATSC card 2nd generation: |
65 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" | 66 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" |
66 | b.)"Multimedia devices" => "Customise DVB frontends" => "NxtWave Communications NXT2002/NXT2004 based" | 67 | b.)"Multimedia devices" => "Customise DVB frontends" => "NxtWave Communications NXT2002/NXT2004 based" |
67 | c.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based" | 68 | c.)"Multimedia devices" => "Customise DVB frontends" => "Generic I2C PLL based tuners" |
68 | 69 | ||
69 | Author: Uwe Bugla <uwe.bugla@gmx.de> December 2008 | 70 | 9.) AirStar ATSC card 3rd generation: |
71 | a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" | ||
72 | b.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based" | ||
73 | c.)"Multimedia devices" => "Customise analog and hybrid tuner modules to build" => "Simple tuner support" | ||
74 | |||
75 | Author: Uwe Bugla <uwe.bugla@gmx.de> February 2009 | ||
diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt new file mode 100644 index 000000000000..674c5663d346 --- /dev/null +++ b/Documentation/dynamic-debug-howto.txt | |||
@@ -0,0 +1,240 @@ | |||
1 | |||
2 | Introduction | ||
3 | ============ | ||
4 | |||
5 | This document describes how to use the dynamic debug (ddebug) feature. | ||
6 | |||
7 | Dynamic debug is designed to allow you to dynamically enable/disable kernel | ||
8 | code to obtain additional kernel information. Currently, if | ||
9 | CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_debug() calls can be | ||
10 | dynamically enabled per-callsite. | ||
11 | |||
12 | Dynamic debug has even more useful features: | ||
13 | |||
14 | * Simple query language allows turning on and off debugging statements by | ||
15 | matching any combination of: | ||
16 | |||
17 | - source filename | ||
18 | - function name | ||
19 | - line number (including ranges of line numbers) | ||
20 | - module name | ||
21 | - format string | ||
22 | |||
23 | * Provides a debugfs control file: <debugfs>/dynamic_debug/control which can be | ||
24 | read to display the complete list of known debug statements, to help guide you | ||
25 | |||
26 | Controlling dynamic debug Behaviour | ||
27 | =============================== | ||
28 | |||
29 | The behaviour of pr_debug()/dev_debug()s are controlled via writing to a | ||
30 | control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs | ||
31 | filesystem, in order to make use of this feature. Subsequently, we refer to the | ||
32 | control file as: <debugfs>/dynamic_debug/control. For example, if you want to | ||
33 | enable printing from source file 'svcsock.c', line 1603 you simply do: | ||
34 | |||
35 | nullarbor:~ # echo 'file svcsock.c line 1603 +p' > | ||
36 | <debugfs>/dynamic_debug/control | ||
37 | |||
38 | If you make a mistake with the syntax, the write will fail thus: | ||
39 | |||
40 | nullarbor:~ # echo 'file svcsock.c wtf 1 +p' > | ||
41 | <debugfs>/dynamic_debug/control | ||
42 | -bash: echo: write error: Invalid argument | ||
43 | |||
44 | Viewing Dynamic Debug Behaviour | ||
45 | =========================== | ||
46 | |||
47 | You can view the currently configured behaviour of all the debug statements | ||
48 | via: | ||
49 | |||
50 | nullarbor:~ # cat <debugfs>/dynamic_debug/control | ||
51 | # filename:lineno [module]function flags format | ||
52 | /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup - "SVCRDMA Module Removed, deregister RPC RDMA transport\012" | ||
53 | /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init - "\011max_inline : %d\012" | ||
54 | /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init - "\011sq_depth : %d\012" | ||
55 | /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init - "\011max_requests : %d\012" | ||
56 | ... | ||
57 | |||
58 | |||
59 | You can also apply standard Unix text manipulation filters to this | ||
60 | data, e.g. | ||
61 | |||
62 | nullarbor:~ # grep -i rdma <debugfs>/dynamic_debug/control | wc -l | ||
63 | 62 | ||
64 | |||
65 | nullarbor:~ # grep -i tcp <debugfs>/dynamic_debug/control | wc -l | ||
66 | 42 | ||
67 | |||
68 | Note in particular that the third column shows the enabled behaviour | ||
69 | flags for each debug statement callsite (see below for definitions of the | ||
70 | flags). The default value, no extra behaviour enabled, is "-". So | ||
71 | you can view all the debug statement callsites with any non-default flags: | ||
72 | |||
73 | nullarbor:~ # awk '$3 != "-"' <debugfs>/dynamic_debug/control | ||
74 | # filename:lineno [module]function flags format | ||
75 | /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012" | ||
76 | |||
77 | |||
78 | Command Language Reference | ||
79 | ========================== | ||
80 | |||
81 | At the lexical level, a command comprises a sequence of words separated | ||
82 | by whitespace characters. Note that newlines are treated as word | ||
83 | separators and do *not* end a command or allow multiple commands to | ||
84 | be done together. So these are all equivalent: | ||
85 | |||
86 | nullarbor:~ # echo -c 'file svcsock.c line 1603 +p' > | ||
87 | <debugfs>/dynamic_debug/control | ||
88 | nullarbor:~ # echo -c ' file svcsock.c line 1603 +p ' > | ||
89 | <debugfs>/dynamic_debug/control | ||
90 | nullarbor:~ # echo -c 'file svcsock.c\nline 1603 +p' > | ||
91 | <debugfs>/dynamic_debug/control | ||
92 | nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' > | ||
93 | <debugfs>/dynamic_debug/control | ||
94 | |||
95 | Commands are bounded by a write() system call. If you want to do | ||
96 | multiple commands you need to do a separate "echo" for each, like: | ||
97 | |||
98 | nullarbor:~ # echo 'file svcsock.c line 1603 +p' > /proc/dprintk ;\ | ||
99 | > echo 'file svcsock.c line 1563 +p' > /proc/dprintk | ||
100 | |||
101 | or even like: | ||
102 | |||
103 | nullarbor:~ # ( | ||
104 | > echo 'file svcsock.c line 1603 +p' ;\ | ||
105 | > echo 'file svcsock.c line 1563 +p' ;\ | ||
106 | > ) > /proc/dprintk | ||
107 | |||
108 | At the syntactical level, a command comprises a sequence of match | ||
109 | specifications, followed by a flags change specification. | ||
110 | |||
111 | command ::= match-spec* flags-spec | ||
112 | |||
113 | The match-spec's are used to choose a subset of the known dprintk() | ||
114 | callsites to which to apply the flags-spec. Think of them as a query | ||
115 | with implicit ANDs between each pair. Note that an empty list of | ||
116 | match-specs is possible, but is not very useful because it will not | ||
117 | match any debug statement callsites. | ||
118 | |||
119 | A match specification comprises a keyword, which controls the attribute | ||
120 | of the callsite to be compared, and a value to compare against. Possible | ||
121 | keywords are: | ||
122 | |||
123 | match-spec ::= 'func' string | | ||
124 | 'file' string | | ||
125 | 'module' string | | ||
126 | 'format' string | | ||
127 | 'line' line-range | ||
128 | |||
129 | line-range ::= lineno | | ||
130 | '-'lineno | | ||
131 | lineno'-' | | ||
132 | lineno'-'lineno | ||
133 | // Note: line-range cannot contain space, e.g. | ||
134 | // "1-30" is valid range but "1 - 30" is not. | ||
135 | |||
136 | lineno ::= unsigned-int | ||
137 | |||
138 | The meanings of each keyword are: | ||
139 | |||
140 | func | ||
141 | The given string is compared against the function name | ||
142 | of each callsite. Example: | ||
143 | |||
144 | func svc_tcp_accept | ||
145 | |||
146 | file | ||
147 | The given string is compared against either the full | ||
148 | pathname or the basename of the source file of each | ||
149 | callsite. Examples: | ||
150 | |||
151 | file svcsock.c | ||
152 | file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c | ||
153 | |||
154 | module | ||
155 | The given string is compared against the module name | ||
156 | of each callsite. The module name is the string as | ||
157 | seen in "lsmod", i.e. without the directory or the .ko | ||
158 | suffix and with '-' changed to '_'. Examples: | ||
159 | |||
160 | module sunrpc | ||
161 | module nfsd | ||
162 | |||
163 | format | ||
164 | The given string is searched for in the dynamic debug format | ||
165 | string. Note that the string does not need to match the | ||
166 | entire format, only some part. Whitespace and other | ||
167 | special characters can be escaped using C octal character | ||
168 | escape \ooo notation, e.g. the space character is \040. | ||
169 | Alternatively, the string can be enclosed in double quote | ||
170 | characters (") or single quote characters ('). | ||
171 | Examples: | ||
172 | |||
173 | format svcrdma: // many of the NFS/RDMA server dprintks | ||
174 | format readahead // some dprintks in the readahead cache | ||
175 | format nfsd:\040SETATTR // one way to match a format with whitespace | ||
176 | format "nfsd: SETATTR" // a neater way to match a format with whitespace | ||
177 | format 'nfsd: SETATTR' // yet another way to match a format with whitespace | ||
178 | |||
179 | line | ||
180 | The given line number or range of line numbers is compared | ||
181 | against the line number of each dprintk() callsite. A single | ||
182 | line number matches the callsite line number exactly. A | ||
183 | range of line numbers matches any callsite between the first | ||
184 | and last line number inclusive. An empty first number means | ||
185 | the first line in the file, an empty line number means the | ||
186 | last number in the file. Examples: | ||
187 | |||
188 | line 1603 // exactly line 1603 | ||
189 | line 1600-1605 // the six lines from line 1600 to line 1605 | ||
190 | line -1605 // the 1605 lines from line 1 to line 1605 | ||
191 | line 1600- // all lines from line 1600 to the end of the file | ||
192 | |||
193 | The flags specification comprises a change operation followed | ||
194 | by one or more flag characters. The change operation is one | ||
195 | of the characters: | ||
196 | |||
197 | - | ||
198 | remove the given flags | ||
199 | |||
200 | + | ||
201 | add the given flags | ||
202 | |||
203 | = | ||
204 | set the flags to the given flags | ||
205 | |||
206 | The flags are: | ||
207 | |||
208 | p | ||
209 | Causes a printk() message to be emitted to dmesg | ||
210 | |||
211 | Note the regexp ^[-+=][scp]+$ matches a flags specification. | ||
212 | Note also that there is no convenient syntax to remove all | ||
213 | the flags at once, you need to use "-psc". | ||
214 | |||
215 | Examples | ||
216 | ======== | ||
217 | |||
218 | // enable the message at line 1603 of file svcsock.c | ||
219 | nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' > | ||
220 | <debugfs>/dynamic_debug/control | ||
221 | |||
222 | // enable all the messages in file svcsock.c | ||
223 | nullarbor:~ # echo -n 'file svcsock.c +p' > | ||
224 | <debugfs>/dynamic_debug/control | ||
225 | |||
226 | // enable all the messages in the NFS server module | ||
227 | nullarbor:~ # echo -n 'module nfsd +p' > | ||
228 | <debugfs>/dynamic_debug/control | ||
229 | |||
230 | // enable all 12 messages in the function svc_process() | ||
231 | nullarbor:~ # echo -n 'func svc_process +p' > | ||
232 | <debugfs>/dynamic_debug/control | ||
233 | |||
234 | // disable all 12 messages in the function svc_process() | ||
235 | nullarbor:~ # echo -n 'func svc_process -p' > | ||
236 | <debugfs>/dynamic_debug/control | ||
237 | |||
238 | // enable messages for NFS calls READ, READLINK, READDIR and READDIR+. | ||
239 | nullarbor:~ # echo -n 'format "nfsd: READ" +p' > | ||
240 | <debugfs>/dynamic_debug/control | ||
diff --git a/Documentation/fb/00-INDEX b/Documentation/fb/00-INDEX index caabbd395e61..a618fd99c9f0 100644 --- a/Documentation/fb/00-INDEX +++ b/Documentation/fb/00-INDEX | |||
@@ -11,8 +11,6 @@ aty128fb.txt | |||
11 | - info on the ATI Rage128 frame buffer driver. | 11 | - info on the ATI Rage128 frame buffer driver. |
12 | cirrusfb.txt | 12 | cirrusfb.txt |
13 | - info on the driver for Cirrus Logic chipsets. | 13 | - info on the driver for Cirrus Logic chipsets. |
14 | cyblafb/ | ||
15 | - directory with documentation files related to the cyblafb driver. | ||
16 | deferred_io.txt | 14 | deferred_io.txt |
17 | - an introduction to deferred IO. | 15 | - an introduction to deferred IO. |
18 | fbcon.txt | 16 | fbcon.txt |
diff --git a/Documentation/fb/cyblafb/bugs b/Documentation/fb/cyblafb/bugs deleted file mode 100644 index 9443a6d72cdd..000000000000 --- a/Documentation/fb/cyblafb/bugs +++ /dev/null | |||
@@ -1,13 +0,0 @@ | |||
1 | Bugs | ||
2 | ==== | ||
3 | |||
4 | I currently don't know of any bug. Please do send reports to: | ||
5 | - linux-fbdev-devel@lists.sourceforge.net | ||
6 | - Knut_Petersen@t-online.de. | ||
7 | |||
8 | |||
9 | Untested features | ||
10 | ================= | ||
11 | |||
12 | All LCD stuff is untested. If it worked in tridentfb, it should work in | ||
13 | cyblafb. Please test and report the results to Knut_Petersen@t-online.de. | ||
diff --git a/Documentation/fb/cyblafb/credits b/Documentation/fb/cyblafb/credits deleted file mode 100644 index 0eb3b443dc2b..000000000000 --- a/Documentation/fb/cyblafb/credits +++ /dev/null | |||
@@ -1,7 +0,0 @@ | |||
1 | Thanks to | ||
2 | ========= | ||
3 | * Alan Hourihane, for writing the X trident driver | ||
4 | * Jani Monoses, for writing the tridentfb driver | ||
5 | * Antonino A. Daplas, for review of the first published | ||
6 | version of cyblafb and some code | ||
7 | * Jochen Hein, for testing and a helpfull bug report | ||
diff --git a/Documentation/fb/cyblafb/documentation b/Documentation/fb/cyblafb/documentation deleted file mode 100644 index bb1aac048425..000000000000 --- a/Documentation/fb/cyblafb/documentation +++ /dev/null | |||
@@ -1,17 +0,0 @@ | |||
1 | Available Documentation | ||
2 | ======================= | ||
3 | |||
4 | Apollo PLE 133 Chipset VT8601A North Bridge Datasheet, Rev. 1.82, October 22, | ||
5 | 2001, available from VIA: | ||
6 | |||
7 | http://www.viavpsd.com/product/6/15/DS8601A182.pdf | ||
8 | |||
9 | The datasheet is incomplete, some registers that need to be programmed are not | ||
10 | explained at all and important bits are listed as "reserved". But you really | ||
11 | need the datasheet to understand the code. "p. xxx" comments refer to page | ||
12 | numbers of this document. | ||
13 | |||
14 | XFree/XOrg drivers are available and of good quality, looking at the code | ||
15 | there is a good idea if the datasheet does not provide enough information | ||
16 | or if the datasheet seems to be wrong. | ||
17 | |||
diff --git a/Documentation/fb/cyblafb/fb.modes b/Documentation/fb/cyblafb/fb.modes deleted file mode 100644 index fe0e5223ba86..000000000000 --- a/Documentation/fb/cyblafb/fb.modes +++ /dev/null | |||
@@ -1,154 +0,0 @@ | |||
1 | # | ||
2 | # Sample fb.modes file | ||
3 | # | ||
4 | # Provides an incomplete list of working modes for | ||
5 | # the cyberblade/i1 graphics core. | ||
6 | # | ||
7 | # The value 4294967256 is used instead of -40. Of course, -40 is not | ||
8 | # a really reasonable value, but chip design does not always follow | ||
9 | # logic. Believe me, it's ok, and it's the way the BIOS does it. | ||
10 | # | ||
11 | # fbset requires 4294967256 in fb.modes and -40 as an argument to | ||
12 | # the -t parameter. That's also not too reasonable, and it might change | ||
13 | # in the future or might even be differt for your current version. | ||
14 | # | ||
15 | |||
16 | mode "640x480-50" | ||
17 | geometry 640 480 2048 4096 8 | ||
18 | timings 47619 4294967256 24 17 0 216 3 | ||
19 | endmode | ||
20 | |||
21 | mode "640x480-60" | ||
22 | geometry 640 480 2048 4096 8 | ||
23 | timings 39682 4294967256 24 17 0 216 3 | ||
24 | endmode | ||
25 | |||
26 | mode "640x480-70" | ||
27 | geometry 640 480 2048 4096 8 | ||
28 | timings 34013 4294967256 24 17 0 216 3 | ||
29 | endmode | ||
30 | |||
31 | mode "640x480-72" | ||
32 | geometry 640 480 2048 4096 8 | ||
33 | timings 33068 4294967256 24 17 0 216 3 | ||
34 | endmode | ||
35 | |||
36 | mode "640x480-75" | ||
37 | geometry 640 480 2048 4096 8 | ||
38 | timings 31746 4294967256 24 17 0 216 3 | ||
39 | endmode | ||
40 | |||
41 | mode "640x480-80" | ||
42 | geometry 640 480 2048 4096 8 | ||
43 | timings 29761 4294967256 24 17 0 216 3 | ||
44 | endmode | ||
45 | |||
46 | mode "640x480-85" | ||
47 | geometry 640 480 2048 4096 8 | ||
48 | timings 28011 4294967256 24 17 0 216 3 | ||
49 | endmode | ||
50 | |||
51 | mode "800x600-50" | ||
52 | geometry 800 600 2048 4096 8 | ||
53 | timings 30303 96 24 14 0 136 11 | ||
54 | endmode | ||
55 | |||
56 | mode "800x600-60" | ||
57 | geometry 800 600 2048 4096 8 | ||
58 | timings 25252 96 24 14 0 136 11 | ||
59 | endmode | ||
60 | |||
61 | mode "800x600-70" | ||
62 | geometry 800 600 2048 4096 8 | ||
63 | timings 21645 96 24 14 0 136 11 | ||
64 | endmode | ||
65 | |||
66 | mode "800x600-72" | ||
67 | geometry 800 600 2048 4096 8 | ||
68 | timings 21043 96 24 14 0 136 11 | ||
69 | endmode | ||
70 | |||
71 | mode "800x600-75" | ||
72 | geometry 800 600 2048 4096 8 | ||
73 | timings 20202 96 24 14 0 136 11 | ||
74 | endmode | ||
75 | |||
76 | mode "800x600-80" | ||
77 | geometry 800 600 2048 4096 8 | ||
78 | timings 18939 96 24 14 0 136 11 | ||
79 | endmode | ||
80 | |||
81 | mode "800x600-85" | ||
82 | geometry 800 600 2048 4096 8 | ||
83 | timings 17825 96 24 14 0 136 11 | ||
84 | endmode | ||
85 | |||
86 | mode "1024x768-50" | ||
87 | geometry 1024 768 2048 4096 8 | ||
88 | timings 19054 144 24 29 0 120 3 | ||
89 | endmode | ||
90 | |||
91 | mode "1024x768-60" | ||
92 | geometry 1024 768 2048 4096 8 | ||
93 | timings 15880 144 24 29 0 120 3 | ||
94 | endmode | ||
95 | |||
96 | mode "1024x768-70" | ||
97 | geometry 1024 768 2048 4096 8 | ||
98 | timings 13610 144 24 29 0 120 3 | ||
99 | endmode | ||
100 | |||
101 | mode "1024x768-72" | ||
102 | geometry 1024 768 2048 4096 8 | ||
103 | timings 13232 144 24 29 0 120 3 | ||
104 | endmode | ||
105 | |||
106 | mode "1024x768-75" | ||
107 | geometry 1024 768 2048 4096 8 | ||
108 | timings 12703 144 24 29 0 120 3 | ||
109 | endmode | ||
110 | |||
111 | mode "1024x768-80" | ||
112 | geometry 1024 768 2048 4096 8 | ||
113 | timings 11910 144 24 29 0 120 3 | ||
114 | endmode | ||
115 | |||
116 | mode "1024x768-85" | ||
117 | geometry 1024 768 2048 4096 8 | ||
118 | timings 11209 144 24 29 0 120 3 | ||
119 | endmode | ||
120 | |||
121 | mode "1280x1024-50" | ||
122 | geometry 1280 1024 2048 4096 8 | ||
123 | timings 11114 232 16 39 0 160 3 | ||
124 | endmode | ||
125 | |||
126 | mode "1280x1024-60" | ||
127 | geometry 1280 1024 2048 4096 8 | ||
128 | timings 9262 232 16 39 0 160 3 | ||
129 | endmode | ||
130 | |||
131 | mode "1280x1024-70" | ||
132 | geometry 1280 1024 2048 4096 8 | ||
133 | timings 7939 232 16 39 0 160 3 | ||
134 | endmode | ||
135 | |||
136 | mode "1280x1024-72" | ||
137 | geometry 1280 1024 2048 4096 8 | ||
138 | timings 7719 232 16 39 0 160 3 | ||
139 | endmode | ||
140 | |||
141 | mode "1280x1024-75" | ||
142 | geometry 1280 1024 2048 4096 8 | ||
143 | timings 7410 232 16 39 0 160 3 | ||
144 | endmode | ||
145 | |||
146 | mode "1280x1024-80" | ||
147 | geometry 1280 1024 2048 4096 8 | ||
148 | timings 6946 232 16 39 0 160 3 | ||
149 | endmode | ||
150 | |||
151 | mode "1280x1024-85" | ||
152 | geometry 1280 1024 2048 4096 8 | ||
153 | timings 6538 232 16 39 0 160 3 | ||
154 | endmode | ||
diff --git a/Documentation/fb/cyblafb/performance b/Documentation/fb/cyblafb/performance deleted file mode 100644 index 8d15d5dfc6b3..000000000000 --- a/Documentation/fb/cyblafb/performance +++ /dev/null | |||
@@ -1,79 +0,0 @@ | |||
1 | Speed | ||
2 | ===== | ||
3 | |||
4 | CyBlaFB is much faster than tridentfb and vesafb. Compare the performance data | ||
5 | for mode 1280x1024-[8,16,32]@61 Hz. | ||
6 | |||
7 | Test 1: Cat a file with 2000 lines of 0 characters. | ||
8 | Test 2: Cat a file with 2000 lines of 80 characters. | ||
9 | Test 3: Cat a file with 2000 lines of 160 characters. | ||
10 | |||
11 | All values show system time use in seconds, kernel 2.6.12 was used for | ||
12 | the measurements. 2.6.13 is a bit slower, 2.6.14 hopefully will include a | ||
13 | patch that speeds up kernel bitblitting a lot ( > 20%). | ||
14 | |||
15 | +-----------+-----------------------------------------------------+ | ||
16 | | | not accelerated | | ||
17 | | TRIDENTFB +-----------------+-----------------+-----------------+ | ||
18 | | of 2.6.12 | 8 bpp | 16 bpp | 32 bpp | | ||
19 | | | noypan | ypan | noypan | ypan | noypan | ypan | | ||
20 | +-----------+--------+--------+--------+--------+--------+--------+ | ||
21 | | Test 1 | 4.31 | 4.33 | 6.05 | 12.81 | ---- | ---- | | ||
22 | | Test 2 | 67.94 | 5.44 | 123.16 | 14.79 | ---- | ---- | | ||
23 | | Test 3 | 131.36 | 6.55 | 240.12 | 16.76 | ---- | ---- | | ||
24 | +-----------+--------+--------+--------+--------+--------+--------+ | ||
25 | | Comments | | | completely bro- | | ||
26 | | | | | ken, monitor | | ||
27 | | | | | switches off | | ||
28 | +-----------+-----------------+-----------------+-----------------+ | ||
29 | |||
30 | |||
31 | +-----------+-----------------------------------------------------+ | ||
32 | | | accelerated | | ||
33 | | TRIDENTFB +-----------------+-----------------+-----------------+ | ||
34 | | of 2.6.12 | 8 bpp | 16 bpp | 32 bpp | | ||
35 | | | noypan | ypan | noypan | ypan | noypan | ypan | | ||
36 | +-----------+--------+--------+--------+--------+--------+--------+ | ||
37 | | Test 1 | ---- | ---- | 20.62 | 1.22 | ---- | ---- | | ||
38 | | Test 2 | ---- | ---- | 22.61 | 3.19 | ---- | ---- | | ||
39 | | Test 3 | ---- | ---- | 24.59 | 5.16 | ---- | ---- | | ||
40 | +-----------+--------+--------+--------+--------+--------+--------+ | ||
41 | | Comments | broken, writing | broken, ok only | completely bro- | | ||
42 | | | to wrong places | if bgcolor is | ken, monitor | | ||
43 | | | on screen + bug | black, bug in | switches off | | ||
44 | | | in fillrect() | fillrect() | | | ||
45 | +-----------+-----------------+-----------------+-----------------+ | ||
46 | |||
47 | |||
48 | +-----------+-----------------------------------------------------+ | ||
49 | | | not accelerated | | ||
50 | | VESAFB +-----------------+-----------------+-----------------+ | ||
51 | | of 2.6.12 | 8 bpp | 16 bpp | 32 bpp | | ||
52 | | | noypan | ypan | noypan | ypan | noypan | ypan | | ||
53 | +-----------+--------+--------+--------+--------+--------+--------+ | ||
54 | | Test 1 | 4.26 | 3.76 | 5.99 | 7.23 | ---- | ---- | | ||
55 | | Test 2 | 65.65 | 4.89 | 120.88 | 9.08 | ---- | ---- | | ||
56 | | Test 3 | 126.91 | 5.94 | 235.77 | 11.03 | ---- | ---- | | ||
57 | +-----------+--------+--------+--------+--------+--------+--------+ | ||
58 | | Comments | vga=0x307 | vga=0x31a | vga=0x31b not | | ||
59 | | | fh=80kHz | fh=80kHz | supported by | | ||
60 | | | fv=75kHz | fv=75kHz | video BIOS and | | ||
61 | | | | | hardware | | ||
62 | +-----------+-----------------+-----------------+-----------------+ | ||
63 | |||
64 | |||
65 | +-----------+-----------------------------------------------------+ | ||
66 | | | accelerated | | ||
67 | | CYBLAFB +-----------------+-----------------+-----------------+ | ||
68 | | | 8 bpp | 16 bpp | 32 bpp | | ||
69 | | | noypan | ypan | noypan | ypan | noypan | ypan | | ||
70 | +-----------+--------+--------+--------+--------+--------+--------+ | ||
71 | | Test 1 | 8.02 | 0.23 | 19.04 | 0.61 | 57.12 | 2.74 | | ||
72 | | Test 2 | 8.38 | 0.55 | 19.39 | 0.92 | 57.54 | 3.13 | | ||
73 | | Test 3 | 8.73 | 0.86 | 19.74 | 1.24 | 57.95 | 3.51 | | ||
74 | +-----------+--------+--------+--------+--------+--------+--------+ | ||
75 | | Comments | | | | | ||
76 | | | | | | | ||
77 | | | | | | | ||
78 | | | | | | | ||
79 | +-----------+-----------------+-----------------+-----------------+ | ||
diff --git a/Documentation/fb/cyblafb/todo b/Documentation/fb/cyblafb/todo deleted file mode 100644 index c5f6d0eae545..000000000000 --- a/Documentation/fb/cyblafb/todo +++ /dev/null | |||
@@ -1,31 +0,0 @@ | |||
1 | TODO / Missing features | ||
2 | ======================= | ||
3 | |||
4 | Verify LCD stuff "stretch" and "center" options are | ||
5 | completely untested ... this code needs to be | ||
6 | verified. As I don't have access to such | ||
7 | hardware, please contact me if you are | ||
8 | willing run some tests. | ||
9 | |||
10 | Interlaced video modes The reason that interleaved | ||
11 | modes are disabled is that I do not know | ||
12 | the meaning of the vertical interlace | ||
13 | parameter. Also the datasheet mentions a | ||
14 | bit d8 of a horizontal interlace parameter, | ||
15 | but nowhere the lower 8 bits. Please help | ||
16 | if you can. | ||
17 | |||
18 | low-res double scan modes Who needs it? | ||
19 | |||
20 | accelerated color blitting Who needs it? The console driver does use color | ||
21 | blitting for nothing but drawing the penguine, | ||
22 | everything else is done using color expanding | ||
23 | blitting of 1bpp character bitmaps. | ||
24 | |||
25 | ioctls Who needs it? | ||
26 | |||
27 | TV-out Will be done later. Use "vga= " at boot time | ||
28 | to set a suitable video mode. | ||
29 | |||
30 | ??? Feel free to contact me if you have any | ||
31 | feature requests | ||
diff --git a/Documentation/fb/cyblafb/usage b/Documentation/fb/cyblafb/usage deleted file mode 100644 index a39bb3d402a2..000000000000 --- a/Documentation/fb/cyblafb/usage +++ /dev/null | |||
@@ -1,217 +0,0 @@ | |||
1 | CyBlaFB is a framebuffer driver for the Cyberblade/i1 graphics core integrated | ||
2 | into the VIA Apollo PLE133 (aka vt8601) south bridge. It is developed and | ||
3 | tested using a VIA EPIA 5000 board. | ||
4 | |||
5 | Cyblafb - compiled into the kernel or as a module? | ||
6 | ================================================== | ||
7 | |||
8 | You might compile cyblafb either as a module or compile it permanently into the | ||
9 | kernel. | ||
10 | |||
11 | Unless you have a real reason to do so you should not compile both vesafb and | ||
12 | cyblafb permanently into the kernel. It's possible and it helps during the | ||
13 | developement cycle, but it's useless and will at least block some otherwise | ||
14 | usefull memory for ordinary users. | ||
15 | |||
16 | Selecting Modes | ||
17 | =============== | ||
18 | |||
19 | Startup Mode | ||
20 | ============ | ||
21 | |||
22 | First of all, you might use the "vga=???" boot parameter as it is | ||
23 | documented in vesafb.txt and svga.txt. Cyblafb will detect the video | ||
24 | mode selected and will use the geometry and timings found by | ||
25 | inspecting the hardware registers. | ||
26 | |||
27 | video=cyblafb vga=0x317 | ||
28 | |||
29 | Alternatively you might use a combination of the mode, ref and bpp | ||
30 | parameters. If you compiled the driver into the kernel, add something | ||
31 | like this to the kernel command line: | ||
32 | |||
33 | video=cyblafb:1280x1024,bpp=16,ref=50 ... | ||
34 | |||
35 | If you compiled the driver as a module, the same mode would be | ||
36 | selected by the following command: | ||
37 | |||
38 | modprobe cyblafb mode=1280x1024 bpp=16 ref=50 ... | ||
39 | |||
40 | None of the modes possible to select as startup modes are affected by | ||
41 | the problems described at the end of the next subsection. | ||
42 | |||
43 | For all startup modes cyblafb chooses a virtual x resolution of 2048, | ||
44 | the only exception is mode 1280x1024 in combination with 32 bpp. This | ||
45 | allows ywrap scrolling for all those modes if rotation is 0 or 2, and | ||
46 | also fast scrolling if rotation is 1 or 3. The default virtual y reso- | ||
47 | lution is 4096 for bpp == 8, 2048 for bpp==16 and 1024 for bpp == 32, | ||
48 | again with the only exception of 1280x1024 at 32 bpp. | ||
49 | |||
50 | Please do set your video memory size to 8 Mb in the Bios setup. Other | ||
51 | values will work, but performace is decreased for a lot of modes. | ||
52 | |||
53 | Mode changes using fbset | ||
54 | ======================== | ||
55 | |||
56 | You might use fbset to change the video mode, see "man fbset". Cyblafb | ||
57 | generally does assume that you know what you are doing. But it does | ||
58 | some checks, especially those that are needed to prevent you from | ||
59 | damaging your hardware. | ||
60 | |||
61 | - only 8, 16, 24 and 32 bpp video modes are accepted | ||
62 | - interlaced video modes are not accepted | ||
63 | - double scan video modes are not accepted | ||
64 | - if a flat panel is found, cyblafb does not allow you | ||
65 | to program a resolution higher than the physical | ||
66 | resolution of the flat panel monitor | ||
67 | - cyblafb does not allow vclk to exceed 230 MHz. As 32 bpp | ||
68 | and (currently) 24 bit modes use a doubled vclk internally, | ||
69 | the dotclock limit as seen by fbset is 115 MHz for those | ||
70 | modes and 230 MHz for 8 and 16 bpp modes. | ||
71 | - cyblafb will allow you to select very high resolutions as | ||
72 | long as the hardware can be programmed to these modes. The | ||
73 | documented limit 1600x1200 is not enforced, but don't expect | ||
74 | perfect signal quality. | ||
75 | |||
76 | Any request that violates the rules given above will be either changed | ||
77 | to something the hardware supports or an error value will be returned. | ||
78 | |||
79 | If you program a virtual y resolution higher than the hardware limit, | ||
80 | cyblafb will silently decrease that value to the highest possible | ||
81 | value. The same is true for a virtual x resolution that is not | ||
82 | supported by the hardware. Cyblafb tries to adapt vyres first because | ||
83 | vxres decides if ywrap scrolling is possible or not. | ||
84 | |||
85 | Attempts to disable acceleration are ignored, I believe that this is | ||
86 | safe. | ||
87 | |||
88 | Some video modes that should work do not work as expected. If you use | ||
89 | the standard fb.modes, fbset 640x480-60 will program that mode, but | ||
90 | you will see a vertical area, about two characters wide, with only | ||
91 | much darker characters than the other characters on the screen. | ||
92 | Cyblafb does allow that mode to be set, as it does not violate the | ||
93 | official specifications. It would need a lot of code to reliably sort | ||
94 | out all invalid modes, playing around with the margin values will | ||
95 | give a valid mode quickly. And if cyblafb would detect such an invalid | ||
96 | mode, should it silently alter the requested values or should it | ||
97 | report an error? Both options have some pros and cons. As stated | ||
98 | above, none of the startup modes are affected, and if you set | ||
99 | verbosity to 1 or higher, cyblafb will print the fbset command that | ||
100 | would be needed to program that mode using fbset. | ||
101 | |||
102 | |||
103 | Other Parameters | ||
104 | ================ | ||
105 | |||
106 | |||
107 | crt don't autodetect, assume monitor connected to | ||
108 | standard VGA connector | ||
109 | |||
110 | fp don't autodetect, assume flat panel display | ||
111 | connected to flat panel monitor interface | ||
112 | |||
113 | nativex inform driver about native x resolution of | ||
114 | flat panel monitor connected to special | ||
115 | interface (should be autodetected) | ||
116 | |||
117 | stretch stretch image to adapt low resolution modes to | ||
118 | higer resolutions of flat panel monitors | ||
119 | connected to special interface | ||
120 | |||
121 | center center image to adapt low resolution modes to | ||
122 | higer resolutions of flat panel monitors | ||
123 | connected to special interface | ||
124 | |||
125 | memsize use if autodetected memsize is wrong ... | ||
126 | should never be necessary | ||
127 | |||
128 | nopcirr disable PCI read retry | ||
129 | nopciwr disable PCI write retry | ||
130 | nopcirb disable PCI read bursts | ||
131 | nopciwb disable PCI write bursts | ||
132 | |||
133 | bpp bpp for specified modes | ||
134 | valid values: 8 || 16 || 24 || 32 | ||
135 | |||
136 | ref refresh rate for specified mode | ||
137 | valid values: 50 <= ref <= 85 | ||
138 | |||
139 | mode 640x480 or 800x600 or 1024x768 or 1280x1024 | ||
140 | if not specified, the startup mode will be detected | ||
141 | and used, so you might also use the vga=??? parameter | ||
142 | described in vesafb.txt. If you do not specify a mode, | ||
143 | bpp and ref parameters are ignored. | ||
144 | |||
145 | verbosity 0 is the default, increase to at least 2 for every | ||
146 | bug report! | ||
147 | |||
148 | Development hints | ||
149 | ================= | ||
150 | |||
151 | It's much faster do compile a module and to load the new version after | ||
152 | unloading the old module than to compile a new kernel and to reboot. So if you | ||
153 | try to work on cyblafb, it might be a good idea to use cyblafb as a module. | ||
154 | In real life, fast often means dangerous, and that's also the case here. If | ||
155 | you introduce a serious bug when cyblafb is compiled into the kernel, the | ||
156 | kernel will lock or oops with a high probability before the file system is | ||
157 | mounted, and the danger for your data is low. If you load a broken own version | ||
158 | of cyblafb on a running system, the danger for the integrity of the file | ||
159 | system is much higher as you might need a hard reset afterwards. Decide | ||
160 | yourself. | ||
161 | |||
162 | Module unloading, the vfb method | ||
163 | ================================ | ||
164 | |||
165 | If you want to unload/reload cyblafb using the virtual framebuffer, you need | ||
166 | to enable vfb support in the kernel first. After that, load the modules as | ||
167 | shown below: | ||
168 | |||
169 | modprobe vfb vfb_enable=1 | ||
170 | modprobe fbcon | ||
171 | modprobe cyblafb | ||
172 | fbset -fb /dev/fb1 1280x1024-60 -vyres 2662 | ||
173 | con2fb /dev/fb1 /dev/tty1 | ||
174 | ... | ||
175 | |||
176 | If you now made some changes to cyblafb and want to reload it, you might do it | ||
177 | as show below: | ||
178 | |||
179 | con2fb /dev/fb0 /dev/tty1 | ||
180 | ... | ||
181 | rmmod cyblafb | ||
182 | modprobe cyblafb | ||
183 | con2fb /dev/fb1 /dev/tty1 | ||
184 | ... | ||
185 | |||
186 | Of course, you might choose another mode, and most certainly you also want to | ||
187 | map some other /dev/tty* to the real framebuffer device. You might also choose | ||
188 | to compile fbcon as a kernel module or place it permanently in the kernel. | ||
189 | |||
190 | I do not know of any way to unload fbcon, and fbcon will prevent the | ||
191 | framebuffer device loaded first from unloading. [If there is a way, then | ||
192 | please add a description here!] | ||
193 | |||
194 | Module unloading, the vesafb method | ||
195 | =================================== | ||
196 | |||
197 | Configure the kernel: | ||
198 | |||
199 | <*> Support for frame buffer devices | ||
200 | [*] VESA VGA graphics support | ||
201 | <M> Cyberblade/i1 support | ||
202 | |||
203 | Add e.g. "video=vesafb:ypan vga=0x307" to the kernel parameters. The ypan | ||
204 | parameter is important, choose any vga parameter you like as long as it is | ||
205 | a graphics mode. | ||
206 | |||
207 | After booting, load cyblafb without any mode and bpp parameter and assign | ||
208 | cyblafb to individual ttys using con2fb, e.g.: | ||
209 | |||
210 | modprobe cyblafb | ||
211 | con2fb /dev/fb1 /dev/tty1 | ||
212 | |||
213 | Unloading cyblafb works without problems after you assign vesafb to all | ||
214 | ttys again, e.g.: | ||
215 | |||
216 | con2fb /dev/fb0 /dev/tty1 | ||
217 | rmmod cyblafb | ||
diff --git a/Documentation/fb/cyblafb/whatsnew b/Documentation/fb/cyblafb/whatsnew deleted file mode 100644 index 76c07a26e044..000000000000 --- a/Documentation/fb/cyblafb/whatsnew +++ /dev/null | |||
@@ -1,29 +0,0 @@ | |||
1 | 0.62 | ||
2 | ==== | ||
3 | |||
4 | - the vesafb parameter has been removed as I decided to allow the | ||
5 | feature without any special parameter. | ||
6 | |||
7 | - Cyblafb does not use the vga style of panning any longer, now the | ||
8 | "right view" register in the graphics engine IO space is used. Without | ||
9 | that change it was impossible to use all available memory, and without | ||
10 | access to all available memory it is impossible to ywrap. | ||
11 | |||
12 | - The imageblit function now uses hardware acceleration for all font | ||
13 | widths. Hardware blitting across pixel column 2048 is broken in the | ||
14 | cyberblade/i1 graphics core, but we work around that hardware bug. | ||
15 | |||
16 | - modes with vxres != xres are supported now. | ||
17 | |||
18 | - ywrap scrolling is supported now and the default. This is a big | ||
19 | performance gain. | ||
20 | |||
21 | - default video modes use vyres > yres and vxres > xres to allow | ||
22 | almost optimal scrolling speed for normal and rotated screens | ||
23 | |||
24 | - some features mainly usefull for debugging the upper layers of the | ||
25 | framebuffer system have been added, have a look at the code | ||
26 | |||
27 | - fixed: Oops after unloading cyblafb when reading /proc/io* | ||
28 | |||
29 | - we work around some bugs of the higher framebuffer layers. | ||
diff --git a/Documentation/fb/cyblafb/whycyblafb b/Documentation/fb/cyblafb/whycyblafb deleted file mode 100644 index a123bc11e698..000000000000 --- a/Documentation/fb/cyblafb/whycyblafb +++ /dev/null | |||
@@ -1,85 +0,0 @@ | |||
1 | I tried the following framebuffer drivers: | ||
2 | |||
3 | - TRIDENTFB is full of bugs. Acceleration is broken for Blade3D | ||
4 | graphics cores like the cyberblade/i1. It claims to support a great | ||
5 | number of devices, but documentation for most of these devices is | ||
6 | unfortunately not available. There is _no_ reason to use tridentfb | ||
7 | for cyberblade/i1 + CRT users. VESAFB is faster, and the one | ||
8 | advantage, mode switching, is broken in tridentfb. | ||
9 | |||
10 | - VESAFB is used by many distributions as a standard. Vesafb does | ||
11 | not support mode switching. VESAFB is a bit faster than the working | ||
12 | configurations of TRIDENTFB, but it is still too slow, even if you | ||
13 | use ypan. | ||
14 | |||
15 | - EPIAFB (you'll find it on sourceforge) supports the Cyberblade/i1 | ||
16 | graphics core, but it still has serious bugs and developement seems | ||
17 | to have stopped. This is the one driver with TV-out support. If you | ||
18 | do need this feature, try epiafb. | ||
19 | |||
20 | None of these drivers was a real option for me. | ||
21 | |||
22 | I believe that is unreasonable to change code that announces to support 20 | ||
23 | devices if I only have more or less sufficient documentation for exactly one | ||
24 | of these. The risk of breaking device foo while fixing device bar is too high. | ||
25 | |||
26 | So I decided to start CyBlaFB as a stripped down tridentfb. | ||
27 | |||
28 | All code specific to other Trident chips has been removed. After that there | ||
29 | were a lot of cosmetic changes to increase the readability of the code. All | ||
30 | register names were changed to those mnemonics used in the datasheet. Function | ||
31 | and macro names were changed if they hindered easy understanding of the code. | ||
32 | |||
33 | After that I debugged the code and implemented some new features. I'll try to | ||
34 | give a little summary of the main changes: | ||
35 | |||
36 | - calculation of vertical and horizontal timings was fixed | ||
37 | |||
38 | - video signal quality has been improved dramatically | ||
39 | |||
40 | - acceleration: | ||
41 | |||
42 | - fillrect and copyarea were fixed and reenabled | ||
43 | |||
44 | - color expanding imageblit was newly implemented, color | ||
45 | imageblit (only used to draw the penguine) still uses the | ||
46 | generic code. | ||
47 | |||
48 | - init of the acceleration engine was improved and moved to a | ||
49 | place where it really works ... | ||
50 | |||
51 | - sync function has a timeout now and tries to reset and | ||
52 | reinit the accel engine if necessary | ||
53 | |||
54 | - fewer slow copyarea calls when doing ypan scrolling by using | ||
55 | undocumented bit d21 of screen start address stored in | ||
56 | CR2B[5]. BIOS does use it also, so this should be safe. | ||
57 | |||
58 | - cyblafb rejects any attempt to set modes that would cause vclk | ||
59 | values above reasonable 230 MHz. 32bit modes use a clock | ||
60 | multiplicator of 2, so fbset does show the correct values for | ||
61 | pixclock but not for vclk in this case. The fbset limit is 115 MHz | ||
62 | for 32 bpp modes. | ||
63 | |||
64 | - cyblafb rejects modes known to be broken or unimplemented (all | ||
65 | interlaced modes, all doublescan modes for now) | ||
66 | |||
67 | - cyblafb now works independant of the video mode in effect at startup | ||
68 | time (tridentfb does not init all needed registers to reasonable | ||
69 | values) | ||
70 | |||
71 | - switching between video modes does work reliably now | ||
72 | |||
73 | - the first video mode now is the one selected on startup using the | ||
74 | vga=???? mechanism or any of | ||
75 | - 640x480, 800x600, 1024x768, 1280x1024 | ||
76 | - 8, 16, 24 or 32 bpp | ||
77 | - refresh between 50 Hz and 85 Hz, 1 Hz steps (1280x1024-32 | ||
78 | is limited to 63Hz) | ||
79 | |||
80 | - pci retry and pci burst mode are settable (try to disable if you | ||
81 | experience latency problems) | ||
82 | |||
83 | - built as a module cyblafb might be unloaded and reloaded using | ||
84 | the vfb module and con2vt or might be used together with vesafb | ||
85 | |||
diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt index 7ac3c4078ff9..eefdd91d298a 100644 --- a/Documentation/fb/uvesafb.txt +++ b/Documentation/fb/uvesafb.txt | |||
@@ -59,7 +59,8 @@ Accepted options: | |||
59 | ypan Enable display panning using the VESA protected mode | 59 | ypan Enable display panning using the VESA protected mode |
60 | interface. The visible screen is just a window of the | 60 | interface. The visible screen is just a window of the |
61 | video memory, console scrolling is done by changing the | 61 | video memory, console scrolling is done by changing the |
62 | start of the window. Available on x86 only. | 62 | start of the window. This option is available on x86 |
63 | only and is the default option on that architecture. | ||
63 | 64 | ||
64 | ywrap Same as ypan, but assumes your gfx board can wrap-around | 65 | ywrap Same as ypan, but assumes your gfx board can wrap-around |
65 | the video memory (i.e. starts reading from top if it | 66 | the video memory (i.e. starts reading from top if it |
@@ -67,7 +68,7 @@ ywrap Same as ypan, but assumes your gfx board can wrap-around | |||
67 | Available on x86 only. | 68 | Available on x86 only. |
68 | 69 | ||
69 | redraw Scroll by redrawing the affected part of the screen, this | 70 | redraw Scroll by redrawing the affected part of the screen, this |
70 | is the safe (and slow) default. | 71 | is the default on non-x86. |
71 | 72 | ||
72 | (If you're using uvesafb as a module, the above three options are | 73 | (If you're using uvesafb as a module, the above three options are |
73 | used a parameter of the scroll option, e.g. scroll=ypan.) | 74 | used a parameter of the scroll option, e.g. scroll=ypan.) |
@@ -182,7 +183,7 @@ from the Video BIOS if you set pixclock to 0 in fb_var_screeninfo. | |||
182 | 183 | ||
183 | -- | 184 | -- |
184 | Michal Januszewski <spock@gentoo.org> | 185 | Michal Januszewski <spock@gentoo.org> |
185 | Last updated: 2007-06-16 | 186 | Last updated: 2009-03-30 |
186 | 187 | ||
187 | Documentation of the uvesafb options is loosely based on vesafb.txt. | 188 | Documentation of the uvesafb options is loosely based on vesafb.txt. |
188 | 189 | ||
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 5ddbe350487a..7e2af10e8264 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -6,20 +6,47 @@ be removed from this file. | |||
6 | 6 | ||
7 | --------------------------- | 7 | --------------------------- |
8 | 8 | ||
9 | What: old static regulatory information and ieee80211_regdom module parameter | 9 | What: The ieee80211_regdom module parameter |
10 | When: 2.6.29 | 10 | When: March 2010 / desktop catchup |
11 | |||
12 | Why: This was inherited by the CONFIG_WIRELESS_OLD_REGULATORY code, | ||
13 | and currently serves as an option for users to define an | ||
14 | ISO / IEC 3166 alpha2 code for the country they are currently | ||
15 | present in. Although there are userspace API replacements for this | ||
16 | through nl80211 distributions haven't yet caught up with implementing | ||
17 | decent alternatives through standard GUIs. Although available as an | ||
18 | option through iw or wpa_supplicant its just a matter of time before | ||
19 | distributions pick up good GUI options for this. The ideal solution | ||
20 | would actually consist of intelligent designs which would do this for | ||
21 | the user automatically even when travelling through different countries. | ||
22 | Until then we leave this module parameter as a compromise. | ||
23 | |||
24 | When userspace improves with reasonable widely-available alternatives for | ||
25 | this we will no longer need this module parameter. This entry hopes that | ||
26 | by the super-futuristically looking date of "March 2010" we will have | ||
27 | such replacements widely available. | ||
28 | |||
29 | Who: Luis R. Rodriguez <lrodriguez@atheros.com> | ||
30 | |||
31 | --------------------------- | ||
32 | |||
33 | What: CONFIG_WIRELESS_OLD_REGULATORY - old static regulatory information | ||
34 | When: March 2010 / desktop catchup | ||
35 | |||
11 | Why: The old regulatory infrastructure has been replaced with a new one | 36 | Why: The old regulatory infrastructure has been replaced with a new one |
12 | which does not require statically defined regulatory domains. We do | 37 | which does not require statically defined regulatory domains. We do |
13 | not want to keep static regulatory domains in the kernel due to the | 38 | not want to keep static regulatory domains in the kernel due to the |
14 | the dynamic nature of regulatory law and localization. We kept around | 39 | the dynamic nature of regulatory law and localization. We kept around |
15 | the old static definitions for the regulatory domains of: | 40 | the old static definitions for the regulatory domains of: |
41 | |||
16 | * US | 42 | * US |
17 | * JP | 43 | * JP |
18 | * EU | 44 | * EU |
45 | |||
19 | and used by default the US when CONFIG_WIRELESS_OLD_REGULATORY was | 46 | and used by default the US when CONFIG_WIRELESS_OLD_REGULATORY was |
20 | set. We also kept around the ieee80211_regdom module parameter in case | 47 | set. We will remove this option once the standard Linux desktop catches |
21 | some applications were relying on it. Changing regulatory domains | 48 | up with the new userspace APIs we have implemented. |
22 | can now be done instead by using nl80211, as is done with iw. | 49 | |
23 | Who: Luis R. Rodriguez <lrodriguez@atheros.com> | 50 | Who: Luis R. Rodriguez <lrodriguez@atheros.com> |
24 | 51 | ||
25 | --------------------------- | 52 | --------------------------- |
@@ -37,10 +64,10 @@ Who: Pavel Machek <pavel@suse.cz> | |||
37 | 64 | ||
38 | --------------------------- | 65 | --------------------------- |
39 | 66 | ||
40 | What: Video4Linux API 1 ioctls and video_decoder.h from Video devices. | 67 | What: Video4Linux API 1 ioctls and from Video devices. |
41 | When: December 2008 | 68 | When: July 2009 |
42 | Files: include/linux/video_decoder.h include/linux/videodev.h | 69 | Files: include/linux/videodev.h |
43 | Check: include/linux/video_decoder.h include/linux/videodev.h | 70 | Check: include/linux/videodev.h |
44 | Why: V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6 | 71 | Why: V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6 |
45 | series. The old API have lots of drawbacks and don't provide enough | 72 | series. The old API have lots of drawbacks and don't provide enough |
46 | means to work with all video and audio standards. The newer API is | 73 | means to work with all video and audio standards. The newer API is |
@@ -228,8 +255,20 @@ Who: Jan Engelhardt <jengelh@computergmbh.de> | |||
228 | 255 | ||
229 | --------------------------- | 256 | --------------------------- |
230 | 257 | ||
258 | What: GPIO autorequest on gpio_direction_{input,output}() in gpiolib | ||
259 | When: February 2010 | ||
260 | Why: All callers should use explicit gpio_request()/gpio_free(). | ||
261 | The autorequest mechanism in gpiolib was provided mostly as a | ||
262 | migration aid for legacy GPIO interfaces (for SOC based GPIOs). | ||
263 | Those users have now largely migrated. Platforms implementing | ||
264 | the GPIO interfaces without using gpiolib will see no changes. | ||
265 | Who: David Brownell <dbrownell@users.sourceforge.net> | ||
266 | --------------------------- | ||
267 | |||
231 | What: b43 support for firmware revision < 410 | 268 | What: b43 support for firmware revision < 410 |
232 | When: July 2008 | 269 | When: The schedule was July 2008, but it was decided that we are going to keep the |
270 | code as long as there are no major maintanance headaches. | ||
271 | So it _could_ be removed _any_ time now, if it conflicts with something new. | ||
233 | Why: The support code for the old firmware hurts code readability/maintainability | 272 | Why: The support code for the old firmware hurts code readability/maintainability |
234 | and slightly hurts runtime performance. Bugfixes for the old firmware | 273 | and slightly hurts runtime performance. Bugfixes for the old firmware |
235 | are not provided by Broadcom anymore. | 274 | are not provided by Broadcom anymore. |
@@ -244,13 +283,6 @@ Who: Glauber Costa <gcosta@redhat.com> | |||
244 | 283 | ||
245 | --------------------------- | 284 | --------------------------- |
246 | 285 | ||
247 | What: remove HID compat support | ||
248 | When: 2.6.29 | ||
249 | Why: needed only as a temporary solution until distros fix themselves up | ||
250 | Who: Jiri Slaby <jirislaby@gmail.com> | ||
251 | |||
252 | --------------------------- | ||
253 | |||
254 | What: print_fn_descriptor_symbol() | 286 | What: print_fn_descriptor_symbol() |
255 | When: October 2009 | 287 | When: October 2009 |
256 | Why: The %pF vsprintf format provides the same functionality in a | 288 | Why: The %pF vsprintf format provides the same functionality in a |
@@ -282,6 +314,18 @@ Who: Vlad Yasevich <vladislav.yasevich@hp.com> | |||
282 | 314 | ||
283 | --------------------------- | 315 | --------------------------- |
284 | 316 | ||
317 | What: Ability for non root users to shm_get hugetlb pages based on mlock | ||
318 | resource limits | ||
319 | When: 2.6.31 | ||
320 | Why: Non root users need to be part of /proc/sys/vm/hugetlb_shm_group or | ||
321 | have CAP_IPC_LOCK to be able to allocate shm segments backed by | ||
322 | huge pages. The mlock based rlimit check to allow shm hugetlb is | ||
323 | inconsistent with mmap based allocations. Hence it is being | ||
324 | deprecated. | ||
325 | Who: Ravikiran Thirumalai <kiran@scalex86.org> | ||
326 | |||
327 | --------------------------- | ||
328 | |||
285 | What: CONFIG_THERMAL_HWMON | 329 | What: CONFIG_THERMAL_HWMON |
286 | When: January 2009 | 330 | When: January 2009 |
287 | Why: This option was introduced just to allow older lm-sensors userspace | 331 | Why: This option was introduced just to allow older lm-sensors userspace |
@@ -310,8 +354,10 @@ Who: Krzysztof Piotr Oledzki <ole@ans.pl> | |||
310 | 354 | ||
311 | --------------------------- | 355 | --------------------------- |
312 | 356 | ||
313 | What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client() | 357 | What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client(), |
314 | When: 2.6.29 (ideally) or 2.6.30 (more likely) | 358 | i2c_adapter->client_register(), i2c_adapter->client_unregister |
359 | When: 2.6.30 | ||
360 | Check: i2c_attach_client i2c_detach_client | ||
315 | Why: Deprecated by the new (standard) device driver binding model. Use | 361 | Why: Deprecated by the new (standard) device driver binding model. Use |
316 | i2c_driver->probe() and ->remove() instead. | 362 | i2c_driver->probe() and ->remove() instead. |
317 | Who: Jean Delvare <khali@linux-fr.org> | 363 | Who: Jean Delvare <khali@linux-fr.org> |
@@ -326,12 +372,59 @@ Who: Hans de Goede <hdegoede@redhat.com> | |||
326 | 372 | ||
327 | --------------------------- | 373 | --------------------------- |
328 | 374 | ||
329 | What: SELinux "compat_net" functionality | 375 | What: sysfs ui for changing p4-clockmod parameters |
330 | When: 2.6.30 at the earliest | 376 | When: September 2009 |
331 | Why: In 2.6.18 the Secmark concept was introduced to replace the "compat_net" | 377 | Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and |
332 | network access control functionality of SELinux. Secmark offers both | 378 | e088e4c9cdb618675874becb91b2fd581ee707e6. |
333 | better performance and greater flexibility than the "compat_net" | 379 | Removal is subject to fixing any remaining bugs in ACPI which may |
334 | mechanism. Now that the major Linux distributions have moved to | 380 | cause the thermal throttling not to happen at the right time. |
335 | Secmark, it is time to deprecate the older mechanism and start the | 381 | Who: Dave Jones <davej@redhat.com>, Matthew Garrett <mjg@redhat.com> |
336 | process of removing the old code. | 382 | |
337 | Who: Paul Moore <paul.moore@hp.com> | 383 | ----------------------------- |
384 | |||
385 | What: __do_IRQ all in one fits nothing interrupt handler | ||
386 | When: 2.6.32 | ||
387 | Why: __do_IRQ was kept for easy migration to the type flow handlers. | ||
388 | More than two years of migration time is enough. | ||
389 | Who: Thomas Gleixner <tglx@linutronix.de> | ||
390 | |||
391 | ----------------------------- | ||
392 | |||
393 | What: obsolete generic irq defines and typedefs | ||
394 | When: 2.6.30 | ||
395 | Why: The defines and typedefs (hw_interrupt_type, no_irq_type, irq_desc_t) | ||
396 | have been kept around for migration reasons. After more than two years | ||
397 | it's time to remove them finally | ||
398 | Who: Thomas Gleixner <tglx@linutronix.de> | ||
399 | |||
400 | --------------------------- | ||
401 | |||
402 | What: fakephp and associated sysfs files in /sys/bus/pci/slots/ | ||
403 | When: 2011 | ||
404 | Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to | ||
405 | represent a machine's physical PCI slots. The change in semantics | ||
406 | had userspace implications, as the hotplug core no longer allowed | ||
407 | drivers to create multiple sysfs files per physical slot (required | ||
408 | for multi-function devices, e.g.). fakephp was seen as a developer's | ||
409 | tool only, and its interface changed. Too late, we learned that | ||
410 | there were some users of the fakephp interface. | ||
411 | |||
412 | In 2.6.30, the original fakephp interface was restored. At the same | ||
413 | time, the PCI core gained the ability that fakephp provided, namely | ||
414 | function-level hot-remove and hot-add. | ||
415 | |||
416 | Since the PCI core now provides the same functionality, exposed in: | ||
417 | |||
418 | /sys/bus/pci/rescan | ||
419 | /sys/bus/pci/devices/.../remove | ||
420 | /sys/bus/pci/devices/.../rescan | ||
421 | |||
422 | there is no functional reason to maintain fakephp as well. | ||
423 | |||
424 | We will keep the existing module so that 'modprobe fakephp' will | ||
425 | present the old /sys/bus/pci/slots/... interface for compatibility, | ||
426 | but users are urged to migrate their applications to the API above. | ||
427 | |||
428 | After a reasonable transition period, we will remove the legacy | ||
429 | fakephp interface. | ||
430 | Who: Alex Chiang <achiang@hp.com> | ||
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index 52cd611277a3..8dd6db76171d 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX | |||
@@ -68,6 +68,8 @@ ncpfs.txt | |||
68 | - info on Novell Netware(tm) filesystem using NCP protocol. | 68 | - info on Novell Netware(tm) filesystem using NCP protocol. |
69 | nfsroot.txt | 69 | nfsroot.txt |
70 | - short guide on setting up a diskless box with NFS root filesystem. | 70 | - short guide on setting up a diskless box with NFS root filesystem. |
71 | nilfs2.txt | ||
72 | - info and mount options for the NILFS2 filesystem. | ||
71 | ntfs.txt | 73 | ntfs.txt |
72 | - info and mount options for the NTFS filesystem (Windows NT). | 74 | - info and mount options for the NTFS filesystem (Windows NT). |
73 | ocfs2.txt | 75 | ocfs2.txt |
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index ec6a9392a173..76efe5b71d7d 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking | |||
@@ -437,8 +437,11 @@ grab BKL for cases when we close a file that had been opened r/w, but that | |||
437 | can and should be done using the internal locking with smaller critical areas). | 437 | can and should be done using the internal locking with smaller critical areas). |
438 | Current worst offender is ext2_get_block()... | 438 | Current worst offender is ext2_get_block()... |
439 | 439 | ||
440 | ->fasync() is a mess. This area needs a big cleanup and that will probably | 440 | ->fasync() is called without BKL protection, and is responsible for |
441 | affect locking. | 441 | maintaining the FASYNC bit in filp->f_flags. Most instances call |
442 | fasync_helper(), which does that maintenance, so it's not normally | ||
443 | something one needs to worry about. Return values > 0 will be mapped to | ||
444 | zero in the VFS layer. | ||
442 | 445 | ||
443 | ->readdir() and ->ioctl() on directories must be changed. Ideally we would | 446 | ->readdir() and ->ioctl() on directories must be changed. Ideally we would |
444 | move ->readdir() to inode_operations and use a separate method for directory | 447 | move ->readdir() to inode_operations and use a separate method for directory |
@@ -502,7 +505,7 @@ prototypes: | |||
502 | void (*open)(struct vm_area_struct*); | 505 | void (*open)(struct vm_area_struct*); |
503 | void (*close)(struct vm_area_struct*); | 506 | void (*close)(struct vm_area_struct*); |
504 | int (*fault)(struct vm_area_struct*, struct vm_fault *); | 507 | int (*fault)(struct vm_area_struct*, struct vm_fault *); |
505 | int (*page_mkwrite)(struct vm_area_struct *, struct page *); | 508 | int (*page_mkwrite)(struct vm_area_struct *, struct vm_fault *); |
506 | int (*access)(struct vm_area_struct *, unsigned long, void*, int, int); | 509 | int (*access)(struct vm_area_struct *, unsigned long, void*, int, int); |
507 | 510 | ||
508 | locking rules: | 511 | locking rules: |
diff --git a/Documentation/filesystems/caching/backend-api.txt b/Documentation/filesystems/caching/backend-api.txt new file mode 100644 index 000000000000..382d52cdaf2d --- /dev/null +++ b/Documentation/filesystems/caching/backend-api.txt | |||
@@ -0,0 +1,658 @@ | |||
1 | ========================== | ||
2 | FS-CACHE CACHE BACKEND API | ||
3 | ========================== | ||
4 | |||
5 | The FS-Cache system provides an API by which actual caches can be supplied to | ||
6 | FS-Cache for it to then serve out to network filesystems and other interested | ||
7 | parties. | ||
8 | |||
9 | This API is declared in <linux/fscache-cache.h>. | ||
10 | |||
11 | |||
12 | ==================================== | ||
13 | INITIALISING AND REGISTERING A CACHE | ||
14 | ==================================== | ||
15 | |||
16 | To start off, a cache definition must be initialised and registered for each | ||
17 | cache the backend wants to make available. For instance, CacheFS does this in | ||
18 | the fill_super() operation on mounting. | ||
19 | |||
20 | The cache definition (struct fscache_cache) should be initialised by calling: | ||
21 | |||
22 | void fscache_init_cache(struct fscache_cache *cache, | ||
23 | struct fscache_cache_ops *ops, | ||
24 | const char *idfmt, | ||
25 | ...); | ||
26 | |||
27 | Where: | ||
28 | |||
29 | (*) "cache" is a pointer to the cache definition; | ||
30 | |||
31 | (*) "ops" is a pointer to the table of operations that the backend supports on | ||
32 | this cache; and | ||
33 | |||
34 | (*) "idfmt" is a format and printf-style arguments for constructing a label | ||
35 | for the cache. | ||
36 | |||
37 | |||
38 | The cache should then be registered with FS-Cache by passing a pointer to the | ||
39 | previously initialised cache definition to: | ||
40 | |||
41 | int fscache_add_cache(struct fscache_cache *cache, | ||
42 | struct fscache_object *fsdef, | ||
43 | const char *tagname); | ||
44 | |||
45 | Two extra arguments should also be supplied: | ||
46 | |||
47 | (*) "fsdef" which should point to the object representation for the FS-Cache | ||
48 | master index in this cache. Netfs primary index entries will be created | ||
49 | here. FS-Cache keeps the caller's reference to the index object if | ||
50 | successful and will release it upon withdrawal of the cache. | ||
51 | |||
52 | (*) "tagname" which, if given, should be a text string naming this cache. If | ||
53 | this is NULL, the identifier will be used instead. For CacheFS, the | ||
54 | identifier is set to name the underlying block device and the tag can be | ||
55 | supplied by mount. | ||
56 | |||
57 | This function may return -ENOMEM if it ran out of memory or -EEXIST if the tag | ||
58 | is already in use. 0 will be returned on success. | ||
59 | |||
60 | |||
61 | ===================== | ||
62 | UNREGISTERING A CACHE | ||
63 | ===================== | ||
64 | |||
65 | A cache can be withdrawn from the system by calling this function with a | ||
66 | pointer to the cache definition: | ||
67 | |||
68 | void fscache_withdraw_cache(struct fscache_cache *cache); | ||
69 | |||
70 | In CacheFS's case, this is called by put_super(). | ||
71 | |||
72 | |||
73 | ======== | ||
74 | SECURITY | ||
75 | ======== | ||
76 | |||
77 | The cache methods are executed one of two contexts: | ||
78 | |||
79 | (1) that of the userspace process that issued the netfs operation that caused | ||
80 | the cache method to be invoked, or | ||
81 | |||
82 | (2) that of one of the processes in the FS-Cache thread pool. | ||
83 | |||
84 | In either case, this may not be an appropriate context in which to access the | ||
85 | cache. | ||
86 | |||
87 | The calling process's fsuid, fsgid and SELinux security identities may need to | ||
88 | be masqueraded for the duration of the cache driver's access to the cache. | ||
89 | This is left to the cache to handle; FS-Cache makes no effort in this regard. | ||
90 | |||
91 | |||
92 | =================================== | ||
93 | CONTROL AND STATISTICS PRESENTATION | ||
94 | =================================== | ||
95 | |||
96 | The cache may present data to the outside world through FS-Cache's interfaces | ||
97 | in sysfs and procfs - the former for control and the latter for statistics. | ||
98 | |||
99 | A sysfs directory called /sys/fs/fscache/<cachetag>/ is created if CONFIG_SYSFS | ||
100 | is enabled. This is accessible through the kobject struct fscache_cache::kobj | ||
101 | and is for use by the cache as it sees fit. | ||
102 | |||
103 | |||
104 | ======================== | ||
105 | RELEVANT DATA STRUCTURES | ||
106 | ======================== | ||
107 | |||
108 | (*) Index/Data file FS-Cache representation cookie: | ||
109 | |||
110 | struct fscache_cookie { | ||
111 | struct fscache_object_def *def; | ||
112 | struct fscache_netfs *netfs; | ||
113 | void *netfs_data; | ||
114 | ... | ||
115 | }; | ||
116 | |||
117 | The fields that might be of use to the backend describe the object | ||
118 | definition, the netfs definition and the netfs's data for this cookie. | ||
119 | The object definition contain functions supplied by the netfs for loading | ||
120 | and matching index entries; these are required to provide some of the | ||
121 | cache operations. | ||
122 | |||
123 | |||
124 | (*) In-cache object representation: | ||
125 | |||
126 | struct fscache_object { | ||
127 | int debug_id; | ||
128 | enum { | ||
129 | FSCACHE_OBJECT_RECYCLING, | ||
130 | ... | ||
131 | } state; | ||
132 | spinlock_t lock | ||
133 | struct fscache_cache *cache; | ||
134 | struct fscache_cookie *cookie; | ||
135 | ... | ||
136 | }; | ||
137 | |||
138 | Structures of this type should be allocated by the cache backend and | ||
139 | passed to FS-Cache when requested by the appropriate cache operation. In | ||
140 | the case of CacheFS, they're embedded in CacheFS's internal object | ||
141 | structures. | ||
142 | |||
143 | The debug_id is a simple integer that can be used in debugging messages | ||
144 | that refer to a particular object. In such a case it should be printed | ||
145 | using "OBJ%x" to be consistent with FS-Cache. | ||
146 | |||
147 | Each object contains a pointer to the cookie that represents the object it | ||
148 | is backing. An object should retired when put_object() is called if it is | ||
149 | in state FSCACHE_OBJECT_RECYCLING. The fscache_object struct should be | ||
150 | initialised by calling fscache_object_init(object). | ||
151 | |||
152 | |||
153 | (*) FS-Cache operation record: | ||
154 | |||
155 | struct fscache_operation { | ||
156 | atomic_t usage; | ||
157 | struct fscache_object *object; | ||
158 | unsigned long flags; | ||
159 | #define FSCACHE_OP_EXCLUSIVE | ||
160 | void (*processor)(struct fscache_operation *op); | ||
161 | void (*release)(struct fscache_operation *op); | ||
162 | ... | ||
163 | }; | ||
164 | |||
165 | FS-Cache has a pool of threads that it uses to give CPU time to the | ||
166 | various asynchronous operations that need to be done as part of driving | ||
167 | the cache. These are represented by the above structure. The processor | ||
168 | method is called to give the op CPU time, and the release method to get | ||
169 | rid of it when its usage count reaches 0. | ||
170 | |||
171 | An operation can be made exclusive upon an object by setting the | ||
172 | appropriate flag before enqueuing it with fscache_enqueue_operation(). If | ||
173 | an operation needs more processing time, it should be enqueued again. | ||
174 | |||
175 | |||
176 | (*) FS-Cache retrieval operation record: | ||
177 | |||
178 | struct fscache_retrieval { | ||
179 | struct fscache_operation op; | ||
180 | struct address_space *mapping; | ||
181 | struct list_head *to_do; | ||
182 | ... | ||
183 | }; | ||
184 | |||
185 | A structure of this type is allocated by FS-Cache to record retrieval and | ||
186 | allocation requests made by the netfs. This struct is then passed to the | ||
187 | backend to do the operation. The backend may get extra refs to it by | ||
188 | calling fscache_get_retrieval() and refs may be discarded by calling | ||
189 | fscache_put_retrieval(). | ||
190 | |||
191 | A retrieval operation can be used by the backend to do retrieval work. To | ||
192 | do this, the retrieval->op.processor method pointer should be set | ||
193 | appropriately by the backend and fscache_enqueue_retrieval() called to | ||
194 | submit it to the thread pool. CacheFiles, for example, uses this to queue | ||
195 | page examination when it detects PG_lock being cleared. | ||
196 | |||
197 | The to_do field is an empty list available for the cache backend to use as | ||
198 | it sees fit. | ||
199 | |||
200 | |||
201 | (*) FS-Cache storage operation record: | ||
202 | |||
203 | struct fscache_storage { | ||
204 | struct fscache_operation op; | ||
205 | pgoff_t store_limit; | ||
206 | ... | ||
207 | }; | ||
208 | |||
209 | A structure of this type is allocated by FS-Cache to record outstanding | ||
210 | writes to be made. FS-Cache itself enqueues this operation and invokes | ||
211 | the write_page() method on the object at appropriate times to effect | ||
212 | storage. | ||
213 | |||
214 | |||
215 | ================ | ||
216 | CACHE OPERATIONS | ||
217 | ================ | ||
218 | |||
219 | The cache backend provides FS-Cache with a table of operations that can be | ||
220 | performed on the denizens of the cache. These are held in a structure of type: | ||
221 | |||
222 | struct fscache_cache_ops | ||
223 | |||
224 | (*) Name of cache provider [mandatory]: | ||
225 | |||
226 | const char *name | ||
227 | |||
228 | This isn't strictly an operation, but should be pointed at a string naming | ||
229 | the backend. | ||
230 | |||
231 | |||
232 | (*) Allocate a new object [mandatory]: | ||
233 | |||
234 | struct fscache_object *(*alloc_object)(struct fscache_cache *cache, | ||
235 | struct fscache_cookie *cookie) | ||
236 | |||
237 | This method is used to allocate a cache object representation to back a | ||
238 | cookie in a particular cache. fscache_object_init() should be called on | ||
239 | the object to initialise it prior to returning. | ||
240 | |||
241 | This function may also be used to parse the index key to be used for | ||
242 | multiple lookup calls to turn it into a more convenient form. FS-Cache | ||
243 | will call the lookup_complete() method to allow the cache to release the | ||
244 | form once lookup is complete or aborted. | ||
245 | |||
246 | |||
247 | (*) Look up and create object [mandatory]: | ||
248 | |||
249 | void (*lookup_object)(struct fscache_object *object) | ||
250 | |||
251 | This method is used to look up an object, given that the object is already | ||
252 | allocated and attached to the cookie. This should instantiate that object | ||
253 | in the cache if it can. | ||
254 | |||
255 | The method should call fscache_object_lookup_negative() as soon as | ||
256 | possible if it determines the object doesn't exist in the cache. If the | ||
257 | object is found to exist and the netfs indicates that it is valid then | ||
258 | fscache_obtained_object() should be called once the object is in a | ||
259 | position to have data stored in it. Similarly, fscache_obtained_object() | ||
260 | should also be called once a non-present object has been created. | ||
261 | |||
262 | If a lookup error occurs, fscache_object_lookup_error() should be called | ||
263 | to abort the lookup of that object. | ||
264 | |||
265 | |||
266 | (*) Release lookup data [mandatory]: | ||
267 | |||
268 | void (*lookup_complete)(struct fscache_object *object) | ||
269 | |||
270 | This method is called to ask the cache to release any resources it was | ||
271 | using to perform a lookup. | ||
272 | |||
273 | |||
274 | (*) Increment object refcount [mandatory]: | ||
275 | |||
276 | struct fscache_object *(*grab_object)(struct fscache_object *object) | ||
277 | |||
278 | This method is called to increment the reference count on an object. It | ||
279 | may fail (for instance if the cache is being withdrawn) by returning NULL. | ||
280 | It should return the object pointer if successful. | ||
281 | |||
282 | |||
283 | (*) Lock/Unlock object [mandatory]: | ||
284 | |||
285 | void (*lock_object)(struct fscache_object *object) | ||
286 | void (*unlock_object)(struct fscache_object *object) | ||
287 | |||
288 | These methods are used to exclusively lock an object. It must be possible | ||
289 | to schedule with the lock held, so a spinlock isn't sufficient. | ||
290 | |||
291 | |||
292 | (*) Pin/Unpin object [optional]: | ||
293 | |||
294 | int (*pin_object)(struct fscache_object *object) | ||
295 | void (*unpin_object)(struct fscache_object *object) | ||
296 | |||
297 | These methods are used to pin an object into the cache. Once pinned an | ||
298 | object cannot be reclaimed to make space. Return -ENOSPC if there's not | ||
299 | enough space in the cache to permit this. | ||
300 | |||
301 | |||
302 | (*) Update object [mandatory]: | ||
303 | |||
304 | int (*update_object)(struct fscache_object *object) | ||
305 | |||
306 | This is called to update the index entry for the specified object. The | ||
307 | new information should be in object->cookie->netfs_data. This can be | ||
308 | obtained by calling object->cookie->def->get_aux()/get_attr(). | ||
309 | |||
310 | |||
311 | (*) Discard object [mandatory]: | ||
312 | |||
313 | void (*drop_object)(struct fscache_object *object) | ||
314 | |||
315 | This method is called to indicate that an object has been unbound from its | ||
316 | cookie, and that the cache should release the object's resources and | ||
317 | retire it if it's in state FSCACHE_OBJECT_RECYCLING. | ||
318 | |||
319 | This method should not attempt to release any references held by the | ||
320 | caller. The caller will invoke the put_object() method as appropriate. | ||
321 | |||
322 | |||
323 | (*) Release object reference [mandatory]: | ||
324 | |||
325 | void (*put_object)(struct fscache_object *object) | ||
326 | |||
327 | This method is used to discard a reference to an object. The object may | ||
328 | be freed when all the references to it are released. | ||
329 | |||
330 | |||
331 | (*) Synchronise a cache [mandatory]: | ||
332 | |||
333 | void (*sync)(struct fscache_cache *cache) | ||
334 | |||
335 | This is called to ask the backend to synchronise a cache with its backing | ||
336 | device. | ||
337 | |||
338 | |||
339 | (*) Dissociate a cache [mandatory]: | ||
340 | |||
341 | void (*dissociate_pages)(struct fscache_cache *cache) | ||
342 | |||
343 | This is called to ask a cache to perform any page dissociations as part of | ||
344 | cache withdrawal. | ||
345 | |||
346 | |||
347 | (*) Notification that the attributes on a netfs file changed [mandatory]: | ||
348 | |||
349 | int (*attr_changed)(struct fscache_object *object); | ||
350 | |||
351 | This is called to indicate to the cache that certain attributes on a netfs | ||
352 | file have changed (for example the maximum size a file may reach). The | ||
353 | cache can read these from the netfs by calling the cookie's get_attr() | ||
354 | method. | ||
355 | |||
356 | The cache may use the file size information to reserve space on the cache. | ||
357 | It should also call fscache_set_store_limit() to indicate to FS-Cache the | ||
358 | highest byte it's willing to store for an object. | ||
359 | |||
360 | This method may return -ve if an error occurred or the cache object cannot | ||
361 | be expanded. In such a case, the object will be withdrawn from service. | ||
362 | |||
363 | This operation is run asynchronously from FS-Cache's thread pool, and | ||
364 | storage and retrieval operations from the netfs are excluded during the | ||
365 | execution of this operation. | ||
366 | |||
367 | |||
368 | (*) Reserve cache space for an object's data [optional]: | ||
369 | |||
370 | int (*reserve_space)(struct fscache_object *object, loff_t size); | ||
371 | |||
372 | This is called to request that cache space be reserved to hold the data | ||
373 | for an object and the metadata used to track it. Zero size should be | ||
374 | taken as request to cancel a reservation. | ||
375 | |||
376 | This should return 0 if successful, -ENOSPC if there isn't enough space | ||
377 | available, or -ENOMEM or -EIO on other errors. | ||
378 | |||
379 | The reservation may exceed the current size of the object, thus permitting | ||
380 | future expansion. If the amount of space consumed by an object would | ||
381 | exceed the reservation, it's permitted to refuse requests to allocate | ||
382 | pages, but not required. An object may be pruned down to its reservation | ||
383 | size if larger than that already. | ||
384 | |||
385 | |||
386 | (*) Request page be read from cache [mandatory]: | ||
387 | |||
388 | int (*read_or_alloc_page)(struct fscache_retrieval *op, | ||
389 | struct page *page, | ||
390 | gfp_t gfp) | ||
391 | |||
392 | This is called to attempt to read a netfs page from the cache, or to | ||
393 | reserve a backing block if not. FS-Cache will have done as much checking | ||
394 | as it can before calling, but most of the work belongs to the backend. | ||
395 | |||
396 | If there's no page in the cache, then -ENODATA should be returned if the | ||
397 | backend managed to reserve a backing block; -ENOBUFS or -ENOMEM if it | ||
398 | didn't. | ||
399 | |||
400 | If there is suitable data in the cache, then a read operation should be | ||
401 | queued and 0 returned. When the read finishes, fscache_end_io() should be | ||
402 | called. | ||
403 | |||
404 | The fscache_mark_pages_cached() should be called for the page if any cache | ||
405 | metadata is retained. This will indicate to the netfs that the page needs | ||
406 | explicit uncaching. This operation takes a pagevec, thus allowing several | ||
407 | pages to be marked at once. | ||
408 | |||
409 | The retrieval record pointed to by op should be retained for each page | ||
410 | queued and released when I/O on the page has been formally ended. | ||
411 | fscache_get/put_retrieval() are available for this purpose. | ||
412 | |||
413 | The retrieval record may be used to get CPU time via the FS-Cache thread | ||
414 | pool. If this is desired, the op->op.processor should be set to point to | ||
415 | the appropriate processing routine, and fscache_enqueue_retrieval() should | ||
416 | be called at an appropriate point to request CPU time. For instance, the | ||
417 | retrieval routine could be enqueued upon the completion of a disk read. | ||
418 | The to_do field in the retrieval record is provided to aid in this. | ||
419 | |||
420 | If an I/O error occurs, fscache_io_error() should be called and -ENOBUFS | ||
421 | returned if possible or fscache_end_io() called with a suitable error | ||
422 | code.. | ||
423 | |||
424 | |||
425 | (*) Request pages be read from cache [mandatory]: | ||
426 | |||
427 | int (*read_or_alloc_pages)(struct fscache_retrieval *op, | ||
428 | struct list_head *pages, | ||
429 | unsigned *nr_pages, | ||
430 | gfp_t gfp) | ||
431 | |||
432 | This is like the read_or_alloc_page() method, except it is handed a list | ||
433 | of pages instead of one page. Any pages on which a read operation is | ||
434 | started must be added to the page cache for the specified mapping and also | ||
435 | to the LRU. Such pages must also be removed from the pages list and | ||
436 | *nr_pages decremented per page. | ||
437 | |||
438 | If there was an error such as -ENOMEM, then that should be returned; else | ||
439 | if one or more pages couldn't be read or allocated, then -ENOBUFS should | ||
440 | be returned; else if one or more pages couldn't be read, then -ENODATA | ||
441 | should be returned. If all the pages are dispatched then 0 should be | ||
442 | returned. | ||
443 | |||
444 | |||
445 | (*) Request page be allocated in the cache [mandatory]: | ||
446 | |||
447 | int (*allocate_page)(struct fscache_retrieval *op, | ||
448 | struct page *page, | ||
449 | gfp_t gfp) | ||
450 | |||
451 | This is like the read_or_alloc_page() method, except that it shouldn't | ||
452 | read from the cache, even if there's data there that could be retrieved. | ||
453 | It should, however, set up any internal metadata required such that | ||
454 | the write_page() method can write to the cache. | ||
455 | |||
456 | If there's no backing block available, then -ENOBUFS should be returned | ||
457 | (or -ENOMEM if there were other problems). If a block is successfully | ||
458 | allocated, then the netfs page should be marked and 0 returned. | ||
459 | |||
460 | |||
461 | (*) Request pages be allocated in the cache [mandatory]: | ||
462 | |||
463 | int (*allocate_pages)(struct fscache_retrieval *op, | ||
464 | struct list_head *pages, | ||
465 | unsigned *nr_pages, | ||
466 | gfp_t gfp) | ||
467 | |||
468 | This is an multiple page version of the allocate_page() method. pages and | ||
469 | nr_pages should be treated as for the read_or_alloc_pages() method. | ||
470 | |||
471 | |||
472 | (*) Request page be written to cache [mandatory]: | ||
473 | |||
474 | int (*write_page)(struct fscache_storage *op, | ||
475 | struct page *page); | ||
476 | |||
477 | This is called to write from a page on which there was a previously | ||
478 | successful read_or_alloc_page() call or similar. FS-Cache filters out | ||
479 | pages that don't have mappings. | ||
480 | |||
481 | This method is called asynchronously from the FS-Cache thread pool. It is | ||
482 | not required to actually store anything, provided -ENODATA is then | ||
483 | returned to the next read of this page. | ||
484 | |||
485 | If an error occurred, then a negative error code should be returned, | ||
486 | otherwise zero should be returned. FS-Cache will take appropriate action | ||
487 | in response to an error, such as withdrawing this object. | ||
488 | |||
489 | If this method returns success then FS-Cache will inform the netfs | ||
490 | appropriately. | ||
491 | |||
492 | |||
493 | (*) Discard retained per-page metadata [mandatory]: | ||
494 | |||
495 | void (*uncache_page)(struct fscache_object *object, struct page *page) | ||
496 | |||
497 | This is called when a netfs page is being evicted from the pagecache. The | ||
498 | cache backend should tear down any internal representation or tracking it | ||
499 | maintains for this page. | ||
500 | |||
501 | |||
502 | ================== | ||
503 | FS-CACHE UTILITIES | ||
504 | ================== | ||
505 | |||
506 | FS-Cache provides some utilities that a cache backend may make use of: | ||
507 | |||
508 | (*) Note occurrence of an I/O error in a cache: | ||
509 | |||
510 | void fscache_io_error(struct fscache_cache *cache) | ||
511 | |||
512 | This tells FS-Cache that an I/O error occurred in the cache. After this | ||
513 | has been called, only resource dissociation operations (object and page | ||
514 | release) will be passed from the netfs to the cache backend for the | ||
515 | specified cache. | ||
516 | |||
517 | This does not actually withdraw the cache. That must be done separately. | ||
518 | |||
519 | |||
520 | (*) Invoke the retrieval I/O completion function: | ||
521 | |||
522 | void fscache_end_io(struct fscache_retrieval *op, struct page *page, | ||
523 | int error); | ||
524 | |||
525 | This is called to note the end of an attempt to retrieve a page. The | ||
526 | error value should be 0 if successful and an error otherwise. | ||
527 | |||
528 | |||
529 | (*) Set highest store limit: | ||
530 | |||
531 | void fscache_set_store_limit(struct fscache_object *object, | ||
532 | loff_t i_size); | ||
533 | |||
534 | This sets the limit FS-Cache imposes on the highest byte it's willing to | ||
535 | try and store for a netfs. Any page over this limit is automatically | ||
536 | rejected by fscache_read_alloc_page() and co with -ENOBUFS. | ||
537 | |||
538 | |||
539 | (*) Mark pages as being cached: | ||
540 | |||
541 | void fscache_mark_pages_cached(struct fscache_retrieval *op, | ||
542 | struct pagevec *pagevec); | ||
543 | |||
544 | This marks a set of pages as being cached. After this has been called, | ||
545 | the netfs must call fscache_uncache_page() to unmark the pages. | ||
546 | |||
547 | |||
548 | (*) Perform coherency check on an object: | ||
549 | |||
550 | enum fscache_checkaux fscache_check_aux(struct fscache_object *object, | ||
551 | const void *data, | ||
552 | uint16_t datalen); | ||
553 | |||
554 | This asks the netfs to perform a coherency check on an object that has | ||
555 | just been looked up. The cookie attached to the object will determine the | ||
556 | netfs to use. data and datalen should specify where the auxiliary data | ||
557 | retrieved from the cache can be found. | ||
558 | |||
559 | One of three values will be returned: | ||
560 | |||
561 | (*) FSCACHE_CHECKAUX_OKAY | ||
562 | |||
563 | The coherency data indicates the object is valid as is. | ||
564 | |||
565 | (*) FSCACHE_CHECKAUX_NEEDS_UPDATE | ||
566 | |||
567 | The coherency data needs updating, but otherwise the object is | ||
568 | valid. | ||
569 | |||
570 | (*) FSCACHE_CHECKAUX_OBSOLETE | ||
571 | |||
572 | The coherency data indicates that the object is obsolete and should | ||
573 | be discarded. | ||
574 | |||
575 | |||
576 | (*) Initialise a freshly allocated object: | ||
577 | |||
578 | void fscache_object_init(struct fscache_object *object); | ||
579 | |||
580 | This initialises all the fields in an object representation. | ||
581 | |||
582 | |||
583 | (*) Indicate the destruction of an object: | ||
584 | |||
585 | void fscache_object_destroyed(struct fscache_cache *cache); | ||
586 | |||
587 | This must be called to inform FS-Cache that an object that belonged to a | ||
588 | cache has been destroyed and deallocated. This will allow continuation | ||
589 | of the cache withdrawal process when it is stopped pending destruction of | ||
590 | all the objects. | ||
591 | |||
592 | |||
593 | (*) Indicate negative lookup on an object: | ||
594 | |||
595 | void fscache_object_lookup_negative(struct fscache_object *object); | ||
596 | |||
597 | This is called to indicate to FS-Cache that a lookup process for an object | ||
598 | found a negative result. | ||
599 | |||
600 | This changes the state of an object to permit reads pending on lookup | ||
601 | completion to go off and start fetching data from the netfs server as it's | ||
602 | known at this point that there can't be any data in the cache. | ||
603 | |||
604 | This may be called multiple times on an object. Only the first call is | ||
605 | significant - all subsequent calls are ignored. | ||
606 | |||
607 | |||
608 | (*) Indicate an object has been obtained: | ||
609 | |||
610 | void fscache_obtained_object(struct fscache_object *object); | ||
611 | |||
612 | This is called to indicate to FS-Cache that a lookup process for an object | ||
613 | produced a positive result, or that an object was created. This should | ||
614 | only be called once for any particular object. | ||
615 | |||
616 | This changes the state of an object to indicate: | ||
617 | |||
618 | (1) if no call to fscache_object_lookup_negative() has been made on | ||
619 | this object, that there may be data available, and that reads can | ||
620 | now go and look for it; and | ||
621 | |||
622 | (2) that writes may now proceed against this object. | ||
623 | |||
624 | |||
625 | (*) Indicate that object lookup failed: | ||
626 | |||
627 | void fscache_object_lookup_error(struct fscache_object *object); | ||
628 | |||
629 | This marks an object as having encountered a fatal error (usually EIO) | ||
630 | and causes it to move into a state whereby it will be withdrawn as soon | ||
631 | as possible. | ||
632 | |||
633 | |||
634 | (*) Get and release references on a retrieval record: | ||
635 | |||
636 | void fscache_get_retrieval(struct fscache_retrieval *op); | ||
637 | void fscache_put_retrieval(struct fscache_retrieval *op); | ||
638 | |||
639 | These two functions are used to retain a retrieval record whilst doing | ||
640 | asynchronous data retrieval and block allocation. | ||
641 | |||
642 | |||
643 | (*) Enqueue a retrieval record for processing. | ||
644 | |||
645 | void fscache_enqueue_retrieval(struct fscache_retrieval *op); | ||
646 | |||
647 | This enqueues a retrieval record for processing by the FS-Cache thread | ||
648 | pool. One of the threads in the pool will invoke the retrieval record's | ||
649 | op->op.processor callback function. This function may be called from | ||
650 | within the callback function. | ||
651 | |||
652 | |||
653 | (*) List of object state names: | ||
654 | |||
655 | const char *fscache_object_states[]; | ||
656 | |||
657 | For debugging purposes, this may be used to turn the state that an object | ||
658 | is in into a text string for display purposes. | ||
diff --git a/Documentation/filesystems/caching/cachefiles.txt b/Documentation/filesystems/caching/cachefiles.txt new file mode 100644 index 000000000000..c78a49b7bba6 --- /dev/null +++ b/Documentation/filesystems/caching/cachefiles.txt | |||
@@ -0,0 +1,501 @@ | |||
1 | =============================================== | ||
2 | CacheFiles: CACHE ON ALREADY MOUNTED FILESYSTEM | ||
3 | =============================================== | ||
4 | |||
5 | Contents: | ||
6 | |||
7 | (*) Overview. | ||
8 | |||
9 | (*) Requirements. | ||
10 | |||
11 | (*) Configuration. | ||
12 | |||
13 | (*) Starting the cache. | ||
14 | |||
15 | (*) Things to avoid. | ||
16 | |||
17 | (*) Cache culling. | ||
18 | |||
19 | (*) Cache structure. | ||
20 | |||
21 | (*) Security model and SELinux. | ||
22 | |||
23 | (*) A note on security. | ||
24 | |||
25 | (*) Statistical information. | ||
26 | |||
27 | (*) Debugging. | ||
28 | |||
29 | |||
30 | ======== | ||
31 | OVERVIEW | ||
32 | ======== | ||
33 | |||
34 | CacheFiles is a caching backend that's meant to use as a cache a directory on | ||
35 | an already mounted filesystem of a local type (such as Ext3). | ||
36 | |||
37 | CacheFiles uses a userspace daemon to do some of the cache management - such as | ||
38 | reaping stale nodes and culling. This is called cachefilesd and lives in | ||
39 | /sbin. | ||
40 | |||
41 | The filesystem and data integrity of the cache are only as good as those of the | ||
42 | filesystem providing the backing services. Note that CacheFiles does not | ||
43 | attempt to journal anything since the journalling interfaces of the various | ||
44 | filesystems are very specific in nature. | ||
45 | |||
46 | CacheFiles creates a misc character device - "/dev/cachefiles" - that is used | ||
47 | to communication with the daemon. Only one thing may have this open at once, | ||
48 | and whilst it is open, a cache is at least partially in existence. The daemon | ||
49 | opens this and sends commands down it to control the cache. | ||
50 | |||
51 | CacheFiles is currently limited to a single cache. | ||
52 | |||
53 | CacheFiles attempts to maintain at least a certain percentage of free space on | ||
54 | the filesystem, shrinking the cache by culling the objects it contains to make | ||
55 | space if necessary - see the "Cache Culling" section. This means it can be | ||
56 | placed on the same medium as a live set of data, and will expand to make use of | ||
57 | spare space and automatically contract when the set of data requires more | ||
58 | space. | ||
59 | |||
60 | |||
61 | ============ | ||
62 | REQUIREMENTS | ||
63 | ============ | ||
64 | |||
65 | The use of CacheFiles and its daemon requires the following features to be | ||
66 | available in the system and in the cache filesystem: | ||
67 | |||
68 | - dnotify. | ||
69 | |||
70 | - extended attributes (xattrs). | ||
71 | |||
72 | - openat() and friends. | ||
73 | |||
74 | - bmap() support on files in the filesystem (FIBMAP ioctl). | ||
75 | |||
76 | - The use of bmap() to detect a partial page at the end of the file. | ||
77 | |||
78 | It is strongly recommended that the "dir_index" option is enabled on Ext3 | ||
79 | filesystems being used as a cache. | ||
80 | |||
81 | |||
82 | ============= | ||
83 | CONFIGURATION | ||
84 | ============= | ||
85 | |||
86 | The cache is configured by a script in /etc/cachefilesd.conf. These commands | ||
87 | set up cache ready for use. The following script commands are available: | ||
88 | |||
89 | (*) brun <N>% | ||
90 | (*) bcull <N>% | ||
91 | (*) bstop <N>% | ||
92 | (*) frun <N>% | ||
93 | (*) fcull <N>% | ||
94 | (*) fstop <N>% | ||
95 | |||
96 | Configure the culling limits. Optional. See the section on culling | ||
97 | The defaults are 7% (run), 5% (cull) and 1% (stop) respectively. | ||
98 | |||
99 | The commands beginning with a 'b' are file space (block) limits, those | ||
100 | beginning with an 'f' are file count limits. | ||
101 | |||
102 | (*) dir <path> | ||
103 | |||
104 | Specify the directory containing the root of the cache. Mandatory. | ||
105 | |||
106 | (*) tag <name> | ||
107 | |||
108 | Specify a tag to FS-Cache to use in distinguishing multiple caches. | ||
109 | Optional. The default is "CacheFiles". | ||
110 | |||
111 | (*) debug <mask> | ||
112 | |||
113 | Specify a numeric bitmask to control debugging in the kernel module. | ||
114 | Optional. The default is zero (all off). The following values can be | ||
115 | OR'd into the mask to collect various information: | ||
116 | |||
117 | 1 Turn on trace of function entry (_enter() macros) | ||
118 | 2 Turn on trace of function exit (_leave() macros) | ||
119 | 4 Turn on trace of internal debug points (_debug()) | ||
120 | |||
121 | This mask can also be set through sysfs, eg: | ||
122 | |||
123 | echo 5 >/sys/modules/cachefiles/parameters/debug | ||
124 | |||
125 | |||
126 | ================== | ||
127 | STARTING THE CACHE | ||
128 | ================== | ||
129 | |||
130 | The cache is started by running the daemon. The daemon opens the cache device, | ||
131 | configures the cache and tells it to begin caching. At that point the cache | ||
132 | binds to fscache and the cache becomes live. | ||
133 | |||
134 | The daemon is run as follows: | ||
135 | |||
136 | /sbin/cachefilesd [-d]* [-s] [-n] [-f <configfile>] | ||
137 | |||
138 | The flags are: | ||
139 | |||
140 | (*) -d | ||
141 | |||
142 | Increase the debugging level. This can be specified multiple times and | ||
143 | is cumulative with itself. | ||
144 | |||
145 | (*) -s | ||
146 | |||
147 | Send messages to stderr instead of syslog. | ||
148 | |||
149 | (*) -n | ||
150 | |||
151 | Don't daemonise and go into background. | ||
152 | |||
153 | (*) -f <configfile> | ||
154 | |||
155 | Use an alternative configuration file rather than the default one. | ||
156 | |||
157 | |||
158 | =============== | ||
159 | THINGS TO AVOID | ||
160 | =============== | ||
161 | |||
162 | Do not mount other things within the cache as this will cause problems. The | ||
163 | kernel module contains its own very cut-down path walking facility that ignores | ||
164 | mountpoints, but the daemon can't avoid them. | ||
165 | |||
166 | Do not create, rename or unlink files and directories in the cache whilst the | ||
167 | cache is active, as this may cause the state to become uncertain. | ||
168 | |||
169 | Renaming files in the cache might make objects appear to be other objects (the | ||
170 | filename is part of the lookup key). | ||
171 | |||
172 | Do not change or remove the extended attributes attached to cache files by the | ||
173 | cache as this will cause the cache state management to get confused. | ||
174 | |||
175 | Do not create files or directories in the cache, lest the cache get confused or | ||
176 | serve incorrect data. | ||
177 | |||
178 | Do not chmod files in the cache. The module creates things with minimal | ||
179 | permissions to prevent random users being able to access them directly. | ||
180 | |||
181 | |||
182 | ============= | ||
183 | CACHE CULLING | ||
184 | ============= | ||
185 | |||
186 | The cache may need culling occasionally to make space. This involves | ||
187 | discarding objects from the cache that have been used less recently than | ||
188 | anything else. Culling is based on the access time of data objects. Empty | ||
189 | directories are culled if not in use. | ||
190 | |||
191 | Cache culling is done on the basis of the percentage of blocks and the | ||
192 | percentage of files available in the underlying filesystem. There are six | ||
193 | "limits": | ||
194 | |||
195 | (*) brun | ||
196 | (*) frun | ||
197 | |||
198 | If the amount of free space and the number of available files in the cache | ||
199 | rises above both these limits, then culling is turned off. | ||
200 | |||
201 | (*) bcull | ||
202 | (*) fcull | ||
203 | |||
204 | If the amount of available space or the number of available files in the | ||
205 | cache falls below either of these limits, then culling is started. | ||
206 | |||
207 | (*) bstop | ||
208 | (*) fstop | ||
209 | |||
210 | If the amount of available space or the number of available files in the | ||
211 | cache falls below either of these limits, then no further allocation of | ||
212 | disk space or files is permitted until culling has raised things above | ||
213 | these limits again. | ||
214 | |||
215 | These must be configured thusly: | ||
216 | |||
217 | 0 <= bstop < bcull < brun < 100 | ||
218 | 0 <= fstop < fcull < frun < 100 | ||
219 | |||
220 | Note that these are percentages of available space and available files, and do | ||
221 | _not_ appear as 100 minus the percentage displayed by the "df" program. | ||
222 | |||
223 | The userspace daemon scans the cache to build up a table of cullable objects. | ||
224 | These are then culled in least recently used order. A new scan of the cache is | ||
225 | started as soon as space is made in the table. Objects will be skipped if | ||
226 | their atimes have changed or if the kernel module says it is still using them. | ||
227 | |||
228 | |||
229 | =============== | ||
230 | CACHE STRUCTURE | ||
231 | =============== | ||
232 | |||
233 | The CacheFiles module will create two directories in the directory it was | ||
234 | given: | ||
235 | |||
236 | (*) cache/ | ||
237 | |||
238 | (*) graveyard/ | ||
239 | |||
240 | The active cache objects all reside in the first directory. The CacheFiles | ||
241 | kernel module moves any retired or culled objects that it can't simply unlink | ||
242 | to the graveyard from which the daemon will actually delete them. | ||
243 | |||
244 | The daemon uses dnotify to monitor the graveyard directory, and will delete | ||
245 | anything that appears therein. | ||
246 | |||
247 | |||
248 | The module represents index objects as directories with the filename "I..." or | ||
249 | "J...". Note that the "cache/" directory is itself a special index. | ||
250 | |||
251 | Data objects are represented as files if they have no children, or directories | ||
252 | if they do. Their filenames all begin "D..." or "E...". If represented as a | ||
253 | directory, data objects will have a file in the directory called "data" that | ||
254 | actually holds the data. | ||
255 | |||
256 | Special objects are similar to data objects, except their filenames begin | ||
257 | "S..." or "T...". | ||
258 | |||
259 | |||
260 | If an object has children, then it will be represented as a directory. | ||
261 | Immediately in the representative directory are a collection of directories | ||
262 | named for hash values of the child object keys with an '@' prepended. Into | ||
263 | this directory, if possible, will be placed the representations of the child | ||
264 | objects: | ||
265 | |||
266 | INDEX INDEX INDEX DATA FILES | ||
267 | ========= ========== ================================= ================ | ||
268 | cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400 | ||
269 | cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...DB1ry | ||
270 | cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...N22ry | ||
271 | cache/@4a/I03nfs/@30/Ji000000000000000--fHg8hi8400/@75/Es0g000w...FP1ry | ||
272 | |||
273 | |||
274 | If the key is so long that it exceeds NAME_MAX with the decorations added on to | ||
275 | it, then it will be cut into pieces, the first few of which will be used to | ||
276 | make a nest of directories, and the last one of which will be the objects | ||
277 | inside the last directory. The names of the intermediate directories will have | ||
278 | '+' prepended: | ||
279 | |||
280 | J1223/@23/+xy...z/+kl...m/Epqr | ||
281 | |||
282 | |||
283 | Note that keys are raw data, and not only may they exceed NAME_MAX in size, | ||
284 | they may also contain things like '/' and NUL characters, and so they may not | ||
285 | be suitable for turning directly into a filename. | ||
286 | |||
287 | To handle this, CacheFiles will use a suitably printable filename directly and | ||
288 | "base-64" encode ones that aren't directly suitable. The two versions of | ||
289 | object filenames indicate the encoding: | ||
290 | |||
291 | OBJECT TYPE PRINTABLE ENCODED | ||
292 | =============== =============== =============== | ||
293 | Index "I..." "J..." | ||
294 | Data "D..." "E..." | ||
295 | Special "S..." "T..." | ||
296 | |||
297 | Intermediate directories are always "@" or "+" as appropriate. | ||
298 | |||
299 | |||
300 | Each object in the cache has an extended attribute label that holds the object | ||
301 | type ID (required to distinguish special objects) and the auxiliary data from | ||
302 | the netfs. The latter is used to detect stale objects in the cache and update | ||
303 | or retire them. | ||
304 | |||
305 | |||
306 | Note that CacheFiles will erase from the cache any file it doesn't recognise or | ||
307 | any file of an incorrect type (such as a FIFO file or a device file). | ||
308 | |||
309 | |||
310 | ========================== | ||
311 | SECURITY MODEL AND SELINUX | ||
312 | ========================== | ||
313 | |||
314 | CacheFiles is implemented to deal properly with the LSM security features of | ||
315 | the Linux kernel and the SELinux facility. | ||
316 | |||
317 | One of the problems that CacheFiles faces is that it is generally acting on | ||
318 | behalf of a process, and running in that process's context, and that includes a | ||
319 | security context that is not appropriate for accessing the cache - either | ||
320 | because the files in the cache are inaccessible to that process, or because if | ||
321 | the process creates a file in the cache, that file may be inaccessible to other | ||
322 | processes. | ||
323 | |||
324 | The way CacheFiles works is to temporarily change the security context (fsuid, | ||
325 | fsgid and actor security label) that the process acts as - without changing the | ||
326 | security context of the process when it the target of an operation performed by | ||
327 | some other process (so signalling and suchlike still work correctly). | ||
328 | |||
329 | |||
330 | When the CacheFiles module is asked to bind to its cache, it: | ||
331 | |||
332 | (1) Finds the security label attached to the root cache directory and uses | ||
333 | that as the security label with which it will create files. By default, | ||
334 | this is: | ||
335 | |||
336 | cachefiles_var_t | ||
337 | |||
338 | (2) Finds the security label of the process which issued the bind request | ||
339 | (presumed to be the cachefilesd daemon), which by default will be: | ||
340 | |||
341 | cachefilesd_t | ||
342 | |||
343 | and asks LSM to supply a security ID as which it should act given the | ||
344 | daemon's label. By default, this will be: | ||
345 | |||
346 | cachefiles_kernel_t | ||
347 | |||
348 | SELinux transitions the daemon's security ID to the module's security ID | ||
349 | based on a rule of this form in the policy. | ||
350 | |||
351 | type_transition <daemon's-ID> kernel_t : process <module's-ID>; | ||
352 | |||
353 | For instance: | ||
354 | |||
355 | type_transition cachefilesd_t kernel_t : process cachefiles_kernel_t; | ||
356 | |||
357 | |||
358 | The module's security ID gives it permission to create, move and remove files | ||
359 | and directories in the cache, to find and access directories and files in the | ||
360 | cache, to set and access extended attributes on cache objects, and to read and | ||
361 | write files in the cache. | ||
362 | |||
363 | The daemon's security ID gives it only a very restricted set of permissions: it | ||
364 | may scan directories, stat files and erase files and directories. It may | ||
365 | not read or write files in the cache, and so it is precluded from accessing the | ||
366 | data cached therein; nor is it permitted to create new files in the cache. | ||
367 | |||
368 | |||
369 | There are policy source files available in: | ||
370 | |||
371 | http://people.redhat.com/~dhowells/fscache/cachefilesd-0.8.tar.bz2 | ||
372 | |||
373 | and later versions. In that tarball, see the files: | ||
374 | |||
375 | cachefilesd.te | ||
376 | cachefilesd.fc | ||
377 | cachefilesd.if | ||
378 | |||
379 | They are built and installed directly by the RPM. | ||
380 | |||
381 | If a non-RPM based system is being used, then copy the above files to their own | ||
382 | directory and run: | ||
383 | |||
384 | make -f /usr/share/selinux/devel/Makefile | ||
385 | semodule -i cachefilesd.pp | ||
386 | |||
387 | You will need checkpolicy and selinux-policy-devel installed prior to the | ||
388 | build. | ||
389 | |||
390 | |||
391 | By default, the cache is located in /var/fscache, but if it is desirable that | ||
392 | it should be elsewhere, than either the above policy files must be altered, or | ||
393 | an auxiliary policy must be installed to label the alternate location of the | ||
394 | cache. | ||
395 | |||
396 | For instructions on how to add an auxiliary policy to enable the cache to be | ||
397 | located elsewhere when SELinux is in enforcing mode, please see: | ||
398 | |||
399 | /usr/share/doc/cachefilesd-*/move-cache.txt | ||
400 | |||
401 | When the cachefilesd rpm is installed; alternatively, the document can be found | ||
402 | in the sources. | ||
403 | |||
404 | |||
405 | ================== | ||
406 | A NOTE ON SECURITY | ||
407 | ================== | ||
408 | |||
409 | CacheFiles makes use of the split security in the task_struct. It allocates | ||
410 | its own task_security structure, and redirects current->act_as to point to it | ||
411 | when it acts on behalf of another process, in that process's context. | ||
412 | |||
413 | The reason it does this is that it calls vfs_mkdir() and suchlike rather than | ||
414 | bypassing security and calling inode ops directly. Therefore the VFS and LSM | ||
415 | may deny the CacheFiles access to the cache data because under some | ||
416 | circumstances the caching code is running in the security context of whatever | ||
417 | process issued the original syscall on the netfs. | ||
418 | |||
419 | Furthermore, should CacheFiles create a file or directory, the security | ||
420 | parameters with that object is created (UID, GID, security label) would be | ||
421 | derived from that process that issued the system call, thus potentially | ||
422 | preventing other processes from accessing the cache - including CacheFiles's | ||
423 | cache management daemon (cachefilesd). | ||
424 | |||
425 | What is required is to temporarily override the security of the process that | ||
426 | issued the system call. We can't, however, just do an in-place change of the | ||
427 | security data as that affects the process as an object, not just as a subject. | ||
428 | This means it may lose signals or ptrace events for example, and affects what | ||
429 | the process looks like in /proc. | ||
430 | |||
431 | So CacheFiles makes use of a logical split in the security between the | ||
432 | objective security (task->sec) and the subjective security (task->act_as). The | ||
433 | objective security holds the intrinsic security properties of a process and is | ||
434 | never overridden. This is what appears in /proc, and is what is used when a | ||
435 | process is the target of an operation by some other process (SIGKILL for | ||
436 | example). | ||
437 | |||
438 | The subjective security holds the active security properties of a process, and | ||
439 | may be overridden. This is not seen externally, and is used whan a process | ||
440 | acts upon another object, for example SIGKILLing another process or opening a | ||
441 | file. | ||
442 | |||
443 | LSM hooks exist that allow SELinux (or Smack or whatever) to reject a request | ||
444 | for CacheFiles to run in a context of a specific security label, or to create | ||
445 | files and directories with another security label. | ||
446 | |||
447 | |||
448 | ======================= | ||
449 | STATISTICAL INFORMATION | ||
450 | ======================= | ||
451 | |||
452 | If FS-Cache is compiled with the following option enabled: | ||
453 | |||
454 | CONFIG_CACHEFILES_HISTOGRAM=y | ||
455 | |||
456 | then it will gather certain statistics and display them through a proc file. | ||
457 | |||
458 | (*) /proc/fs/cachefiles/histogram | ||
459 | |||
460 | cat /proc/fs/cachefiles/histogram | ||
461 | JIFS SECS LOOKUPS MKDIRS CREATES | ||
462 | ===== ===== ========= ========= ========= | ||
463 | |||
464 | This shows the breakdown of the number of times each amount of time | ||
465 | between 0 jiffies and HZ-1 jiffies a variety of tasks took to run. The | ||
466 | columns are as follows: | ||
467 | |||
468 | COLUMN TIME MEASUREMENT | ||
469 | ======= ======================================================= | ||
470 | LOOKUPS Length of time to perform a lookup on the backing fs | ||
471 | MKDIRS Length of time to perform a mkdir on the backing fs | ||
472 | CREATES Length of time to perform a create on the backing fs | ||
473 | |||
474 | Each row shows the number of events that took a particular range of times. | ||
475 | Each step is 1 jiffy in size. The JIFS column indicates the particular | ||
476 | jiffy range covered, and the SECS field the equivalent number of seconds. | ||
477 | |||
478 | |||
479 | ========= | ||
480 | DEBUGGING | ||
481 | ========= | ||
482 | |||
483 | If CONFIG_CACHEFILES_DEBUG is enabled, the CacheFiles facility can have runtime | ||
484 | debugging enabled by adjusting the value in: | ||
485 | |||
486 | /sys/module/cachefiles/parameters/debug | ||
487 | |||
488 | This is a bitmask of debugging streams to enable: | ||
489 | |||
490 | BIT VALUE STREAM POINT | ||
491 | ======= ======= =============================== ======================= | ||
492 | 0 1 General Function entry trace | ||
493 | 1 2 Function exit trace | ||
494 | 2 4 General | ||
495 | |||
496 | The appropriate set of values should be OR'd together and the result written to | ||
497 | the control file. For example: | ||
498 | |||
499 | echo $((1|4|8)) >/sys/module/cachefiles/parameters/debug | ||
500 | |||
501 | will turn on all function entry debugging. | ||
diff --git a/Documentation/filesystems/caching/fscache.txt b/Documentation/filesystems/caching/fscache.txt new file mode 100644 index 000000000000..9e94b9491d89 --- /dev/null +++ b/Documentation/filesystems/caching/fscache.txt | |||
@@ -0,0 +1,333 @@ | |||
1 | ========================== | ||
2 | General Filesystem Caching | ||
3 | ========================== | ||
4 | |||
5 | ======== | ||
6 | OVERVIEW | ||
7 | ======== | ||
8 | |||
9 | This facility is a general purpose cache for network filesystems, though it | ||
10 | could be used for caching other things such as ISO9660 filesystems too. | ||
11 | |||
12 | FS-Cache mediates between cache backends (such as CacheFS) and network | ||
13 | filesystems: | ||
14 | |||
15 | +---------+ | ||
16 | | | +--------------+ | ||
17 | | NFS |--+ | | | ||
18 | | | | +-->| CacheFS | | ||
19 | +---------+ | +----------+ | | /dev/hda5 | | ||
20 | | | | | +--------------+ | ||
21 | +---------+ +-->| | | | ||
22 | | | | |--+ | ||
23 | | AFS |----->| FS-Cache | | ||
24 | | | | |--+ | ||
25 | +---------+ +-->| | | | ||
26 | | | | | +--------------+ | ||
27 | +---------+ | +----------+ | | | | ||
28 | | | | +-->| CacheFiles | | ||
29 | | ISOFS |--+ | /var/cache | | ||
30 | | | +--------------+ | ||
31 | +---------+ | ||
32 | |||
33 | Or to look at it another way, FS-Cache is a module that provides a caching | ||
34 | facility to a network filesystem such that the cache is transparent to the | ||
35 | user: | ||
36 | |||
37 | +---------+ | ||
38 | | | | ||
39 | | Server | | ||
40 | | | | ||
41 | +---------+ | ||
42 | | NETWORK | ||
43 | ~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
44 | | | ||
45 | | +----------+ | ||
46 | V | | | ||
47 | +---------+ | | | ||
48 | | | | | | ||
49 | | NFS |----->| FS-Cache | | ||
50 | | | | |--+ | ||
51 | +---------+ | | | +--------------+ +--------------+ | ||
52 | | | | | | | | | | ||
53 | V +----------+ +-->| CacheFiles |-->| Ext3 | | ||
54 | +---------+ | /var/cache | | /dev/sda6 | | ||
55 | | | +--------------+ +--------------+ | ||
56 | | VFS | ^ ^ | ||
57 | | | | | | ||
58 | +---------+ +--------------+ | | ||
59 | | KERNEL SPACE | | | ||
60 | ~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~|~~~~ | ||
61 | | USER SPACE | | | ||
62 | V | | | ||
63 | +---------+ +--------------+ | ||
64 | | | | | | ||
65 | | Process | | cachefilesd | | ||
66 | | | | | | ||
67 | +---------+ +--------------+ | ||
68 | |||
69 | |||
70 | FS-Cache does not follow the idea of completely loading every netfs file | ||
71 | opened in its entirety into a cache before permitting it to be accessed and | ||
72 | then serving the pages out of that cache rather than the netfs inode because: | ||
73 | |||
74 | (1) It must be practical to operate without a cache. | ||
75 | |||
76 | (2) The size of any accessible file must not be limited to the size of the | ||
77 | cache. | ||
78 | |||
79 | (3) The combined size of all opened files (this includes mapped libraries) | ||
80 | must not be limited to the size of the cache. | ||
81 | |||
82 | (4) The user should not be forced to download an entire file just to do a | ||
83 | one-off access of a small portion of it (such as might be done with the | ||
84 | "file" program). | ||
85 | |||
86 | It instead serves the cache out in PAGE_SIZE chunks as and when requested by | ||
87 | the netfs('s) using it. | ||
88 | |||
89 | |||
90 | FS-Cache provides the following facilities: | ||
91 | |||
92 | (1) More than one cache can be used at once. Caches can be selected | ||
93 | explicitly by use of tags. | ||
94 | |||
95 | (2) Caches can be added / removed at any time. | ||
96 | |||
97 | (3) The netfs is provided with an interface that allows either party to | ||
98 | withdraw caching facilities from a file (required for (2)). | ||
99 | |||
100 | (4) The interface to the netfs returns as few errors as possible, preferring | ||
101 | rather to let the netfs remain oblivious. | ||
102 | |||
103 | (5) Cookies are used to represent indices, files and other objects to the | ||
104 | netfs. The simplest cookie is just a NULL pointer - indicating nothing | ||
105 | cached there. | ||
106 | |||
107 | (6) The netfs is allowed to propose - dynamically - any index hierarchy it | ||
108 | desires, though it must be aware that the index search function is | ||
109 | recursive, stack space is limited, and indices can only be children of | ||
110 | indices. | ||
111 | |||
112 | (7) Data I/O is done direct to and from the netfs's pages. The netfs | ||
113 | indicates that page A is at index B of the data-file represented by cookie | ||
114 | C, and that it should be read or written. The cache backend may or may | ||
115 | not start I/O on that page, but if it does, a netfs callback will be | ||
116 | invoked to indicate completion. The I/O may be either synchronous or | ||
117 | asynchronous. | ||
118 | |||
119 | (8) Cookies can be "retired" upon release. At this point FS-Cache will mark | ||
120 | them as obsolete and the index hierarchy rooted at that point will get | ||
121 | recycled. | ||
122 | |||
123 | (9) The netfs provides a "match" function for index searches. In addition to | ||
124 | saying whether a match was made or not, this can also specify that an | ||
125 | entry should be updated or deleted. | ||
126 | |||
127 | (10) As much as possible is done asynchronously. | ||
128 | |||
129 | |||
130 | FS-Cache maintains a virtual indexing tree in which all indices, files, objects | ||
131 | and pages are kept. Bits of this tree may actually reside in one or more | ||
132 | caches. | ||
133 | |||
134 | FSDEF | ||
135 | | | ||
136 | +------------------------------------+ | ||
137 | | | | ||
138 | NFS AFS | ||
139 | | | | ||
140 | +--------------------------+ +-----------+ | ||
141 | | | | | | ||
142 | homedir mirror afs.org redhat.com | ||
143 | | | | | ||
144 | +------------+ +---------------+ +----------+ | ||
145 | | | | | | | | ||
146 | 00001 00002 00007 00125 vol00001 vol00002 | ||
147 | | | | | | | ||
148 | +---+---+ +-----+ +---+ +------+------+ +-----+----+ | ||
149 | | | | | | | | | | | | | | | ||
150 | PG0 PG1 PG2 PG0 XATTR PG0 PG1 DIRENT DIRENT DIRENT R/W R/O Bak | ||
151 | | | | ||
152 | PG0 +-------+ | ||
153 | | | | ||
154 | 00001 00003 | ||
155 | | | ||
156 | +---+---+ | ||
157 | | | | | ||
158 | PG0 PG1 PG2 | ||
159 | |||
160 | In the example above, you can see two netfs's being backed: NFS and AFS. These | ||
161 | have different index hierarchies: | ||
162 | |||
163 | (*) The NFS primary index contains per-server indices. Each server index is | ||
164 | indexed by NFS file handles to get data file objects. Each data file | ||
165 | objects can have an array of pages, but may also have further child | ||
166 | objects, such as extended attributes and directory entries. Extended | ||
167 | attribute objects themselves have page-array contents. | ||
168 | |||
169 | (*) The AFS primary index contains per-cell indices. Each cell index contains | ||
170 | per-logical-volume indices. Each of volume index contains up to three | ||
171 | indices for the read-write, read-only and backup mirrors of those volumes. | ||
172 | Each of these contains vnode data file objects, each of which contains an | ||
173 | array of pages. | ||
174 | |||
175 | The very top index is the FS-Cache master index in which individual netfs's | ||
176 | have entries. | ||
177 | |||
178 | Any index object may reside in more than one cache, provided it only has index | ||
179 | children. Any index with non-index object children will be assumed to only | ||
180 | reside in one cache. | ||
181 | |||
182 | |||
183 | The netfs API to FS-Cache can be found in: | ||
184 | |||
185 | Documentation/filesystems/caching/netfs-api.txt | ||
186 | |||
187 | The cache backend API to FS-Cache can be found in: | ||
188 | |||
189 | Documentation/filesystems/caching/backend-api.txt | ||
190 | |||
191 | A description of the internal representations and object state machine can be | ||
192 | found in: | ||
193 | |||
194 | Documentation/filesystems/caching/object.txt | ||
195 | |||
196 | |||
197 | ======================= | ||
198 | STATISTICAL INFORMATION | ||
199 | ======================= | ||
200 | |||
201 | If FS-Cache is compiled with the following options enabled: | ||
202 | |||
203 | CONFIG_FSCACHE_STATS=y | ||
204 | CONFIG_FSCACHE_HISTOGRAM=y | ||
205 | |||
206 | then it will gather certain statistics and display them through a number of | ||
207 | proc files. | ||
208 | |||
209 | (*) /proc/fs/fscache/stats | ||
210 | |||
211 | This shows counts of a number of events that can happen in FS-Cache: | ||
212 | |||
213 | CLASS EVENT MEANING | ||
214 | ======= ======= ======================================================= | ||
215 | Cookies idx=N Number of index cookies allocated | ||
216 | dat=N Number of data storage cookies allocated | ||
217 | spc=N Number of special cookies allocated | ||
218 | Objects alc=N Number of objects allocated | ||
219 | nal=N Number of object allocation failures | ||
220 | avl=N Number of objects that reached the available state | ||
221 | ded=N Number of objects that reached the dead state | ||
222 | ChkAux non=N Number of objects that didn't have a coherency check | ||
223 | ok=N Number of objects that passed a coherency check | ||
224 | upd=N Number of objects that needed a coherency data update | ||
225 | obs=N Number of objects that were declared obsolete | ||
226 | Pages mrk=N Number of pages marked as being cached | ||
227 | unc=N Number of uncache page requests seen | ||
228 | Acquire n=N Number of acquire cookie requests seen | ||
229 | nul=N Number of acq reqs given a NULL parent | ||
230 | noc=N Number of acq reqs rejected due to no cache available | ||
231 | ok=N Number of acq reqs succeeded | ||
232 | nbf=N Number of acq reqs rejected due to error | ||
233 | oom=N Number of acq reqs failed on ENOMEM | ||
234 | Lookups n=N Number of lookup calls made on cache backends | ||
235 | neg=N Number of negative lookups made | ||
236 | pos=N Number of positive lookups made | ||
237 | crt=N Number of objects created by lookup | ||
238 | Updates n=N Number of update cookie requests seen | ||
239 | nul=N Number of upd reqs given a NULL parent | ||
240 | run=N Number of upd reqs granted CPU time | ||
241 | Relinqs n=N Number of relinquish cookie requests seen | ||
242 | nul=N Number of rlq reqs given a NULL parent | ||
243 | wcr=N Number of rlq reqs waited on completion of creation | ||
244 | AttrChg n=N Number of attribute changed requests seen | ||
245 | ok=N Number of attr changed requests queued | ||
246 | nbf=N Number of attr changed rejected -ENOBUFS | ||
247 | oom=N Number of attr changed failed -ENOMEM | ||
248 | run=N Number of attr changed ops given CPU time | ||
249 | Allocs n=N Number of allocation requests seen | ||
250 | ok=N Number of successful alloc reqs | ||
251 | wt=N Number of alloc reqs that waited on lookup completion | ||
252 | nbf=N Number of alloc reqs rejected -ENOBUFS | ||
253 | ops=N Number of alloc reqs submitted | ||
254 | owt=N Number of alloc reqs waited for CPU time | ||
255 | Retrvls n=N Number of retrieval (read) requests seen | ||
256 | ok=N Number of successful retr reqs | ||
257 | wt=N Number of retr reqs that waited on lookup completion | ||
258 | nod=N Number of retr reqs returned -ENODATA | ||
259 | nbf=N Number of retr reqs rejected -ENOBUFS | ||
260 | int=N Number of retr reqs aborted -ERESTARTSYS | ||
261 | oom=N Number of retr reqs failed -ENOMEM | ||
262 | ops=N Number of retr reqs submitted | ||
263 | owt=N Number of retr reqs waited for CPU time | ||
264 | Stores n=N Number of storage (write) requests seen | ||
265 | ok=N Number of successful store reqs | ||
266 | agn=N Number of store reqs on a page already pending storage | ||
267 | nbf=N Number of store reqs rejected -ENOBUFS | ||
268 | oom=N Number of store reqs failed -ENOMEM | ||
269 | ops=N Number of store reqs submitted | ||
270 | run=N Number of store reqs granted CPU time | ||
271 | Ops pend=N Number of times async ops added to pending queues | ||
272 | run=N Number of times async ops given CPU time | ||
273 | enq=N Number of times async ops queued for processing | ||
274 | dfr=N Number of async ops queued for deferred release | ||
275 | rel=N Number of async ops released | ||
276 | gc=N Number of deferred-release async ops garbage collected | ||
277 | |||
278 | |||
279 | (*) /proc/fs/fscache/histogram | ||
280 | |||
281 | cat /proc/fs/fscache/histogram | ||
282 | JIFS SECS OBJ INST OP RUNS OBJ RUNS RETRV DLY RETRIEVLS | ||
283 | ===== ===== ========= ========= ========= ========= ========= | ||
284 | |||
285 | This shows the breakdown of the number of times each amount of time | ||
286 | between 0 jiffies and HZ-1 jiffies a variety of tasks took to run. The | ||
287 | columns are as follows: | ||
288 | |||
289 | COLUMN TIME MEASUREMENT | ||
290 | ======= ======================================================= | ||
291 | OBJ INST Length of time to instantiate an object | ||
292 | OP RUNS Length of time a call to process an operation took | ||
293 | OBJ RUNS Length of time a call to process an object event took | ||
294 | RETRV DLY Time between an requesting a read and lookup completing | ||
295 | RETRIEVLS Time between beginning and end of a retrieval | ||
296 | |||
297 | Each row shows the number of events that took a particular range of times. | ||
298 | Each step is 1 jiffy in size. The JIFS column indicates the particular | ||
299 | jiffy range covered, and the SECS field the equivalent number of seconds. | ||
300 | |||
301 | |||
302 | ========= | ||
303 | DEBUGGING | ||
304 | ========= | ||
305 | |||
306 | If CONFIG_FSCACHE_DEBUG is enabled, the FS-Cache facility can have runtime | ||
307 | debugging enabled by adjusting the value in: | ||
308 | |||
309 | /sys/module/fscache/parameters/debug | ||
310 | |||
311 | This is a bitmask of debugging streams to enable: | ||
312 | |||
313 | BIT VALUE STREAM POINT | ||
314 | ======= ======= =============================== ======================= | ||
315 | 0 1 Cache management Function entry trace | ||
316 | 1 2 Function exit trace | ||
317 | 2 4 General | ||
318 | 3 8 Cookie management Function entry trace | ||
319 | 4 16 Function exit trace | ||
320 | 5 32 General | ||
321 | 6 64 Page handling Function entry trace | ||
322 | 7 128 Function exit trace | ||
323 | 8 256 General | ||
324 | 9 512 Operation management Function entry trace | ||
325 | 10 1024 Function exit trace | ||
326 | 11 2048 General | ||
327 | |||
328 | The appropriate set of values should be OR'd together and the result written to | ||
329 | the control file. For example: | ||
330 | |||
331 | echo $((1|8|64)) >/sys/module/fscache/parameters/debug | ||
332 | |||
333 | will turn on all function entry debugging. | ||
diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt new file mode 100644 index 000000000000..4db125b3a5c6 --- /dev/null +++ b/Documentation/filesystems/caching/netfs-api.txt | |||
@@ -0,0 +1,778 @@ | |||
1 | =============================== | ||
2 | FS-CACHE NETWORK FILESYSTEM API | ||
3 | =============================== | ||
4 | |||
5 | There's an API by which a network filesystem can make use of the FS-Cache | ||
6 | facilities. This is based around a number of principles: | ||
7 | |||
8 | (1) Caches can store a number of different object types. There are two main | ||
9 | object types: indices and files. The first is a special type used by | ||
10 | FS-Cache to make finding objects faster and to make retiring of groups of | ||
11 | objects easier. | ||
12 | |||
13 | (2) Every index, file or other object is represented by a cookie. This cookie | ||
14 | may or may not have anything associated with it, but the netfs doesn't | ||
15 | need to care. | ||
16 | |||
17 | (3) Barring the top-level index (one entry per cached netfs), the index | ||
18 | hierarchy for each netfs is structured according the whim of the netfs. | ||
19 | |||
20 | This API is declared in <linux/fscache.h>. | ||
21 | |||
22 | This document contains the following sections: | ||
23 | |||
24 | (1) Network filesystem definition | ||
25 | (2) Index definition | ||
26 | (3) Object definition | ||
27 | (4) Network filesystem (un)registration | ||
28 | (5) Cache tag lookup | ||
29 | (6) Index registration | ||
30 | (7) Data file registration | ||
31 | (8) Miscellaneous object registration | ||
32 | (9) Setting the data file size | ||
33 | (10) Page alloc/read/write | ||
34 | (11) Page uncaching | ||
35 | (12) Index and data file update | ||
36 | (13) Miscellaneous cookie operations | ||
37 | (14) Cookie unregistration | ||
38 | (15) Index and data file invalidation | ||
39 | (16) FS-Cache specific page flags. | ||
40 | |||
41 | |||
42 | ============================= | ||
43 | NETWORK FILESYSTEM DEFINITION | ||
44 | ============================= | ||
45 | |||
46 | FS-Cache needs a description of the network filesystem. This is specified | ||
47 | using a record of the following structure: | ||
48 | |||
49 | struct fscache_netfs { | ||
50 | uint32_t version; | ||
51 | const char *name; | ||
52 | struct fscache_cookie *primary_index; | ||
53 | ... | ||
54 | }; | ||
55 | |||
56 | This first two fields should be filled in before registration, and the third | ||
57 | will be filled in by the registration function; any other fields should just be | ||
58 | ignored and are for internal use only. | ||
59 | |||
60 | The fields are: | ||
61 | |||
62 | (1) The name of the netfs (used as the key in the toplevel index). | ||
63 | |||
64 | (2) The version of the netfs (if the name matches but the version doesn't, the | ||
65 | entire in-cache hierarchy for this netfs will be scrapped and begun | ||
66 | afresh). | ||
67 | |||
68 | (3) The cookie representing the primary index will be allocated according to | ||
69 | another parameter passed into the registration function. | ||
70 | |||
71 | For example, kAFS (linux/fs/afs/) uses the following definitions to describe | ||
72 | itself: | ||
73 | |||
74 | struct fscache_netfs afs_cache_netfs = { | ||
75 | .version = 0, | ||
76 | .name = "afs", | ||
77 | }; | ||
78 | |||
79 | |||
80 | ================ | ||
81 | INDEX DEFINITION | ||
82 | ================ | ||
83 | |||
84 | Indices are used for two purposes: | ||
85 | |||
86 | (1) To aid the finding of a file based on a series of keys (such as AFS's | ||
87 | "cell", "volume ID", "vnode ID"). | ||
88 | |||
89 | (2) To make it easier to discard a subset of all the files cached based around | ||
90 | a particular key - for instance to mirror the removal of an AFS volume. | ||
91 | |||
92 | However, since it's unlikely that any two netfs's are going to want to define | ||
93 | their index hierarchies in quite the same way, FS-Cache tries to impose as few | ||
94 | restraints as possible on how an index is structured and where it is placed in | ||
95 | the tree. The netfs can even mix indices and data files at the same level, but | ||
96 | it's not recommended. | ||
97 | |||
98 | Each index entry consists of a key of indeterminate length plus some auxilliary | ||
99 | data, also of indeterminate length. | ||
100 | |||
101 | There are some limits on indices: | ||
102 | |||
103 | (1) Any index containing non-index objects should be restricted to a single | ||
104 | cache. Any such objects created within an index will be created in the | ||
105 | first cache only. The cache in which an index is created can be | ||
106 | controlled by cache tags (see below). | ||
107 | |||
108 | (2) The entry data must be atomically journallable, so it is limited to about | ||
109 | 400 bytes at present. At least 400 bytes will be available. | ||
110 | |||
111 | (3) The depth of the index tree should be judged with care as the search | ||
112 | function is recursive. Too many layers will run the kernel out of stack. | ||
113 | |||
114 | |||
115 | ================= | ||
116 | OBJECT DEFINITION | ||
117 | ================= | ||
118 | |||
119 | To define an object, a structure of the following type should be filled out: | ||
120 | |||
121 | struct fscache_cookie_def | ||
122 | { | ||
123 | uint8_t name[16]; | ||
124 | uint8_t type; | ||
125 | |||
126 | struct fscache_cache_tag *(*select_cache)( | ||
127 | const void *parent_netfs_data, | ||
128 | const void *cookie_netfs_data); | ||
129 | |||
130 | uint16_t (*get_key)(const void *cookie_netfs_data, | ||
131 | void *buffer, | ||
132 | uint16_t bufmax); | ||
133 | |||
134 | void (*get_attr)(const void *cookie_netfs_data, | ||
135 | uint64_t *size); | ||
136 | |||
137 | uint16_t (*get_aux)(const void *cookie_netfs_data, | ||
138 | void *buffer, | ||
139 | uint16_t bufmax); | ||
140 | |||
141 | enum fscache_checkaux (*check_aux)(void *cookie_netfs_data, | ||
142 | const void *data, | ||
143 | uint16_t datalen); | ||
144 | |||
145 | void (*get_context)(void *cookie_netfs_data, void *context); | ||
146 | |||
147 | void (*put_context)(void *cookie_netfs_data, void *context); | ||
148 | |||
149 | void (*mark_pages_cached)(void *cookie_netfs_data, | ||
150 | struct address_space *mapping, | ||
151 | struct pagevec *cached_pvec); | ||
152 | |||
153 | void (*now_uncached)(void *cookie_netfs_data); | ||
154 | }; | ||
155 | |||
156 | This has the following fields: | ||
157 | |||
158 | (1) The type of the object [mandatory]. | ||
159 | |||
160 | This is one of the following values: | ||
161 | |||
162 | (*) FSCACHE_COOKIE_TYPE_INDEX | ||
163 | |||
164 | This defines an index, which is a special FS-Cache type. | ||
165 | |||
166 | (*) FSCACHE_COOKIE_TYPE_DATAFILE | ||
167 | |||
168 | This defines an ordinary data file. | ||
169 | |||
170 | (*) Any other value between 2 and 255 | ||
171 | |||
172 | This defines an extraordinary object such as an XATTR. | ||
173 | |||
174 | (2) The name of the object type (NUL terminated unless all 16 chars are used) | ||
175 | [optional]. | ||
176 | |||
177 | (3) A function to select the cache in which to store an index [optional]. | ||
178 | |||
179 | This function is invoked when an index needs to be instantiated in a cache | ||
180 | during the instantiation of a non-index object. Only the immediate index | ||
181 | parent for the non-index object will be queried. Any indices above that | ||
182 | in the hierarchy may be stored in multiple caches. This function does not | ||
183 | need to be supplied for any non-index object or any index that will only | ||
184 | have index children. | ||
185 | |||
186 | If this function is not supplied or if it returns NULL then the first | ||
187 | cache in the parent's list will be chosed, or failing that, the first | ||
188 | cache in the master list. | ||
189 | |||
190 | (4) A function to retrieve an object's key from the netfs [mandatory]. | ||
191 | |||
192 | This function will be called with the netfs data that was passed to the | ||
193 | cookie acquisition function and the maximum length of key data that it may | ||
194 | provide. It should write the required key data into the given buffer and | ||
195 | return the quantity it wrote. | ||
196 | |||
197 | (5) A function to retrieve attribute data from the netfs [optional]. | ||
198 | |||
199 | This function will be called with the netfs data that was passed to the | ||
200 | cookie acquisition function. It should return the size of the file if | ||
201 | this is a data file. The size may be used to govern how much cache must | ||
202 | be reserved for this file in the cache. | ||
203 | |||
204 | If the function is absent, a file size of 0 is assumed. | ||
205 | |||
206 | (6) A function to retrieve auxilliary data from the netfs [optional]. | ||
207 | |||
208 | This function will be called with the netfs data that was passed to the | ||
209 | cookie acquisition function and the maximum length of auxilliary data that | ||
210 | it may provide. It should write the auxilliary data into the given buffer | ||
211 | and return the quantity it wrote. | ||
212 | |||
213 | If this function is absent, the auxilliary data length will be set to 0. | ||
214 | |||
215 | The length of the auxilliary data buffer may be dependent on the key | ||
216 | length. A netfs mustn't rely on being able to provide more than 400 bytes | ||
217 | for both. | ||
218 | |||
219 | (7) A function to check the auxilliary data [optional]. | ||
220 | |||
221 | This function will be called to check that a match found in the cache for | ||
222 | this object is valid. For instance with AFS it could check the auxilliary | ||
223 | data against the data version number returned by the server to determine | ||
224 | whether the index entry in a cache is still valid. | ||
225 | |||
226 | If this function is absent, it will be assumed that matching objects in a | ||
227 | cache are always valid. | ||
228 | |||
229 | If present, the function should return one of the following values: | ||
230 | |||
231 | (*) FSCACHE_CHECKAUX_OKAY - the entry is okay as is | ||
232 | (*) FSCACHE_CHECKAUX_NEEDS_UPDATE - the entry requires update | ||
233 | (*) FSCACHE_CHECKAUX_OBSOLETE - the entry should be deleted | ||
234 | |||
235 | This function can also be used to extract data from the auxilliary data in | ||
236 | the cache and copy it into the netfs's structures. | ||
237 | |||
238 | (8) A pair of functions to manage contexts for the completion callback | ||
239 | [optional]. | ||
240 | |||
241 | The cache read/write functions are passed a context which is then passed | ||
242 | to the I/O completion callback function. To ensure this context remains | ||
243 | valid until after the I/O completion is called, two functions may be | ||
244 | provided: one to get an extra reference on the context, and one to drop a | ||
245 | reference to it. | ||
246 | |||
247 | If the context is not used or is a type of object that won't go out of | ||
248 | scope, then these functions are not required. These functions are not | ||
249 | required for indices as indices may not contain data. These functions may | ||
250 | be called in interrupt context and so may not sleep. | ||
251 | |||
252 | (9) A function to mark a page as retaining cache metadata [optional]. | ||
253 | |||
254 | This is called by the cache to indicate that it is retaining in-memory | ||
255 | information for this page and that the netfs should uncache the page when | ||
256 | it has finished. This does not indicate whether there's data on the disk | ||
257 | or not. Note that several pages at once may be presented for marking. | ||
258 | |||
259 | The PG_fscache bit is set on the pages before this function would be | ||
260 | called, so the function need not be provided if this is sufficient. | ||
261 | |||
262 | This function is not required for indices as they're not permitted data. | ||
263 | |||
264 | (10) A function to unmark all the pages retaining cache metadata [mandatory]. | ||
265 | |||
266 | This is called by FS-Cache to indicate that a backing store is being | ||
267 | unbound from a cookie and that all the marks on the pages should be | ||
268 | cleared to prevent confusion. Note that the cache will have torn down all | ||
269 | its tracking information so that the pages don't need to be explicitly | ||
270 | uncached. | ||
271 | |||
272 | This function is not required for indices as they're not permitted data. | ||
273 | |||
274 | |||
275 | =================================== | ||
276 | NETWORK FILESYSTEM (UN)REGISTRATION | ||
277 | =================================== | ||
278 | |||
279 | The first step is to declare the network filesystem to the cache. This also | ||
280 | involves specifying the layout of the primary index (for AFS, this would be the | ||
281 | "cell" level). | ||
282 | |||
283 | The registration function is: | ||
284 | |||
285 | int fscache_register_netfs(struct fscache_netfs *netfs); | ||
286 | |||
287 | It just takes a pointer to the netfs definition. It returns 0 or an error as | ||
288 | appropriate. | ||
289 | |||
290 | For kAFS, registration is done as follows: | ||
291 | |||
292 | ret = fscache_register_netfs(&afs_cache_netfs); | ||
293 | |||
294 | The last step is, of course, unregistration: | ||
295 | |||
296 | void fscache_unregister_netfs(struct fscache_netfs *netfs); | ||
297 | |||
298 | |||
299 | ================ | ||
300 | CACHE TAG LOOKUP | ||
301 | ================ | ||
302 | |||
303 | FS-Cache permits the use of more than one cache. To permit particular index | ||
304 | subtrees to be bound to particular caches, the second step is to look up cache | ||
305 | representation tags. This step is optional; it can be left entirely up to | ||
306 | FS-Cache as to which cache should be used. The problem with doing that is that | ||
307 | FS-Cache will always pick the first cache that was registered. | ||
308 | |||
309 | To get the representation for a named tag: | ||
310 | |||
311 | struct fscache_cache_tag *fscache_lookup_cache_tag(const char *name); | ||
312 | |||
313 | This takes a text string as the name and returns a representation of a tag. It | ||
314 | will never return an error. It may return a dummy tag, however, if it runs out | ||
315 | of memory; this will inhibit caching with this tag. | ||
316 | |||
317 | Any representation so obtained must be released by passing it to this function: | ||
318 | |||
319 | void fscache_release_cache_tag(struct fscache_cache_tag *tag); | ||
320 | |||
321 | The tag will be retrieved by FS-Cache when it calls the object definition | ||
322 | operation select_cache(). | ||
323 | |||
324 | |||
325 | ================== | ||
326 | INDEX REGISTRATION | ||
327 | ================== | ||
328 | |||
329 | The third step is to inform FS-Cache about part of an index hierarchy that can | ||
330 | be used to locate files. This is done by requesting a cookie for each index in | ||
331 | the path to the file: | ||
332 | |||
333 | struct fscache_cookie * | ||
334 | fscache_acquire_cookie(struct fscache_cookie *parent, | ||
335 | const struct fscache_object_def *def, | ||
336 | void *netfs_data); | ||
337 | |||
338 | This function creates an index entry in the index represented by parent, | ||
339 | filling in the index entry by calling the operations pointed to by def. | ||
340 | |||
341 | Note that this function never returns an error - all errors are handled | ||
342 | internally. It may, however, return NULL to indicate no cookie. It is quite | ||
343 | acceptable to pass this token back to this function as the parent to another | ||
344 | acquisition (or even to the relinquish cookie, read page and write page | ||
345 | functions - see below). | ||
346 | |||
347 | Note also that no indices are actually created in a cache until a non-index | ||
348 | object needs to be created somewhere down the hierarchy. Furthermore, an index | ||
349 | may be created in several different caches independently at different times. | ||
350 | This is all handled transparently, and the netfs doesn't see any of it. | ||
351 | |||
352 | For example, with AFS, a cell would be added to the primary index. This index | ||
353 | entry would have a dependent inode containing a volume location index for the | ||
354 | volume mappings within this cell: | ||
355 | |||
356 | cell->cache = | ||
357 | fscache_acquire_cookie(afs_cache_netfs.primary_index, | ||
358 | &afs_cell_cache_index_def, | ||
359 | cell); | ||
360 | |||
361 | Then when a volume location was accessed, it would be entered into the cell's | ||
362 | index and an inode would be allocated that acts as a volume type and hash chain | ||
363 | combination: | ||
364 | |||
365 | vlocation->cache = | ||
366 | fscache_acquire_cookie(cell->cache, | ||
367 | &afs_vlocation_cache_index_def, | ||
368 | vlocation); | ||
369 | |||
370 | And then a particular flavour of volume (R/O for example) could be added to | ||
371 | that index, creating another index for vnodes (AFS inode equivalents): | ||
372 | |||
373 | volume->cache = | ||
374 | fscache_acquire_cookie(vlocation->cache, | ||
375 | &afs_volume_cache_index_def, | ||
376 | volume); | ||
377 | |||
378 | |||
379 | ====================== | ||
380 | DATA FILE REGISTRATION | ||
381 | ====================== | ||
382 | |||
383 | The fourth step is to request a data file be created in the cache. This is | ||
384 | identical to index cookie acquisition. The only difference is that the type in | ||
385 | the object definition should be something other than index type. | ||
386 | |||
387 | vnode->cache = | ||
388 | fscache_acquire_cookie(volume->cache, | ||
389 | &afs_vnode_cache_object_def, | ||
390 | vnode); | ||
391 | |||
392 | |||
393 | ================================= | ||
394 | MISCELLANEOUS OBJECT REGISTRATION | ||
395 | ================================= | ||
396 | |||
397 | An optional step is to request an object of miscellaneous type be created in | ||
398 | the cache. This is almost identical to index cookie acquisition. The only | ||
399 | difference is that the type in the object definition should be something other | ||
400 | than index type. Whilst the parent object could be an index, it's more likely | ||
401 | it would be some other type of object such as a data file. | ||
402 | |||
403 | xattr->cache = | ||
404 | fscache_acquire_cookie(vnode->cache, | ||
405 | &afs_xattr_cache_object_def, | ||
406 | xattr); | ||
407 | |||
408 | Miscellaneous objects might be used to store extended attributes or directory | ||
409 | entries for example. | ||
410 | |||
411 | |||
412 | ========================== | ||
413 | SETTING THE DATA FILE SIZE | ||
414 | ========================== | ||
415 | |||
416 | The fifth step is to set the physical attributes of the file, such as its size. | ||
417 | This doesn't automatically reserve any space in the cache, but permits the | ||
418 | cache to adjust its metadata for data tracking appropriately: | ||
419 | |||
420 | int fscache_attr_changed(struct fscache_cookie *cookie); | ||
421 | |||
422 | The cache will return -ENOBUFS if there is no backing cache or if there is no | ||
423 | space to allocate any extra metadata required in the cache. The attributes | ||
424 | will be accessed with the get_attr() cookie definition operation. | ||
425 | |||
426 | Note that attempts to read or write data pages in the cache over this size may | ||
427 | be rebuffed with -ENOBUFS. | ||
428 | |||
429 | This operation schedules an attribute adjustment to happen asynchronously at | ||
430 | some point in the future, and as such, it may happen after the function returns | ||
431 | to the caller. The attribute adjustment excludes read and write operations. | ||
432 | |||
433 | |||
434 | ===================== | ||
435 | PAGE READ/ALLOC/WRITE | ||
436 | ===================== | ||
437 | |||
438 | And the sixth step is to store and retrieve pages in the cache. There are | ||
439 | three functions that are used to do this. | ||
440 | |||
441 | Note: | ||
442 | |||
443 | (1) A page should not be re-read or re-allocated without uncaching it first. | ||
444 | |||
445 | (2) A read or allocated page must be uncached when the netfs page is released | ||
446 | from the pagecache. | ||
447 | |||
448 | (3) A page should only be written to the cache if previous read or allocated. | ||
449 | |||
450 | This permits the cache to maintain its page tracking in proper order. | ||
451 | |||
452 | |||
453 | PAGE READ | ||
454 | --------- | ||
455 | |||
456 | Firstly, the netfs should ask FS-Cache to examine the caches and read the | ||
457 | contents cached for a particular page of a particular file if present, or else | ||
458 | allocate space to store the contents if not: | ||
459 | |||
460 | typedef | ||
461 | void (*fscache_rw_complete_t)(struct page *page, | ||
462 | void *context, | ||
463 | int error); | ||
464 | |||
465 | int fscache_read_or_alloc_page(struct fscache_cookie *cookie, | ||
466 | struct page *page, | ||
467 | fscache_rw_complete_t end_io_func, | ||
468 | void *context, | ||
469 | gfp_t gfp); | ||
470 | |||
471 | The cookie argument must specify a cookie for an object that isn't an index, | ||
472 | the page specified will have the data loaded into it (and is also used to | ||
473 | specify the page number), and the gfp argument is used to control how any | ||
474 | memory allocations made are satisfied. | ||
475 | |||
476 | If the cookie indicates the inode is not cached: | ||
477 | |||
478 | (1) The function will return -ENOBUFS. | ||
479 | |||
480 | Else if there's a copy of the page resident in the cache: | ||
481 | |||
482 | (1) The mark_pages_cached() cookie operation will be called on that page. | ||
483 | |||
484 | (2) The function will submit a request to read the data from the cache's | ||
485 | backing device directly into the page specified. | ||
486 | |||
487 | (3) The function will return 0. | ||
488 | |||
489 | (4) When the read is complete, end_io_func() will be invoked with: | ||
490 | |||
491 | (*) The netfs data supplied when the cookie was created. | ||
492 | |||
493 | (*) The page descriptor. | ||
494 | |||
495 | (*) The context argument passed to the above function. This will be | ||
496 | maintained with the get_context/put_context functions mentioned above. | ||
497 | |||
498 | (*) An argument that's 0 on success or negative for an error code. | ||
499 | |||
500 | If an error occurs, it should be assumed that the page contains no usable | ||
501 | data. | ||
502 | |||
503 | end_io_func() will be called in process context if the read is results in | ||
504 | an error, but it might be called in interrupt context if the read is | ||
505 | successful. | ||
506 | |||
507 | Otherwise, if there's not a copy available in cache, but the cache may be able | ||
508 | to store the page: | ||
509 | |||
510 | (1) The mark_pages_cached() cookie operation will be called on that page. | ||
511 | |||
512 | (2) A block may be reserved in the cache and attached to the object at the | ||
513 | appropriate place. | ||
514 | |||
515 | (3) The function will return -ENODATA. | ||
516 | |||
517 | This function may also return -ENOMEM or -EINTR, in which case it won't have | ||
518 | read any data from the cache. | ||
519 | |||
520 | |||
521 | PAGE ALLOCATE | ||
522 | ------------- | ||
523 | |||
524 | Alternatively, if there's not expected to be any data in the cache for a page | ||
525 | because the file has been extended, a block can simply be allocated instead: | ||
526 | |||
527 | int fscache_alloc_page(struct fscache_cookie *cookie, | ||
528 | struct page *page, | ||
529 | gfp_t gfp); | ||
530 | |||
531 | This is similar to the fscache_read_or_alloc_page() function, except that it | ||
532 | never reads from the cache. It will return 0 if a block has been allocated, | ||
533 | rather than -ENODATA as the other would. One or the other must be performed | ||
534 | before writing to the cache. | ||
535 | |||
536 | The mark_pages_cached() cookie operation will be called on the page if | ||
537 | successful. | ||
538 | |||
539 | |||
540 | PAGE WRITE | ||
541 | ---------- | ||
542 | |||
543 | Secondly, if the netfs changes the contents of the page (either due to an | ||
544 | initial download or if a user performs a write), then the page should be | ||
545 | written back to the cache: | ||
546 | |||
547 | int fscache_write_page(struct fscache_cookie *cookie, | ||
548 | struct page *page, | ||
549 | gfp_t gfp); | ||
550 | |||
551 | The cookie argument must specify a data file cookie, the page specified should | ||
552 | contain the data to be written (and is also used to specify the page number), | ||
553 | and the gfp argument is used to control how any memory allocations made are | ||
554 | satisfied. | ||
555 | |||
556 | The page must have first been read or allocated successfully and must not have | ||
557 | been uncached before writing is performed. | ||
558 | |||
559 | If the cookie indicates the inode is not cached then: | ||
560 | |||
561 | (1) The function will return -ENOBUFS. | ||
562 | |||
563 | Else if space can be allocated in the cache to hold this page: | ||
564 | |||
565 | (1) PG_fscache_write will be set on the page. | ||
566 | |||
567 | (2) The function will submit a request to write the data to cache's backing | ||
568 | device directly from the page specified. | ||
569 | |||
570 | (3) The function will return 0. | ||
571 | |||
572 | (4) When the write is complete PG_fscache_write is cleared on the page and | ||
573 | anyone waiting for that bit will be woken up. | ||
574 | |||
575 | Else if there's no space available in the cache, -ENOBUFS will be returned. It | ||
576 | is also possible for the PG_fscache_write bit to be cleared when no write took | ||
577 | place if unforeseen circumstances arose (such as a disk error). | ||
578 | |||
579 | Writing takes place asynchronously. | ||
580 | |||
581 | |||
582 | MULTIPLE PAGE READ | ||
583 | ------------------ | ||
584 | |||
585 | A facility is provided to read several pages at once, as requested by the | ||
586 | readpages() address space operation: | ||
587 | |||
588 | int fscache_read_or_alloc_pages(struct fscache_cookie *cookie, | ||
589 | struct address_space *mapping, | ||
590 | struct list_head *pages, | ||
591 | int *nr_pages, | ||
592 | fscache_rw_complete_t end_io_func, | ||
593 | void *context, | ||
594 | gfp_t gfp); | ||
595 | |||
596 | This works in a similar way to fscache_read_or_alloc_page(), except: | ||
597 | |||
598 | (1) Any page it can retrieve data for is removed from pages and nr_pages and | ||
599 | dispatched for reading to the disk. Reads of adjacent pages on disk may | ||
600 | be merged for greater efficiency. | ||
601 | |||
602 | (2) The mark_pages_cached() cookie operation will be called on several pages | ||
603 | at once if they're being read or allocated. | ||
604 | |||
605 | (3) If there was an general error, then that error will be returned. | ||
606 | |||
607 | Else if some pages couldn't be allocated or read, then -ENOBUFS will be | ||
608 | returned. | ||
609 | |||
610 | Else if some pages couldn't be read but were allocated, then -ENODATA will | ||
611 | be returned. | ||
612 | |||
613 | Otherwise, if all pages had reads dispatched, then 0 will be returned, the | ||
614 | list will be empty and *nr_pages will be 0. | ||
615 | |||
616 | (4) end_io_func will be called once for each page being read as the reads | ||
617 | complete. It will be called in process context if error != 0, but it may | ||
618 | be called in interrupt context if there is no error. | ||
619 | |||
620 | Note that a return of -ENODATA, -ENOBUFS or any other error does not preclude | ||
621 | some of the pages being read and some being allocated. Those pages will have | ||
622 | been marked appropriately and will need uncaching. | ||
623 | |||
624 | |||
625 | ============== | ||
626 | PAGE UNCACHING | ||
627 | ============== | ||
628 | |||
629 | To uncache a page, this function should be called: | ||
630 | |||
631 | void fscache_uncache_page(struct fscache_cookie *cookie, | ||
632 | struct page *page); | ||
633 | |||
634 | This function permits the cache to release any in-memory representation it | ||
635 | might be holding for this netfs page. This function must be called once for | ||
636 | each page on which the read or write page functions above have been called to | ||
637 | make sure the cache's in-memory tracking information gets torn down. | ||
638 | |||
639 | Note that pages can't be explicitly deleted from the a data file. The whole | ||
640 | data file must be retired (see the relinquish cookie function below). | ||
641 | |||
642 | Furthermore, note that this does not cancel the asynchronous read or write | ||
643 | operation started by the read/alloc and write functions, so the page | ||
644 | invalidation and release functions must use: | ||
645 | |||
646 | bool fscache_check_page_write(struct fscache_cookie *cookie, | ||
647 | struct page *page); | ||
648 | |||
649 | to see if a page is being written to the cache, and: | ||
650 | |||
651 | void fscache_wait_on_page_write(struct fscache_cookie *cookie, | ||
652 | struct page *page); | ||
653 | |||
654 | to wait for it to finish if it is. | ||
655 | |||
656 | |||
657 | ========================== | ||
658 | INDEX AND DATA FILE UPDATE | ||
659 | ========================== | ||
660 | |||
661 | To request an update of the index data for an index or other object, the | ||
662 | following function should be called: | ||
663 | |||
664 | void fscache_update_cookie(struct fscache_cookie *cookie); | ||
665 | |||
666 | This function will refer back to the netfs_data pointer stored in the cookie by | ||
667 | the acquisition function to obtain the data to write into each revised index | ||
668 | entry. The update method in the parent index definition will be called to | ||
669 | transfer the data. | ||
670 | |||
671 | Note that partial updates may happen automatically at other times, such as when | ||
672 | data blocks are added to a data file object. | ||
673 | |||
674 | |||
675 | =============================== | ||
676 | MISCELLANEOUS COOKIE OPERATIONS | ||
677 | =============================== | ||
678 | |||
679 | There are a number of operations that can be used to control cookies: | ||
680 | |||
681 | (*) Cookie pinning: | ||
682 | |||
683 | int fscache_pin_cookie(struct fscache_cookie *cookie); | ||
684 | void fscache_unpin_cookie(struct fscache_cookie *cookie); | ||
685 | |||
686 | These operations permit data cookies to be pinned into the cache and to | ||
687 | have the pinning removed. They are not permitted on index cookies. | ||
688 | |||
689 | The pinning function will return 0 if successful, -ENOBUFS in the cookie | ||
690 | isn't backed by a cache, -EOPNOTSUPP if the cache doesn't support pinning, | ||
691 | -ENOSPC if there isn't enough space to honour the operation, -ENOMEM or | ||
692 | -EIO if there's any other problem. | ||
693 | |||
694 | (*) Data space reservation: | ||
695 | |||
696 | int fscache_reserve_space(struct fscache_cookie *cookie, loff_t size); | ||
697 | |||
698 | This permits a netfs to request cache space be reserved to store up to the | ||
699 | given amount of a file. It is permitted to ask for more than the current | ||
700 | size of the file to allow for future file expansion. | ||
701 | |||
702 | If size is given as zero then the reservation will be cancelled. | ||
703 | |||
704 | The function will return 0 if successful, -ENOBUFS in the cookie isn't | ||
705 | backed by a cache, -EOPNOTSUPP if the cache doesn't support reservations, | ||
706 | -ENOSPC if there isn't enough space to honour the operation, -ENOMEM or | ||
707 | -EIO if there's any other problem. | ||
708 | |||
709 | Note that this doesn't pin an object in a cache; it can still be culled to | ||
710 | make space if it's not in use. | ||
711 | |||
712 | |||
713 | ===================== | ||
714 | COOKIE UNREGISTRATION | ||
715 | ===================== | ||
716 | |||
717 | To get rid of a cookie, this function should be called. | ||
718 | |||
719 | void fscache_relinquish_cookie(struct fscache_cookie *cookie, | ||
720 | int retire); | ||
721 | |||
722 | If retire is non-zero, then the object will be marked for recycling, and all | ||
723 | copies of it will be removed from all active caches in which it is present. | ||
724 | Not only that but all child objects will also be retired. | ||
725 | |||
726 | If retire is zero, then the object may be available again when next the | ||
727 | acquisition function is called. Retirement here will overrule the pinning on a | ||
728 | cookie. | ||
729 | |||
730 | One very important note - relinquish must NOT be called for a cookie unless all | ||
731 | the cookies for "child" indices, objects and pages have been relinquished | ||
732 | first. | ||
733 | |||
734 | |||
735 | ================================ | ||
736 | INDEX AND DATA FILE INVALIDATION | ||
737 | ================================ | ||
738 | |||
739 | There is no direct way to invalidate an index subtree or a data file. To do | ||
740 | this, the caller should relinquish and retire the cookie they have, and then | ||
741 | acquire a new one. | ||
742 | |||
743 | |||
744 | =========================== | ||
745 | FS-CACHE SPECIFIC PAGE FLAG | ||
746 | =========================== | ||
747 | |||
748 | FS-Cache makes use of a page flag, PG_private_2, for its own purpose. This is | ||
749 | given the alternative name PG_fscache. | ||
750 | |||
751 | PG_fscache is used to indicate that the page is known by the cache, and that | ||
752 | the cache must be informed if the page is going to go away. It's an indication | ||
753 | to the netfs that the cache has an interest in this page, where an interest may | ||
754 | be a pointer to it, resources allocated or reserved for it, or I/O in progress | ||
755 | upon it. | ||
756 | |||
757 | The netfs can use this information in methods such as releasepage() to | ||
758 | determine whether it needs to uncache a page or update it. | ||
759 | |||
760 | Furthermore, if this bit is set, releasepage() and invalidatepage() operations | ||
761 | will be called on a page to get rid of it, even if PG_private is not set. This | ||
762 | allows caching to attempted on a page before read_cache_pages() to be called | ||
763 | after fscache_read_or_alloc_pages() as the former will try and release pages it | ||
764 | was given under certain circumstances. | ||
765 | |||
766 | This bit does not overlap with such as PG_private. This means that FS-Cache | ||
767 | can be used with a filesystem that uses the block buffering code. | ||
768 | |||
769 | There are a number of operations defined on this flag: | ||
770 | |||
771 | int PageFsCache(struct page *page); | ||
772 | void SetPageFsCache(struct page *page) | ||
773 | void ClearPageFsCache(struct page *page) | ||
774 | int TestSetPageFsCache(struct page *page) | ||
775 | int TestClearPageFsCache(struct page *page) | ||
776 | |||
777 | These functions are bit test, bit set, bit clear, bit test and set and bit | ||
778 | test and clear operations on PG_fscache. | ||
diff --git a/Documentation/filesystems/caching/object.txt b/Documentation/filesystems/caching/object.txt new file mode 100644 index 000000000000..e8b0a35d8fe5 --- /dev/null +++ b/Documentation/filesystems/caching/object.txt | |||
@@ -0,0 +1,313 @@ | |||
1 | ==================================================== | ||
2 | IN-KERNEL CACHE OBJECT REPRESENTATION AND MANAGEMENT | ||
3 | ==================================================== | ||
4 | |||
5 | By: David Howells <dhowells@redhat.com> | ||
6 | |||
7 | Contents: | ||
8 | |||
9 | (*) Representation | ||
10 | |||
11 | (*) Object management state machine. | ||
12 | |||
13 | - Provision of cpu time. | ||
14 | - Locking simplification. | ||
15 | |||
16 | (*) The set of states. | ||
17 | |||
18 | (*) The set of events. | ||
19 | |||
20 | |||
21 | ============== | ||
22 | REPRESENTATION | ||
23 | ============== | ||
24 | |||
25 | FS-Cache maintains an in-kernel representation of each object that a netfs is | ||
26 | currently interested in. Such objects are represented by the fscache_cookie | ||
27 | struct and are referred to as cookies. | ||
28 | |||
29 | FS-Cache also maintains a separate in-kernel representation of the objects that | ||
30 | a cache backend is currently actively caching. Such objects are represented by | ||
31 | the fscache_object struct. The cache backends allocate these upon request, and | ||
32 | are expected to embed them in their own representations. These are referred to | ||
33 | as objects. | ||
34 | |||
35 | There is a 1:N relationship between cookies and objects. A cookie may be | ||
36 | represented by multiple objects - an index may exist in more than one cache - | ||
37 | or even by no objects (it may not be cached). | ||
38 | |||
39 | Furthermore, both cookies and objects are hierarchical. The two hierarchies | ||
40 | correspond, but the cookies tree is a superset of the union of the object trees | ||
41 | of multiple caches: | ||
42 | |||
43 | NETFS INDEX TREE : CACHE 1 : CACHE 2 | ||
44 | : : | ||
45 | : +-----------+ : | ||
46 | +----------->| IObject | : | ||
47 | +-----------+ | : +-----------+ : | ||
48 | | ICookie |-------+ : | : | ||
49 | +-----------+ | : | : +-----------+ | ||
50 | | +------------------------------>| IObject | | ||
51 | | : | : +-----------+ | ||
52 | | : V : | | ||
53 | | : +-----------+ : | | ||
54 | V +----------->| IObject | : | | ||
55 | +-----------+ | : +-----------+ : | | ||
56 | | ICookie |-------+ : | : V | ||
57 | +-----------+ | : | : +-----------+ | ||
58 | | +------------------------------>| IObject | | ||
59 | +-----+-----+ : | : +-----------+ | ||
60 | | | : | : | | ||
61 | V | : V : | | ||
62 | +-----------+ | : +-----------+ : | | ||
63 | | ICookie |------------------------->| IObject | : | | ||
64 | +-----------+ | : +-----------+ : | | ||
65 | | V : | : V | ||
66 | | +-----------+ : | : +-----------+ | ||
67 | | | ICookie |-------------------------------->| IObject | | ||
68 | | +-----------+ : | : +-----------+ | ||
69 | V | : V : | | ||
70 | +-----------+ | : +-----------+ : | | ||
71 | | DCookie |------------------------->| DObject | : | | ||
72 | +-----------+ | : +-----------+ : | | ||
73 | | : : | | ||
74 | +-------+-------+ : : | | ||
75 | | | : : | | ||
76 | V V : : V | ||
77 | +-----------+ +-----------+ : : +-----------+ | ||
78 | | DCookie | | DCookie |------------------------>| DObject | | ||
79 | +-----------+ +-----------+ : : +-----------+ | ||
80 | : : | ||
81 | |||
82 | In the above illustration, ICookie and IObject represent indices and DCookie | ||
83 | and DObject represent data storage objects. Indices may have representation in | ||
84 | multiple caches, but currently, non-index objects may not. Objects of any type | ||
85 | may also be entirely unrepresented. | ||
86 | |||
87 | As far as the netfs API goes, the netfs is only actually permitted to see | ||
88 | pointers to the cookies. The cookies themselves and any objects attached to | ||
89 | those cookies are hidden from it. | ||
90 | |||
91 | |||
92 | =============================== | ||
93 | OBJECT MANAGEMENT STATE MACHINE | ||
94 | =============================== | ||
95 | |||
96 | Within FS-Cache, each active object is managed by its own individual state | ||
97 | machine. The state for an object is kept in the fscache_object struct, in | ||
98 | object->state. A cookie may point to a set of objects that are in different | ||
99 | states. | ||
100 | |||
101 | Each state has an action associated with it that is invoked when the machine | ||
102 | wakes up in that state. There are four logical sets of states: | ||
103 | |||
104 | (1) Preparation: states that wait for the parent objects to become ready. The | ||
105 | representations are hierarchical, and it is expected that an object must | ||
106 | be created or accessed with respect to its parent object. | ||
107 | |||
108 | (2) Initialisation: states that perform lookups in the cache and validate | ||
109 | what's found and that create on disk any missing metadata. | ||
110 | |||
111 | (3) Normal running: states that allow netfs operations on objects to proceed | ||
112 | and that update the state of objects. | ||
113 | |||
114 | (4) Termination: states that detach objects from their netfs cookies, that | ||
115 | delete objects from disk, that handle disk and system errors and that free | ||
116 | up in-memory resources. | ||
117 | |||
118 | |||
119 | In most cases, transitioning between states is in response to signalled events. | ||
120 | When a state has finished processing, it will usually set the mask of events in | ||
121 | which it is interested (object->event_mask) and relinquish the worker thread. | ||
122 | Then when an event is raised (by calling fscache_raise_event()), if the event | ||
123 | is not masked, the object will be queued for processing (by calling | ||
124 | fscache_enqueue_object()). | ||
125 | |||
126 | |||
127 | PROVISION OF CPU TIME | ||
128 | --------------------- | ||
129 | |||
130 | The work to be done by the various states is given CPU time by the threads of | ||
131 | the slow work facility (see Documentation/slow-work.txt). This is used in | ||
132 | preference to the workqueue facility because: | ||
133 | |||
134 | (1) Threads may be completely occupied for very long periods of time by a | ||
135 | particular work item. These state actions may be doing sequences of | ||
136 | synchronous, journalled disk accesses (lookup, mkdir, create, setxattr, | ||
137 | getxattr, truncate, unlink, rmdir, rename). | ||
138 | |||
139 | (2) Threads may do little actual work, but may rather spend a lot of time | ||
140 | sleeping on I/O. This means that single-threaded and 1-per-CPU-threaded | ||
141 | workqueues don't necessarily have the right numbers of threads. | ||
142 | |||
143 | |||
144 | LOCKING SIMPLIFICATION | ||
145 | ---------------------- | ||
146 | |||
147 | Because only one worker thread may be operating on any particular object's | ||
148 | state machine at once, this simplifies the locking, particularly with respect | ||
149 | to disconnecting the netfs's representation of a cache object (fscache_cookie) | ||
150 | from the cache backend's representation (fscache_object) - which may be | ||
151 | requested from either end. | ||
152 | |||
153 | |||
154 | ================= | ||
155 | THE SET OF STATES | ||
156 | ================= | ||
157 | |||
158 | The object state machine has a set of states that it can be in. There are | ||
159 | preparation states in which the object sets itself up and waits for its parent | ||
160 | object to transit to a state that allows access to its children: | ||
161 | |||
162 | (1) State FSCACHE_OBJECT_INIT. | ||
163 | |||
164 | Initialise the object and wait for the parent object to become active. In | ||
165 | the cache, it is expected that it will not be possible to look an object | ||
166 | up from the parent object, until that parent object itself has been looked | ||
167 | up. | ||
168 | |||
169 | There are initialisation states in which the object sets itself up and accesses | ||
170 | disk for the object metadata: | ||
171 | |||
172 | (2) State FSCACHE_OBJECT_LOOKING_UP. | ||
173 | |||
174 | Look up the object on disk, using the parent as a starting point. | ||
175 | FS-Cache expects the cache backend to probe the cache to see whether this | ||
176 | object is represented there, and if it is, to see if it's valid (coherency | ||
177 | management). | ||
178 | |||
179 | The cache should call fscache_object_lookup_negative() to indicate lookup | ||
180 | failure for whatever reason, and should call fscache_obtained_object() to | ||
181 | indicate success. | ||
182 | |||
183 | At the completion of lookup, FS-Cache will let the netfs go ahead with | ||
184 | read operations, no matter whether the file is yet cached. If not yet | ||
185 | cached, read operations will be immediately rejected with ENODATA until | ||
186 | the first known page is uncached - as to that point there can be no data | ||
187 | to be read out of the cache for that file that isn't currently also held | ||
188 | in the pagecache. | ||
189 | |||
190 | (3) State FSCACHE_OBJECT_CREATING. | ||
191 | |||
192 | Create an object on disk, using the parent as a starting point. This | ||
193 | happens if the lookup failed to find the object, or if the object's | ||
194 | coherency data indicated what's on disk is out of date. In this state, | ||
195 | FS-Cache expects the cache to create | ||
196 | |||
197 | The cache should call fscache_obtained_object() if creation completes | ||
198 | successfully, fscache_object_lookup_negative() otherwise. | ||
199 | |||
200 | At the completion of creation, FS-Cache will start processing write | ||
201 | operations the netfs has queued for an object. If creation failed, the | ||
202 | write ops will be transparently discarded, and nothing recorded in the | ||
203 | cache. | ||
204 | |||
205 | There are some normal running states in which the object spends its time | ||
206 | servicing netfs requests: | ||
207 | |||
208 | (4) State FSCACHE_OBJECT_AVAILABLE. | ||
209 | |||
210 | A transient state in which pending operations are started, child objects | ||
211 | are permitted to advance from FSCACHE_OBJECT_INIT state, and temporary | ||
212 | lookup data is freed. | ||
213 | |||
214 | (5) State FSCACHE_OBJECT_ACTIVE. | ||
215 | |||
216 | The normal running state. In this state, requests the netfs makes will be | ||
217 | passed on to the cache. | ||
218 | |||
219 | (6) State FSCACHE_OBJECT_UPDATING. | ||
220 | |||
221 | The state machine comes here to update the object in the cache from the | ||
222 | netfs's records. This involves updating the auxiliary data that is used | ||
223 | to maintain coherency. | ||
224 | |||
225 | And there are terminal states in which an object cleans itself up, deallocates | ||
226 | memory and potentially deletes stuff from disk: | ||
227 | |||
228 | (7) State FSCACHE_OBJECT_LC_DYING. | ||
229 | |||
230 | The object comes here if it is dying because of a lookup or creation | ||
231 | error. This would be due to a disk error or system error of some sort. | ||
232 | Temporary data is cleaned up, and the parent is released. | ||
233 | |||
234 | (8) State FSCACHE_OBJECT_DYING. | ||
235 | |||
236 | The object comes here if it is dying due to an error, because its parent | ||
237 | cookie has been relinquished by the netfs or because the cache is being | ||
238 | withdrawn. | ||
239 | |||
240 | Any child objects waiting on this one are given CPU time so that they too | ||
241 | can destroy themselves. This object waits for all its children to go away | ||
242 | before advancing to the next state. | ||
243 | |||
244 | (9) State FSCACHE_OBJECT_ABORT_INIT. | ||
245 | |||
246 | The object comes to this state if it was waiting on its parent in | ||
247 | FSCACHE_OBJECT_INIT, but its parent died. The object will destroy itself | ||
248 | so that the parent may proceed from the FSCACHE_OBJECT_DYING state. | ||
249 | |||
250 | (10) State FSCACHE_OBJECT_RELEASING. | ||
251 | (11) State FSCACHE_OBJECT_RECYCLING. | ||
252 | |||
253 | The object comes to one of these two states when dying once it is rid of | ||
254 | all its children, if it is dying because the netfs relinquished its | ||
255 | cookie. In the first state, the cached data is expected to persist, and | ||
256 | in the second it will be deleted. | ||
257 | |||
258 | (12) State FSCACHE_OBJECT_WITHDRAWING. | ||
259 | |||
260 | The object transits to this state if the cache decides it wants to | ||
261 | withdraw the object from service, perhaps to make space, but also due to | ||
262 | error or just because the whole cache is being withdrawn. | ||
263 | |||
264 | (13) State FSCACHE_OBJECT_DEAD. | ||
265 | |||
266 | The object transits to this state when the in-memory object record is | ||
267 | ready to be deleted. The object processor shouldn't ever see an object in | ||
268 | this state. | ||
269 | |||
270 | |||
271 | THE SET OF EVENTS | ||
272 | ----------------- | ||
273 | |||
274 | There are a number of events that can be raised to an object state machine: | ||
275 | |||
276 | (*) FSCACHE_OBJECT_EV_UPDATE | ||
277 | |||
278 | The netfs requested that an object be updated. The state machine will ask | ||
279 | the cache backend to update the object, and the cache backend will ask the | ||
280 | netfs for details of the change through its cookie definition ops. | ||
281 | |||
282 | (*) FSCACHE_OBJECT_EV_CLEARED | ||
283 | |||
284 | This is signalled in two circumstances: | ||
285 | |||
286 | (a) when an object's last child object is dropped and | ||
287 | |||
288 | (b) when the last operation outstanding on an object is completed. | ||
289 | |||
290 | This is used to proceed from the dying state. | ||
291 | |||
292 | (*) FSCACHE_OBJECT_EV_ERROR | ||
293 | |||
294 | This is signalled when an I/O error occurs during the processing of some | ||
295 | object. | ||
296 | |||
297 | (*) FSCACHE_OBJECT_EV_RELEASE | ||
298 | (*) FSCACHE_OBJECT_EV_RETIRE | ||
299 | |||
300 | These are signalled when the netfs relinquishes a cookie it was using. | ||
301 | The event selected depends on whether the netfs asks for the backing | ||
302 | object to be retired (deleted) or retained. | ||
303 | |||
304 | (*) FSCACHE_OBJECT_EV_WITHDRAW | ||
305 | |||
306 | This is signalled when the cache backend wants to withdraw an object. | ||
307 | This means that the object will have to be detached from the netfs's | ||
308 | cookie. | ||
309 | |||
310 | Because the withdrawing releasing/retiring events are all handled by the object | ||
311 | state machine, it doesn't matter if there's a collision with both ends trying | ||
312 | to sever the connection at the same time. The state machine can just pick | ||
313 | which one it wants to honour, and that effects the other. | ||
diff --git a/Documentation/filesystems/caching/operations.txt b/Documentation/filesystems/caching/operations.txt new file mode 100644 index 000000000000..b6b070c57cbf --- /dev/null +++ b/Documentation/filesystems/caching/operations.txt | |||
@@ -0,0 +1,213 @@ | |||
1 | ================================ | ||
2 | ASYNCHRONOUS OPERATIONS HANDLING | ||
3 | ================================ | ||
4 | |||
5 | By: David Howells <dhowells@redhat.com> | ||
6 | |||
7 | Contents: | ||
8 | |||
9 | (*) Overview. | ||
10 | |||
11 | (*) Operation record initialisation. | ||
12 | |||
13 | (*) Parameters. | ||
14 | |||
15 | (*) Procedure. | ||
16 | |||
17 | (*) Asynchronous callback. | ||
18 | |||
19 | |||
20 | ======== | ||
21 | OVERVIEW | ||
22 | ======== | ||
23 | |||
24 | FS-Cache has an asynchronous operations handling facility that it uses for its | ||
25 | data storage and retrieval routines. Its operations are represented by | ||
26 | fscache_operation structs, though these are usually embedded into some other | ||
27 | structure. | ||
28 | |||
29 | This facility is available to and expected to be be used by the cache backends, | ||
30 | and FS-Cache will create operations and pass them off to the appropriate cache | ||
31 | backend for completion. | ||
32 | |||
33 | To make use of this facility, <linux/fscache-cache.h> should be #included. | ||
34 | |||
35 | |||
36 | =============================== | ||
37 | OPERATION RECORD INITIALISATION | ||
38 | =============================== | ||
39 | |||
40 | An operation is recorded in an fscache_operation struct: | ||
41 | |||
42 | struct fscache_operation { | ||
43 | union { | ||
44 | struct work_struct fast_work; | ||
45 | struct slow_work slow_work; | ||
46 | }; | ||
47 | unsigned long flags; | ||
48 | fscache_operation_processor_t processor; | ||
49 | ... | ||
50 | }; | ||
51 | |||
52 | Someone wanting to issue an operation should allocate something with this | ||
53 | struct embedded in it. They should initialise it by calling: | ||
54 | |||
55 | void fscache_operation_init(struct fscache_operation *op, | ||
56 | fscache_operation_release_t release); | ||
57 | |||
58 | with the operation to be initialised and the release function to use. | ||
59 | |||
60 | The op->flags parameter should be set to indicate the CPU time provision and | ||
61 | the exclusivity (see the Parameters section). | ||
62 | |||
63 | The op->fast_work, op->slow_work and op->processor flags should be set as | ||
64 | appropriate for the CPU time provision (see the Parameters section). | ||
65 | |||
66 | FSCACHE_OP_WAITING may be set in op->flags prior to each submission of the | ||
67 | operation and waited for afterwards. | ||
68 | |||
69 | |||
70 | ========== | ||
71 | PARAMETERS | ||
72 | ========== | ||
73 | |||
74 | There are a number of parameters that can be set in the operation record's flag | ||
75 | parameter. There are three options for the provision of CPU time in these | ||
76 | operations: | ||
77 | |||
78 | (1) The operation may be done synchronously (FSCACHE_OP_MYTHREAD). A thread | ||
79 | may decide it wants to handle an operation itself without deferring it to | ||
80 | another thread. | ||
81 | |||
82 | This is, for example, used in read operations for calling readpages() on | ||
83 | the backing filesystem in CacheFiles. Although readpages() does an | ||
84 | asynchronous data fetch, the determination of whether pages exist is done | ||
85 | synchronously - and the netfs does not proceed until this has been | ||
86 | determined. | ||
87 | |||
88 | If this option is to be used, FSCACHE_OP_WAITING must be set in op->flags | ||
89 | before submitting the operation, and the operating thread must wait for it | ||
90 | to be cleared before proceeding: | ||
91 | |||
92 | wait_on_bit(&op->flags, FSCACHE_OP_WAITING, | ||
93 | fscache_wait_bit, TASK_UNINTERRUPTIBLE); | ||
94 | |||
95 | |||
96 | (2) The operation may be fast asynchronous (FSCACHE_OP_FAST), in which case it | ||
97 | will be given to keventd to process. Such an operation is not permitted | ||
98 | to sleep on I/O. | ||
99 | |||
100 | This is, for example, used by CacheFiles to copy data from a backing fs | ||
101 | page to a netfs page after the backing fs has read the page in. | ||
102 | |||
103 | If this option is used, op->fast_work and op->processor must be | ||
104 | initialised before submitting the operation: | ||
105 | |||
106 | INIT_WORK(&op->fast_work, do_some_work); | ||
107 | |||
108 | |||
109 | (3) The operation may be slow asynchronous (FSCACHE_OP_SLOW), in which case it | ||
110 | will be given to the slow work facility to process. Such an operation is | ||
111 | permitted to sleep on I/O. | ||
112 | |||
113 | This is, for example, used by FS-Cache to handle background writes of | ||
114 | pages that have just been fetched from a remote server. | ||
115 | |||
116 | If this option is used, op->slow_work and op->processor must be | ||
117 | initialised before submitting the operation: | ||
118 | |||
119 | fscache_operation_init_slow(op, processor) | ||
120 | |||
121 | |||
122 | Furthermore, operations may be one of two types: | ||
123 | |||
124 | (1) Exclusive (FSCACHE_OP_EXCLUSIVE). Operations of this type may not run in | ||
125 | conjunction with any other operation on the object being operated upon. | ||
126 | |||
127 | An example of this is the attribute change operation, in which the file | ||
128 | being written to may need truncation. | ||
129 | |||
130 | (2) Shareable. Operations of this type may be running simultaneously. It's | ||
131 | up to the operation implementation to prevent interference between other | ||
132 | operations running at the same time. | ||
133 | |||
134 | |||
135 | ========= | ||
136 | PROCEDURE | ||
137 | ========= | ||
138 | |||
139 | Operations are used through the following procedure: | ||
140 | |||
141 | (1) The submitting thread must allocate the operation and initialise it | ||
142 | itself. Normally this would be part of a more specific structure with the | ||
143 | generic op embedded within. | ||
144 | |||
145 | (2) The submitting thread must then submit the operation for processing using | ||
146 | one of the following two functions: | ||
147 | |||
148 | int fscache_submit_op(struct fscache_object *object, | ||
149 | struct fscache_operation *op); | ||
150 | |||
151 | int fscache_submit_exclusive_op(struct fscache_object *object, | ||
152 | struct fscache_operation *op); | ||
153 | |||
154 | The first function should be used to submit non-exclusive ops and the | ||
155 | second to submit exclusive ones. The caller must still set the | ||
156 | FSCACHE_OP_EXCLUSIVE flag. | ||
157 | |||
158 | If successful, both functions will assign the operation to the specified | ||
159 | object and return 0. -ENOBUFS will be returned if the object specified is | ||
160 | permanently unavailable. | ||
161 | |||
162 | The operation manager will defer operations on an object that is still | ||
163 | undergoing lookup or creation. The operation will also be deferred if an | ||
164 | operation of conflicting exclusivity is in progress on the object. | ||
165 | |||
166 | If the operation is asynchronous, the manager will retain a reference to | ||
167 | it, so the caller should put their reference to it by passing it to: | ||
168 | |||
169 | void fscache_put_operation(struct fscache_operation *op); | ||
170 | |||
171 | (3) If the submitting thread wants to do the work itself, and has marked the | ||
172 | operation with FSCACHE_OP_MYTHREAD, then it should monitor | ||
173 | FSCACHE_OP_WAITING as described above and check the state of the object if | ||
174 | necessary (the object might have died whilst the thread was waiting). | ||
175 | |||
176 | When it has finished doing its processing, it should call | ||
177 | fscache_put_operation() on it. | ||
178 | |||
179 | (4) The operation holds an effective lock upon the object, preventing other | ||
180 | exclusive ops conflicting until it is released. The operation can be | ||
181 | enqueued for further immediate asynchronous processing by adjusting the | ||
182 | CPU time provisioning option if necessary, eg: | ||
183 | |||
184 | op->flags &= ~FSCACHE_OP_TYPE; | ||
185 | op->flags |= ~FSCACHE_OP_FAST; | ||
186 | |||
187 | and calling: | ||
188 | |||
189 | void fscache_enqueue_operation(struct fscache_operation *op) | ||
190 | |||
191 | This can be used to allow other things to have use of the worker thread | ||
192 | pools. | ||
193 | |||
194 | |||
195 | ===================== | ||
196 | ASYNCHRONOUS CALLBACK | ||
197 | ===================== | ||
198 | |||
199 | When used in asynchronous mode, the worker thread pool will invoke the | ||
200 | processor method with a pointer to the operation. This should then get at the | ||
201 | container struct by using container_of(): | ||
202 | |||
203 | static void fscache_write_op(struct fscache_operation *_op) | ||
204 | { | ||
205 | struct fscache_storage *op = | ||
206 | container_of(_op, struct fscache_storage, op); | ||
207 | ... | ||
208 | } | ||
209 | |||
210 | The caller holds a reference on the operation, and will invoke | ||
211 | fscache_put_operation() when the processor function returns. The processor | ||
212 | function is at liberty to call fscache_enqueue_operation() or to take extra | ||
213 | references. | ||
diff --git a/Documentation/filesystems/exofs.txt b/Documentation/filesystems/exofs.txt new file mode 100644 index 000000000000..0ced74c2f73c --- /dev/null +++ b/Documentation/filesystems/exofs.txt | |||
@@ -0,0 +1,176 @@ | |||
1 | =============================================================================== | ||
2 | WHAT IS EXOFS? | ||
3 | =============================================================================== | ||
4 | |||
5 | exofs is a file system that uses an OSD and exports the API of a normal Linux | ||
6 | file system. Users access exofs like any other local file system, and exofs | ||
7 | will in turn issue commands to the local OSD initiator. | ||
8 | |||
9 | OSD is a new T10 command set that views storage devices not as a large/flat | ||
10 | array of sectors but as a container of objects, each having a length, quota, | ||
11 | time attributes and more. Each object is addressed by a 64bit ID, and is | ||
12 | contained in a 64bit ID partition. Each object has associated attributes | ||
13 | attached to it, which are integral part of the object and provide metadata about | ||
14 | the object. The standard defines some common obligatory attributes, but user | ||
15 | attributes can be added as needed. | ||
16 | |||
17 | =============================================================================== | ||
18 | ENVIRONMENT | ||
19 | =============================================================================== | ||
20 | |||
21 | To use this file system, you need to have an object store to run it on. You | ||
22 | may download a target from: | ||
23 | http://open-osd.org | ||
24 | |||
25 | See Documentation/scsi/osd.txt for how to setup a working osd environment. | ||
26 | |||
27 | =============================================================================== | ||
28 | USAGE | ||
29 | =============================================================================== | ||
30 | |||
31 | 1. Download and compile exofs and open-osd initiator: | ||
32 | You need an external Kernel source tree or kernel headers from your | ||
33 | distribution. (anything based on 2.6.26 or later). | ||
34 | |||
35 | a. download open-osd including exofs source using: | ||
36 | [parent-directory]$ git clone git://git.open-osd.org/open-osd.git | ||
37 | |||
38 | b. Build the library module like this: | ||
39 | [parent-directory]$ make -C KSRC=$(KER_DIR) open-osd | ||
40 | |||
41 | This will build both the open-osd initiator as well as the exofs kernel | ||
42 | module. Use whatever parameters you compiled your Kernel with and | ||
43 | $(KER_DIR) above pointing to the Kernel you compile against. See the file | ||
44 | open-osd/top-level-Makefile for an example. | ||
45 | |||
46 | 2. Get the OSD initiator and target set up properly, and login to the target. | ||
47 | See Documentation/scsi/osd.txt for farther instructions. Also see ./do-osd | ||
48 | for example script that does all these steps. | ||
49 | |||
50 | 3. Insmod the exofs.ko module: | ||
51 | [exofs]$ insmod exofs.ko | ||
52 | |||
53 | 4. Make sure the directory where you want to mount exists. If not, create it. | ||
54 | (For example, mkdir /mnt/exofs) | ||
55 | |||
56 | 5. At first run you will need to invoke the mkfs.exofs application | ||
57 | |||
58 | As an example, this will create the file system on: | ||
59 | /dev/osd0 partition ID 65536 | ||
60 | |||
61 | mkfs.exofs --pid=65536 --format /dev/osd0 | ||
62 | |||
63 | The --format is optional if not specified no OSD_FORMAT will be | ||
64 | preformed and a clean file system will be created in the specified pid, | ||
65 | in the available space of the target. (Use --format=size_in_meg to limit | ||
66 | the total LUN space available) | ||
67 | |||
68 | If pid already exist it will be deleted and a new one will be created in it's | ||
69 | place. Be careful. | ||
70 | |||
71 | An exofs lives inside a single OSD partition. You can create multiple exofs | ||
72 | filesystems on the same device using multiple pids. | ||
73 | |||
74 | (run mkfs.exofs without any parameters for usage help message) | ||
75 | |||
76 | 6. Mount the file system. | ||
77 | |||
78 | For example, to mount /dev/osd0, partition ID 0x10000 on /mnt/exofs: | ||
79 | |||
80 | mount -t exofs -o pid=65536 /dev/osd0 /mnt/exofs/ | ||
81 | |||
82 | 7. For reference (See do-exofs example script): | ||
83 | do-exofs start - an example of how to perform the above steps. | ||
84 | do-exofs stop - an example of how to unmount the file system. | ||
85 | do-exofs format - an example of how to format and mkfs a new exofs. | ||
86 | |||
87 | 8. Extra compilation flags (uncomment in fs/exofs/Kbuild): | ||
88 | CONFIG_EXOFS_DEBUG - for debug messages and extra checks. | ||
89 | |||
90 | =============================================================================== | ||
91 | exofs mount options | ||
92 | =============================================================================== | ||
93 | Similar to any mount command: | ||
94 | mount -t exofs -o exofs_options /dev/osdX mount_exofs_directory | ||
95 | |||
96 | Where: | ||
97 | -t exofs: specifies the exofs file system | ||
98 | |||
99 | /dev/osdX: X is a decimal number. /dev/osdX was created after a successful | ||
100 | login into an OSD target. | ||
101 | |||
102 | mount_exofs_directory: The directory to mount the file system on | ||
103 | |||
104 | exofs specific options: Options are separated by commas (,) | ||
105 | pid=<integer> - The partition number to mount/create as | ||
106 | container of the filesystem. | ||
107 | This option is mandatory | ||
108 | to=<integer> - Timeout in ticks for a single command | ||
109 | default is (60 * HZ) [for debugging only] | ||
110 | |||
111 | =============================================================================== | ||
112 | DESIGN | ||
113 | =============================================================================== | ||
114 | |||
115 | * The file system control block (AKA on-disk superblock) resides in an object | ||
116 | with a special ID (defined in common.h). | ||
117 | Information included in the file system control block is used to fill the | ||
118 | in-memory superblock structure at mount time. This object is created before | ||
119 | the file system is used by mkexofs.c It contains information such as: | ||
120 | - The file system's magic number | ||
121 | - The next inode number to be allocated | ||
122 | |||
123 | * Each file resides in its own object and contains the data (and it will be | ||
124 | possible to extend the file over multiple objects, though this has not been | ||
125 | implemented yet). | ||
126 | |||
127 | * A directory is treated as a file, and essentially contains a list of <file | ||
128 | name, inode #> pairs for files that are found in that directory. The object | ||
129 | IDs correspond to the files' inode numbers and will be allocated according to | ||
130 | a bitmap (stored in a separate object). Now they are allocated using a | ||
131 | counter. | ||
132 | |||
133 | * Each file's control block (AKA on-disk inode) is stored in its object's | ||
134 | attributes. This applies to both regular files and other types (directories, | ||
135 | device files, symlinks, etc.). | ||
136 | |||
137 | * Credentials are generated per object (inode and superblock) when they is | ||
138 | created in memory (read off disk or created). The credential works for all | ||
139 | operations and is used as long as the object remains in memory. | ||
140 | |||
141 | * Async OSD operations are used whenever possible, but the target may execute | ||
142 | them out of order. The operations that concern us are create, delete, | ||
143 | readpage, writepage, update_inode, and truncate. The following pairs of | ||
144 | operations should execute in the order written, and we need to prevent them | ||
145 | from executing in reverse order: | ||
146 | - The following are handled with the OBJ_CREATED and OBJ_2BCREATED | ||
147 | flags. OBJ_CREATED is set when we know the object exists on the OSD - | ||
148 | in create's callback function, and when we successfully do a read_inode. | ||
149 | OBJ_2BCREATED is set in the beginning of the create function, so we | ||
150 | know that we should wait. | ||
151 | - create/delete: delete should wait until the object is created | ||
152 | on the OSD. | ||
153 | - create/readpage: readpage should be able to return a page | ||
154 | full of zeroes in this case. If there was a write already | ||
155 | en-route (i.e. create, writepage, readpage) then the page | ||
156 | would be locked, and so it would really be the same as | ||
157 | create/writepage. | ||
158 | - create/writepage: if writepage is called for a sync write, it | ||
159 | should wait until the object is created on the OSD. | ||
160 | Otherwise, it should just return. | ||
161 | - create/truncate: truncate should wait until the object is | ||
162 | created on the OSD. | ||
163 | - create/update_inode: update_inode should wait until the | ||
164 | object is created on the OSD. | ||
165 | - Handled by VFS locks: | ||
166 | - readpage/delete: shouldn't happen because of page lock. | ||
167 | - writepage/delete: shouldn't happen because of page lock. | ||
168 | - readpage/writepage: shouldn't happen because of page lock. | ||
169 | |||
170 | =============================================================================== | ||
171 | LICENSE/COPYRIGHT | ||
172 | =============================================================================== | ||
173 | The exofs file system is based on ext2 v0.5b (distributed with the Linux kernel | ||
174 | version 2.6.10). All files include the original copyrights, and the license | ||
175 | is GPL version 2 (only version 2, as is true for the Linux kernel). The | ||
176 | Linux kernel can be downloaded from www.kernel.org. | ||
diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt index 4333e836c495..e055acb6b2d4 100644 --- a/Documentation/filesystems/ext2.txt +++ b/Documentation/filesystems/ext2.txt | |||
@@ -373,10 +373,11 @@ Filesystem Resizing http://ext2resize.sourceforge.net/ | |||
373 | Compression (*) http://e2compr.sourceforge.net/ | 373 | Compression (*) http://e2compr.sourceforge.net/ |
374 | 374 | ||
375 | Implementations for: | 375 | Implementations for: |
376 | Windows 95/98/NT/2000 http://uranus.it.swin.edu.au/~jn/linux/Explore2fs.htm | 376 | Windows 95/98/NT/2000 http://www.chrysocome.net/explore2fs |
377 | Windows 95 (*) http://www.yipton.demon.co.uk/content.html#FSDEXT2 | 377 | Windows 95 (*) http://www.yipton.net/content.html#FSDEXT2 |
378 | DOS client (*) ftp://metalab.unc.edu/pub/Linux/system/filesystems/ext2/ | 378 | DOS client (*) ftp://metalab.unc.edu/pub/Linux/system/filesystems/ext2/ |
379 | OS/2 http://perso.wanadoo.fr/matthieu.willm/ext2-os2/ | 379 | OS/2 (+) ftp://metalab.unc.edu/pub/Linux/system/filesystems/ext2/ |
380 | RISC OS client ftp://ftp.barnet.ac.uk/pub/acorn/armlinux/iscafs/ | 380 | RISC OS client http://www.esw-heim.tu-clausthal.de/~marco/smorbrod/IscaFS/ |
381 | 381 | ||
382 | (*) no longer actively developed/supported (as of Apr 2001) | 382 | (*) no longer actively developed/supported (as of Apr 2001) |
383 | (+) no longer actively developed/supported (as of Mar 2009) | ||
diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt index 9dd2a3bb2acc..570f9bd9be2b 100644 --- a/Documentation/filesystems/ext3.txt +++ b/Documentation/filesystems/ext3.txt | |||
@@ -14,6 +14,11 @@ Options | |||
14 | When mounting an ext3 filesystem, the following option are accepted: | 14 | When mounting an ext3 filesystem, the following option are accepted: |
15 | (*) == default | 15 | (*) == default |
16 | 16 | ||
17 | ro Mount filesystem read only. Note that ext3 will replay | ||
18 | the journal (and thus write to the partition) even when | ||
19 | mounted "read only". Mount options "ro,noload" can be | ||
20 | used to prevent writes to the filesystem. | ||
21 | |||
17 | journal=update Update the ext3 file system's journal to the current | 22 | journal=update Update the ext3 file system's journal to the current |
18 | format. | 23 | format. |
19 | 24 | ||
@@ -27,7 +32,9 @@ journal_dev=devnum When the external journal device's major/minor numbers | |||
27 | identified through its new major/minor numbers encoded | 32 | identified through its new major/minor numbers encoded |
28 | in devnum. | 33 | in devnum. |
29 | 34 | ||
30 | noload Don't load the journal on mounting. | 35 | noload Don't load the journal on mounting. Note that this forces |
36 | mount of inconsistent filesystem, which can lead to | ||
37 | various problems. | ||
31 | 38 | ||
32 | data=journal All data are committed into the journal prior to being | 39 | data=journal All data are committed into the journal prior to being |
33 | written into the main file system. | 40 | written into the main file system. |
@@ -92,9 +99,12 @@ nocheck | |||
92 | 99 | ||
93 | debug Extra debugging information is sent to syslog. | 100 | debug Extra debugging information is sent to syslog. |
94 | 101 | ||
95 | errors=remount-ro(*) Remount the filesystem read-only on an error. | 102 | errors=remount-ro Remount the filesystem read-only on an error. |
96 | errors=continue Keep going on a filesystem error. | 103 | errors=continue Keep going on a filesystem error. |
97 | errors=panic Panic and halt the machine if an error occurs. | 104 | errors=panic Panic and halt the machine if an error occurs. |
105 | (These mount options override the errors behavior | ||
106 | specified in the superblock, which can be | ||
107 | configured using tune2fs.) | ||
98 | 108 | ||
99 | data_err=ignore(*) Just print an error message if an error occurs | 109 | data_err=ignore(*) Just print an error message if an error occurs |
100 | in a file data buffer in ordered mode. | 110 | in a file data buffer in ordered mode. |
@@ -198,5 +208,5 @@ kernel source: <file:fs/ext3/> | |||
198 | programs: http://e2fsprogs.sourceforge.net/ | 208 | programs: http://e2fsprogs.sourceforge.net/ |
199 | http://ext2resize.sourceforge.net | 209 | http://ext2resize.sourceforge.net |
200 | 210 | ||
201 | useful links: http://www-106.ibm.com/developerworks/linux/library/l-fs7/ | 211 | useful links: http://www.ibm.com/developerworks/library/l-fs7.html |
202 | http://www-106.ibm.com/developerworks/linux/library/l-fs8/ | 212 | http://www.ibm.com/developerworks/library/l-fs8.html |
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index cec829bc7291..97882df04865 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt | |||
@@ -85,7 +85,7 @@ Note: More extensive information for getting started with ext4 can be | |||
85 | * extent format more robust in face of on-disk corruption due to magics, | 85 | * extent format more robust in face of on-disk corruption due to magics, |
86 | * internal redundancy in tree | 86 | * internal redundancy in tree |
87 | * improved file allocation (multi-block alloc) | 87 | * improved file allocation (multi-block alloc) |
88 | * fix 32000 subdirectory limit | 88 | * lift 32000 subdirectory limit imposed by i_links_count[1] |
89 | * nsec timestamps for mtime, atime, ctime, create time | 89 | * nsec timestamps for mtime, atime, ctime, create time |
90 | * inode version field on disk (NFSv4, Lustre) | 90 | * inode version field on disk (NFSv4, Lustre) |
91 | * reduced e2fsck time via uninit_bg feature | 91 | * reduced e2fsck time via uninit_bg feature |
@@ -100,6 +100,9 @@ Note: More extensive information for getting started with ext4 can be | |||
100 | * efficent new ordered mode in JBD2 and ext4(avoid using buffer head to force | 100 | * efficent new ordered mode in JBD2 and ext4(avoid using buffer head to force |
101 | the ordering) | 101 | the ordering) |
102 | 102 | ||
103 | [1] Filesystems with a block size of 1k may see a limit imposed by the | ||
104 | directory hash tree having a maximum depth of two. | ||
105 | |||
103 | 2.2 Candidate features for future inclusion | 106 | 2.2 Candidate features for future inclusion |
104 | 107 | ||
105 | * Online defrag (patches available but not well tested) | 108 | * Online defrag (patches available but not well tested) |
@@ -180,8 +183,8 @@ commit=nrsec (*) Ext4 can be told to sync all its data and metadata | |||
180 | performance. | 183 | performance. |
181 | 184 | ||
182 | barrier=<0|1(*)> This enables/disables the use of write barriers in | 185 | barrier=<0|1(*)> This enables/disables the use of write barriers in |
183 | the jbd code. barrier=0 disables, barrier=1 enables. | 186 | barrier(*) the jbd code. barrier=0 disables, barrier=1 enables. |
184 | This also requires an IO stack which can support | 187 | nobarrier This also requires an IO stack which can support |
185 | barriers, and if jbd gets an error on a barrier | 188 | barriers, and if jbd gets an error on a barrier |
186 | write, it will disable again with a warning. | 189 | write, it will disable again with a warning. |
187 | Write barriers enforce proper on-disk ordering | 190 | Write barriers enforce proper on-disk ordering |
@@ -189,6 +192,9 @@ barrier=<0|1(*)> This enables/disables the use of write barriers in | |||
189 | safe to use, at some performance penalty. If | 192 | safe to use, at some performance penalty. If |
190 | your disks are battery-backed in one way or another, | 193 | your disks are battery-backed in one way or another, |
191 | disabling barriers may safely improve performance. | 194 | disabling barriers may safely improve performance. |
195 | The mount options "barrier" and "nobarrier" can | ||
196 | also be used to enable or disable barriers, for | ||
197 | consistency with other ext4 mount options. | ||
192 | 198 | ||
193 | inode_readahead=n This tuning parameter controls the maximum | 199 | inode_readahead=n This tuning parameter controls the maximum |
194 | number of inode table blocks that ext4's inode | 200 | number of inode table blocks that ext4's inode |
@@ -310,6 +316,24 @@ journal_ioprio=prio The I/O priority (from 0 to 7, where 0 is the | |||
310 | a slightly higher priority than the default I/O | 316 | a slightly higher priority than the default I/O |
311 | priority. | 317 | priority. |
312 | 318 | ||
319 | auto_da_alloc(*) Many broken applications don't use fsync() when | ||
320 | noauto_da_alloc replacing existing files via patterns such as | ||
321 | fd = open("foo.new")/write(fd,..)/close(fd)/ | ||
322 | rename("foo.new", "foo"), or worse yet, | ||
323 | fd = open("foo", O_TRUNC)/write(fd,..)/close(fd). | ||
324 | If auto_da_alloc is enabled, ext4 will detect | ||
325 | the replace-via-rename and replace-via-truncate | ||
326 | patterns and force that any delayed allocation | ||
327 | blocks are allocated such that at the next | ||
328 | journal commit, in the default data=ordered | ||
329 | mode, the data blocks of the new file are forced | ||
330 | to disk before the rename() operation is | ||
331 | commited. This provides roughly the same level | ||
332 | of guarantees as ext3, and avoids the | ||
333 | "zero-length" problem that can happen when a | ||
334 | system crashes before the delayed allocation | ||
335 | blocks are forced to disk. | ||
336 | |||
313 | Data Mode | 337 | Data Mode |
314 | ========= | 338 | ========= |
315 | There are 3 different data modes: | 339 | There are 3 different data modes: |
diff --git a/Documentation/filesystems/knfsd-stats.txt b/Documentation/filesystems/knfsd-stats.txt new file mode 100644 index 000000000000..64ced5149d37 --- /dev/null +++ b/Documentation/filesystems/knfsd-stats.txt | |||
@@ -0,0 +1,159 @@ | |||
1 | |||
2 | Kernel NFS Server Statistics | ||
3 | ============================ | ||
4 | |||
5 | This document describes the format and semantics of the statistics | ||
6 | which the kernel NFS server makes available to userspace. These | ||
7 | statistics are available in several text form pseudo files, each of | ||
8 | which is described separately below. | ||
9 | |||
10 | In most cases you don't need to know these formats, as the nfsstat(8) | ||
11 | program from the nfs-utils distribution provides a helpful command-line | ||
12 | interface for extracting and printing them. | ||
13 | |||
14 | All the files described here are formatted as a sequence of text lines, | ||
15 | separated by newline '\n' characters. Lines beginning with a hash | ||
16 | '#' character are comments intended for humans and should be ignored | ||
17 | by parsing routines. All other lines contain a sequence of fields | ||
18 | separated by whitespace. | ||
19 | |||
20 | /proc/fs/nfsd/pool_stats | ||
21 | ------------------------ | ||
22 | |||
23 | This file is available in kernels from 2.6.30 onwards, if the | ||
24 | /proc/fs/nfsd filesystem is mounted (it almost always should be). | ||
25 | |||
26 | The first line is a comment which describes the fields present in | ||
27 | all the other lines. The other lines present the following data as | ||
28 | a sequence of unsigned decimal numeric fields. One line is shown | ||
29 | for each NFS thread pool. | ||
30 | |||
31 | All counters are 64 bits wide and wrap naturally. There is no way | ||
32 | to zero these counters, instead applications should do their own | ||
33 | rate conversion. | ||
34 | |||
35 | pool | ||
36 | The id number of the NFS thread pool to which this line applies. | ||
37 | This number does not change. | ||
38 | |||
39 | Thread pool ids are a contiguous set of small integers starting | ||
40 | at zero. The maximum value depends on the thread pool mode, but | ||
41 | currently cannot be larger than the number of CPUs in the system. | ||
42 | Note that in the default case there will be a single thread pool | ||
43 | which contains all the nfsd threads and all the CPUs in the system, | ||
44 | and thus this file will have a single line with a pool id of "0". | ||
45 | |||
46 | packets-arrived | ||
47 | Counts how many NFS packets have arrived. More precisely, this | ||
48 | is the number of times that the network stack has notified the | ||
49 | sunrpc server layer that new data may be available on a transport | ||
50 | (e.g. an NFS or UDP socket or an NFS/RDMA endpoint). | ||
51 | |||
52 | Depending on the NFS workload patterns and various network stack | ||
53 | effects (such as Large Receive Offload) which can combine packets | ||
54 | on the wire, this may be either more or less than the number | ||
55 | of NFS calls received (which statistic is available elsewhere). | ||
56 | However this is a more accurate and less workload-dependent measure | ||
57 | of how much CPU load is being placed on the sunrpc server layer | ||
58 | due to NFS network traffic. | ||
59 | |||
60 | sockets-enqueued | ||
61 | Counts how many times an NFS transport is enqueued to wait for | ||
62 | an nfsd thread to service it, i.e. no nfsd thread was considered | ||
63 | available. | ||
64 | |||
65 | The circumstance this statistic tracks indicates that there was NFS | ||
66 | network-facing work to be done but it couldn't be done immediately, | ||
67 | thus introducing a small delay in servicing NFS calls. The ideal | ||
68 | rate of change for this counter is zero; significantly non-zero | ||
69 | values may indicate a performance limitation. | ||
70 | |||
71 | This can happen either because there are too few nfsd threads in the | ||
72 | thread pool for the NFS workload (the workload is thread-limited), | ||
73 | or because the NFS workload needs more CPU time than is available in | ||
74 | the thread pool (the workload is CPU-limited). In the former case, | ||
75 | configuring more nfsd threads will probably improve the performance | ||
76 | of the NFS workload. In the latter case, the sunrpc server layer is | ||
77 | already choosing not to wake idle nfsd threads because there are too | ||
78 | many nfsd threads which want to run but cannot, so configuring more | ||
79 | nfsd threads will make no difference whatsoever. The overloads-avoided | ||
80 | statistic (see below) can be used to distinguish these cases. | ||
81 | |||
82 | threads-woken | ||
83 | Counts how many times an idle nfsd thread is woken to try to | ||
84 | receive some data from an NFS transport. | ||
85 | |||
86 | This statistic tracks the circumstance where incoming | ||
87 | network-facing NFS work is being handled quickly, which is a good | ||
88 | thing. The ideal rate of change for this counter will be close | ||
89 | to but less than the rate of change of the packets-arrived counter. | ||
90 | |||
91 | overloads-avoided | ||
92 | Counts how many times the sunrpc server layer chose not to wake an | ||
93 | nfsd thread, despite the presence of idle nfsd threads, because | ||
94 | too many nfsd threads had been recently woken but could not get | ||
95 | enough CPU time to actually run. | ||
96 | |||
97 | This statistic counts a circumstance where the sunrpc layer | ||
98 | heuristically avoids overloading the CPU scheduler with too many | ||
99 | runnable nfsd threads. The ideal rate of change for this counter | ||
100 | is zero. Significant non-zero values indicate that the workload | ||
101 | is CPU limited. Usually this is associated with heavy CPU usage | ||
102 | on all the CPUs in the nfsd thread pool. | ||
103 | |||
104 | If a sustained large overloads-avoided rate is detected on a pool, | ||
105 | the top(1) utility should be used to check for the following | ||
106 | pattern of CPU usage on all the CPUs associated with the given | ||
107 | nfsd thread pool. | ||
108 | |||
109 | - %us ~= 0 (as you're *NOT* running applications on your NFS server) | ||
110 | |||
111 | - %wa ~= 0 | ||
112 | |||
113 | - %id ~= 0 | ||
114 | |||
115 | - %sy + %hi + %si ~= 100 | ||
116 | |||
117 | If this pattern is seen, configuring more nfsd threads will *not* | ||
118 | improve the performance of the workload. If this patten is not | ||
119 | seen, then something more subtle is wrong. | ||
120 | |||
121 | threads-timedout | ||
122 | Counts how many times an nfsd thread triggered an idle timeout, | ||
123 | i.e. was not woken to handle any incoming network packets for | ||
124 | some time. | ||
125 | |||
126 | This statistic counts a circumstance where there are more nfsd | ||
127 | threads configured than can be used by the NFS workload. This is | ||
128 | a clue that the number of nfsd threads can be reduced without | ||
129 | affecting performance. Unfortunately, it's only a clue and not | ||
130 | a strong indication, for a couple of reasons: | ||
131 | |||
132 | - Currently the rate at which the counter is incremented is quite | ||
133 | slow; the idle timeout is 60 minutes. Unless the NFS workload | ||
134 | remains constant for hours at a time, this counter is unlikely | ||
135 | to be providing information that is still useful. | ||
136 | |||
137 | - It is usually a wise policy to provide some slack, | ||
138 | i.e. configure a few more nfsds than are currently needed, | ||
139 | to allow for future spikes in load. | ||
140 | |||
141 | |||
142 | Note that incoming packets on NFS transports will be dealt with in | ||
143 | one of three ways. An nfsd thread can be woken (threads-woken counts | ||
144 | this case), or the transport can be enqueued for later attention | ||
145 | (sockets-enqueued counts this case), or the packet can be temporarily | ||
146 | deferred because the transport is currently being used by an nfsd | ||
147 | thread. This last case is not very interesting and is not explicitly | ||
148 | counted, but can be inferred from the other counters thus: | ||
149 | |||
150 | packets-deferred = packets-arrived - ( sockets-enqueued + threads-woken ) | ||
151 | |||
152 | |||
153 | More | ||
154 | ---- | ||
155 | Descriptions of the other statistics file should go here. | ||
156 | |||
157 | |||
158 | Greg Banks <gnb@sgi.com> | ||
159 | 26 Mar 2009 | ||
diff --git a/Documentation/filesystems/nfs41-server.txt b/Documentation/filesystems/nfs41-server.txt new file mode 100644 index 000000000000..05d81cbcb2e1 --- /dev/null +++ b/Documentation/filesystems/nfs41-server.txt | |||
@@ -0,0 +1,161 @@ | |||
1 | NFSv4.1 Server Implementation | ||
2 | |||
3 | Server support for minorversion 1 can be controlled using the | ||
4 | /proc/fs/nfsd/versions control file. The string output returned | ||
5 | by reading this file will contain either "+4.1" or "-4.1" | ||
6 | correspondingly. | ||
7 | |||
8 | Currently, server support for minorversion 1 is disabled by default. | ||
9 | It can be enabled at run time by writing the string "+4.1" to | ||
10 | the /proc/fs/nfsd/versions control file. Note that to write this | ||
11 | control file, the nfsd service must be taken down. Use your user-mode | ||
12 | nfs-utils to set this up; see rpc.nfsd(8) | ||
13 | |||
14 | The NFSv4 minorversion 1 (NFSv4.1) implementation in nfsd is based | ||
15 | on the latest NFSv4.1 Internet Draft: | ||
16 | http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-29 | ||
17 | |||
18 | From the many new features in NFSv4.1 the current implementation | ||
19 | focuses on the mandatory-to-implement NFSv4.1 Sessions, providing | ||
20 | "exactly once" semantics and better control and throttling of the | ||
21 | resources allocated for each client. | ||
22 | |||
23 | Other NFSv4.1 features, Parallel NFS operations in particular, | ||
24 | are still under development out of tree. | ||
25 | See http://wiki.linux-nfs.org/wiki/index.php/PNFS_prototype_design | ||
26 | for more information. | ||
27 | |||
28 | The table below, taken from the NFSv4.1 document, lists | ||
29 | the operations that are mandatory to implement (REQ), optional | ||
30 | (OPT), and NFSv4.0 operations that are required not to implement (MNI) | ||
31 | in minor version 1. The first column indicates the operations that | ||
32 | are not supported yet by the linux server implementation. | ||
33 | |||
34 | The OPTIONAL features identified and their abbreviations are as follows: | ||
35 | pNFS Parallel NFS | ||
36 | FDELG File Delegations | ||
37 | DDELG Directory Delegations | ||
38 | |||
39 | The following abbreviations indicate the linux server implementation status. | ||
40 | I Implemented NFSv4.1 operations. | ||
41 | NS Not Supported. | ||
42 | NS* unimplemented optional feature. | ||
43 | P pNFS features implemented out of tree. | ||
44 | PNS pNFS features that are not supported yet (out of tree). | ||
45 | |||
46 | Operations | ||
47 | |||
48 | +----------------------+------------+--------------+----------------+ | ||
49 | | Operation | REQ, REC, | Feature | Definition | | ||
50 | | | OPT, or | (REQ, REC, | | | ||
51 | | | MNI | or OPT) | | | ||
52 | +----------------------+------------+--------------+----------------+ | ||
53 | | ACCESS | REQ | | Section 18.1 | | ||
54 | NS | BACKCHANNEL_CTL | REQ | | Section 18.33 | | ||
55 | NS | BIND_CONN_TO_SESSION | REQ | | Section 18.34 | | ||
56 | | CLOSE | REQ | | Section 18.2 | | ||
57 | | COMMIT | REQ | | Section 18.3 | | ||
58 | | CREATE | REQ | | Section 18.4 | | ||
59 | I | CREATE_SESSION | REQ | | Section 18.36 | | ||
60 | NS*| DELEGPURGE | OPT | FDELG (REQ) | Section 18.5 | | ||
61 | | DELEGRETURN | OPT | FDELG, | Section 18.6 | | ||
62 | | | | DDELG, pNFS | | | ||
63 | | | | (REQ) | | | ||
64 | NS | DESTROY_CLIENTID | REQ | | Section 18.50 | | ||
65 | I | DESTROY_SESSION | REQ | | Section 18.37 | | ||
66 | I | EXCHANGE_ID | REQ | | Section 18.35 | | ||
67 | NS | FREE_STATEID | REQ | | Section 18.38 | | ||
68 | | GETATTR | REQ | | Section 18.7 | | ||
69 | P | GETDEVICEINFO | OPT | pNFS (REQ) | Section 18.40 | | ||
70 | P | GETDEVICELIST | OPT | pNFS (OPT) | Section 18.41 | | ||
71 | | GETFH | REQ | | Section 18.8 | | ||
72 | NS*| GET_DIR_DELEGATION | OPT | DDELG (REQ) | Section 18.39 | | ||
73 | P | LAYOUTCOMMIT | OPT | pNFS (REQ) | Section 18.42 | | ||
74 | P | LAYOUTGET | OPT | pNFS (REQ) | Section 18.43 | | ||
75 | P | LAYOUTRETURN | OPT | pNFS (REQ) | Section 18.44 | | ||
76 | | LINK | OPT | | Section 18.9 | | ||
77 | | LOCK | REQ | | Section 18.10 | | ||
78 | | LOCKT | REQ | | Section 18.11 | | ||
79 | | LOCKU | REQ | | Section 18.12 | | ||
80 | | LOOKUP | REQ | | Section 18.13 | | ||
81 | | LOOKUPP | REQ | | Section 18.14 | | ||
82 | | NVERIFY | REQ | | Section 18.15 | | ||
83 | | OPEN | REQ | | Section 18.16 | | ||
84 | NS*| OPENATTR | OPT | | Section 18.17 | | ||
85 | | OPEN_CONFIRM | MNI | | N/A | | ||
86 | | OPEN_DOWNGRADE | REQ | | Section 18.18 | | ||
87 | | PUTFH | REQ | | Section 18.19 | | ||
88 | | PUTPUBFH | REQ | | Section 18.20 | | ||
89 | | PUTROOTFH | REQ | | Section 18.21 | | ||
90 | | READ | REQ | | Section 18.22 | | ||
91 | | READDIR | REQ | | Section 18.23 | | ||
92 | | READLINK | OPT | | Section 18.24 | | ||
93 | NS | RECLAIM_COMPLETE | REQ | | Section 18.51 | | ||
94 | | RELEASE_LOCKOWNER | MNI | | N/A | | ||
95 | | REMOVE | REQ | | Section 18.25 | | ||
96 | | RENAME | REQ | | Section 18.26 | | ||
97 | | RENEW | MNI | | N/A | | ||
98 | | RESTOREFH | REQ | | Section 18.27 | | ||
99 | | SAVEFH | REQ | | Section 18.28 | | ||
100 | | SECINFO | REQ | | Section 18.29 | | ||
101 | NS | SECINFO_NO_NAME | REC | pNFS files | Section 18.45, | | ||
102 | | | | layout (REQ) | Section 13.12 | | ||
103 | I | SEQUENCE | REQ | | Section 18.46 | | ||
104 | | SETATTR | REQ | | Section 18.30 | | ||
105 | | SETCLIENTID | MNI | | N/A | | ||
106 | | SETCLIENTID_CONFIRM | MNI | | N/A | | ||
107 | NS | SET_SSV | REQ | | Section 18.47 | | ||
108 | NS | TEST_STATEID | REQ | | Section 18.48 | | ||
109 | | VERIFY | REQ | | Section 18.31 | | ||
110 | NS*| WANT_DELEGATION | OPT | FDELG (OPT) | Section 18.49 | | ||
111 | | WRITE | REQ | | Section 18.32 | | ||
112 | |||
113 | Callback Operations | ||
114 | |||
115 | +-------------------------+-----------+-------------+---------------+ | ||
116 | | Operation | REQ, REC, | Feature | Definition | | ||
117 | | | OPT, or | (REQ, REC, | | | ||
118 | | | MNI | or OPT) | | | ||
119 | +-------------------------+-----------+-------------+---------------+ | ||
120 | | CB_GETATTR | OPT | FDELG (REQ) | Section 20.1 | | ||
121 | P | CB_LAYOUTRECALL | OPT | pNFS (REQ) | Section 20.3 | | ||
122 | NS*| CB_NOTIFY | OPT | DDELG (REQ) | Section 20.4 | | ||
123 | P | CB_NOTIFY_DEVICEID | OPT | pNFS (OPT) | Section 20.12 | | ||
124 | NS*| CB_NOTIFY_LOCK | OPT | | Section 20.11 | | ||
125 | NS*| CB_PUSH_DELEG | OPT | FDELG (OPT) | Section 20.5 | | ||
126 | | CB_RECALL | OPT | FDELG, | Section 20.2 | | ||
127 | | | | DDELG, pNFS | | | ||
128 | | | | (REQ) | | | ||
129 | NS*| CB_RECALL_ANY | OPT | FDELG, | Section 20.6 | | ||
130 | | | | DDELG, pNFS | | | ||
131 | | | | (REQ) | | | ||
132 | NS | CB_RECALL_SLOT | REQ | | Section 20.8 | | ||
133 | NS*| CB_RECALLABLE_OBJ_AVAIL | OPT | DDELG, pNFS | Section 20.7 | | ||
134 | | | | (REQ) | | | ||
135 | I | CB_SEQUENCE | OPT | FDELG, | Section 20.9 | | ||
136 | | | | DDELG, pNFS | | | ||
137 | | | | (REQ) | | | ||
138 | NS*| CB_WANTS_CANCELLED | OPT | FDELG, | Section 20.10 | | ||
139 | | | | DDELG, pNFS | | | ||
140 | | | | (REQ) | | | ||
141 | +-------------------------+-----------+-------------+---------------+ | ||
142 | |||
143 | Implementation notes: | ||
144 | |||
145 | EXCHANGE_ID: | ||
146 | * only SP4_NONE state protection supported | ||
147 | * implementation ids are ignored | ||
148 | |||
149 | CREATE_SESSION: | ||
150 | * backchannel attributes are ignored | ||
151 | * backchannel security parameters are ignored | ||
152 | |||
153 | SEQUENCE: | ||
154 | * no support for dynamic slot table renegotiation (optional) | ||
155 | |||
156 | nfsv4.1 COMPOUND rules: | ||
157 | The following cases aren't supported yet: | ||
158 | * Enforcing of NFS4ERR_NOT_ONLY_OP for: BIND_CONN_TO_SESSION, CREATE_SESSION, | ||
159 | DESTROY_CLIENTID, DESTROY_SESSION, EXCHANGE_ID. | ||
160 | * DESTROY_SESSION MUST be the final operation in the COMPOUND request. | ||
161 | |||
diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt new file mode 100644 index 000000000000..55c4300abfcb --- /dev/null +++ b/Documentation/filesystems/nilfs2.txt | |||
@@ -0,0 +1,200 @@ | |||
1 | NILFS2 | ||
2 | ------ | ||
3 | |||
4 | NILFS2 is a log-structured file system (LFS) supporting continuous | ||
5 | snapshotting. In addition to versioning capability of the entire file | ||
6 | system, users can even restore files mistakenly overwritten or | ||
7 | destroyed just a few seconds ago. Since NILFS2 can keep consistency | ||
8 | like conventional LFS, it achieves quick recovery after system | ||
9 | crashes. | ||
10 | |||
11 | NILFS2 creates a number of checkpoints every few seconds or per | ||
12 | synchronous write basis (unless there is no change). Users can select | ||
13 | significant versions among continuously created checkpoints, and can | ||
14 | change them into snapshots which will be preserved until they are | ||
15 | changed back to checkpoints. | ||
16 | |||
17 | There is no limit on the number of snapshots until the volume gets | ||
18 | full. Each snapshot is mountable as a read-only file system | ||
19 | concurrently with its writable mount, and this feature is convenient | ||
20 | for online backup. | ||
21 | |||
22 | The userland tools are included in nilfs-utils package, which is | ||
23 | available from the following download page. At least "mkfs.nilfs2", | ||
24 | "mount.nilfs2", "umount.nilfs2", and "nilfs_cleanerd" (so called | ||
25 | cleaner or garbage collector) are required. Details on the tools are | ||
26 | described in the man pages included in the package. | ||
27 | |||
28 | Project web page: http://www.nilfs.org/en/ | ||
29 | Download page: http://www.nilfs.org/en/download.html | ||
30 | Git tree web page: http://www.nilfs.org/git/ | ||
31 | NILFS mailing lists: http://www.nilfs.org/mailman/listinfo/users | ||
32 | |||
33 | Caveats | ||
34 | ======= | ||
35 | |||
36 | Features which NILFS2 does not support yet: | ||
37 | |||
38 | - atime | ||
39 | - extended attributes | ||
40 | - POSIX ACLs | ||
41 | - quotas | ||
42 | - writable snapshots | ||
43 | - remote backup (CDP) | ||
44 | - data integrity | ||
45 | - defragmentation | ||
46 | |||
47 | Mount options | ||
48 | ============= | ||
49 | |||
50 | NILFS2 supports the following mount options: | ||
51 | (*) == default | ||
52 | |||
53 | barrier=on(*) This enables/disables barriers. barrier=off disables | ||
54 | it, barrier=on enables it. | ||
55 | errors=continue(*) Keep going on a filesystem error. | ||
56 | errors=remount-ro Remount the filesystem read-only on an error. | ||
57 | errors=panic Panic and halt the machine if an error occurs. | ||
58 | cp=n Specify the checkpoint-number of the snapshot to be | ||
59 | mounted. Checkpoints and snapshots are listed by lscp | ||
60 | user command. Only the checkpoints marked as snapshot | ||
61 | are mountable with this option. Snapshot is read-only, | ||
62 | so a read-only mount option must be specified together. | ||
63 | order=relaxed(*) Apply relaxed order semantics that allows modified data | ||
64 | blocks to be written to disk without making a | ||
65 | checkpoint if no metadata update is going. This mode | ||
66 | is equivalent to the ordered data mode of the ext3 | ||
67 | filesystem except for the updates on data blocks still | ||
68 | conserve atomicity. This will improve synchronous | ||
69 | write performance for overwriting. | ||
70 | order=strict Apply strict in-order semantics that preserves sequence | ||
71 | of all file operations including overwriting of data | ||
72 | blocks. That means, it is guaranteed that no | ||
73 | overtaking of events occurs in the recovered file | ||
74 | system after a crash. | ||
75 | |||
76 | NILFS2 usage | ||
77 | ============ | ||
78 | |||
79 | To use nilfs2 as a local file system, simply: | ||
80 | |||
81 | # mkfs -t nilfs2 /dev/block_device | ||
82 | # mount -t nilfs2 /dev/block_device /dir | ||
83 | |||
84 | This will also invoke the cleaner through the mount helper program | ||
85 | (mount.nilfs2). | ||
86 | |||
87 | Checkpoints and snapshots are managed by the following commands. | ||
88 | Their manpages are included in the nilfs-utils package above. | ||
89 | |||
90 | lscp list checkpoints or snapshots. | ||
91 | mkcp make a checkpoint or a snapshot. | ||
92 | chcp change an existing checkpoint to a snapshot or vice versa. | ||
93 | rmcp invalidate specified checkpoint(s). | ||
94 | |||
95 | To mount a snapshot, | ||
96 | |||
97 | # mount -t nilfs2 -r -o cp=<cno> /dev/block_device /snap_dir | ||
98 | |||
99 | where <cno> is the checkpoint number of the snapshot. | ||
100 | |||
101 | To unmount the NILFS2 mount point or snapshot, simply: | ||
102 | |||
103 | # umount /dir | ||
104 | |||
105 | Then, the cleaner daemon is automatically shut down by the umount | ||
106 | helper program (umount.nilfs2). | ||
107 | |||
108 | Disk format | ||
109 | =========== | ||
110 | |||
111 | A nilfs2 volume is equally divided into a number of segments except | ||
112 | for the super block (SB) and segment #0. A segment is the container | ||
113 | of logs. Each log is composed of summary information blocks, payload | ||
114 | blocks, and an optional super root block (SR): | ||
115 | |||
116 | ______________________________________________________ | ||
117 | | |SB| | Segment | Segment | Segment | ... | Segment | | | ||
118 | |_|__|_|____0____|____1____|____2____|_____|____N____|_| | ||
119 | 0 +1K +4K +8M +16M +24M +(8MB x N) | ||
120 | . . (Typical offsets for 4KB-block) | ||
121 | . . | ||
122 | .______________________. | ||
123 | | log | log |... | log | | ||
124 | |__1__|__2__|____|__m__| | ||
125 | . . | ||
126 | . . | ||
127 | . . | ||
128 | .______________________________. | ||
129 | | Summary | Payload blocks |SR| | ||
130 | |_blocks__|_________________|__| | ||
131 | |||
132 | The payload blocks are organized per file, and each file consists of | ||
133 | data blocks and B-tree node blocks: | ||
134 | |||
135 | |<--- File-A --->|<--- File-B --->| | ||
136 | _______________________________________________________________ | ||
137 | | Data blocks | B-tree blocks | Data blocks | B-tree blocks | ... | ||
138 | _|_____________|_______________|_____________|_______________|_ | ||
139 | |||
140 | |||
141 | Since only the modified blocks are written in the log, it may have | ||
142 | files without data blocks or B-tree node blocks. | ||
143 | |||
144 | The organization of the blocks is recorded in the summary information | ||
145 | blocks, which contains a header structure (nilfs_segment_summary), per | ||
146 | file structures (nilfs_finfo), and per block structures (nilfs_binfo): | ||
147 | |||
148 | _________________________________________________________________________ | ||
149 | | Summary | finfo | binfo | ... | binfo | finfo | binfo | ... | binfo |... | ||
150 | |_blocks__|___A___|_(A,1)_|_____|(A,Na)_|___B___|_(B,1)_|_____|(B,Nb)_|___ | ||
151 | |||
152 | |||
153 | The logs include regular files, directory files, symbolic link files | ||
154 | and several meta data files. The mata data files are the files used | ||
155 | to maintain file system meta data. The current version of NILFS2 uses | ||
156 | the following meta data files: | ||
157 | |||
158 | 1) Inode file (ifile) -- Stores on-disk inodes | ||
159 | 2) Checkpoint file (cpfile) -- Stores checkpoints | ||
160 | 3) Segment usage file (sufile) -- Stores allocation state of segments | ||
161 | 4) Data address translation file -- Maps virtual block numbers to usual | ||
162 | (DAT) block numbers. This file serves to | ||
163 | make on-disk blocks relocatable. | ||
164 | |||
165 | The following figure shows a typical organization of the logs: | ||
166 | |||
167 | _________________________________________________________________________ | ||
168 | | Summary | regular file | file | ... | ifile | cpfile | sufile | DAT |SR| | ||
169 | |_blocks__|_or_directory_|_______|_____|_______|________|________|_____|__| | ||
170 | |||
171 | |||
172 | To stride over segment boundaries, this sequence of files may be split | ||
173 | into multiple logs. The sequence of logs that should be treated as | ||
174 | logically one log, is delimited with flags marked in the segment | ||
175 | summary. The recovery code of nilfs2 looks this boundary information | ||
176 | to ensure atomicity of updates. | ||
177 | |||
178 | The super root block is inserted for every checkpoints. It includes | ||
179 | three special inodes, inodes for the DAT, cpfile, and sufile. Inodes | ||
180 | of regular files, directories, symlinks and other special files, are | ||
181 | included in the ifile. The inode of ifile itself is included in the | ||
182 | corresponding checkpoint entry in the cpfile. Thus, the hierarchy | ||
183 | among NILFS2 files can be depicted as follows: | ||
184 | |||
185 | Super block (SB) | ||
186 | | | ||
187 | v | ||
188 | Super root block (the latest cno=xx) | ||
189 | |-- DAT | ||
190 | |-- sufile | ||
191 | `-- cpfile | ||
192 | |-- ifile (cno=c1) | ||
193 | |-- ifile (cno=c2) ---- file (ino=i1) | ||
194 | : : |-- file (ino=i2) | ||
195 | `-- ifile (cno=xx) |-- file (ino=i3) | ||
196 | : : | ||
197 | `-- file (ino=yy) | ||
198 | ( regular file, directory, or symlink ) | ||
199 | |||
200 | For detail on the format of each file, please see include/linux/nilfs2_fs.h. | ||
diff --git a/Documentation/filesystems/pohmelfs/design_notes.txt b/Documentation/filesystems/pohmelfs/design_notes.txt new file mode 100644 index 000000000000..6d6db60d567d --- /dev/null +++ b/Documentation/filesystems/pohmelfs/design_notes.txt | |||
@@ -0,0 +1,70 @@ | |||
1 | POHMELFS: Parallel Optimized Host Message Exchange Layered File System. | ||
2 | |||
3 | Evgeniy Polyakov <zbr@ioremap.net> | ||
4 | |||
5 | Homepage: http://www.ioremap.net/projects/pohmelfs | ||
6 | |||
7 | POHMELFS first began as a network filesystem with coherent local data and | ||
8 | metadata caches but is now evolving into a parallel distributed filesystem. | ||
9 | |||
10 | Main features of this FS include: | ||
11 | * Locally coherent cache for data and metadata with (potentially) byte-range locks. | ||
12 | Since all Linux filesystems lock the whole inode during writing, algorithm | ||
13 | is very simple and does not use byte-ranges, although they are sent in | ||
14 | locking messages. | ||
15 | * Completely async processing of all events except creation of hard and symbolic | ||
16 | links, and rename events. | ||
17 | Object creation and data reading and writing are processed asynchronously. | ||
18 | * Flexible object architecture optimized for network processing. | ||
19 | Ability to create long paths to objects and remove arbitrarily huge | ||
20 | directories with a single network command. | ||
21 | (like removing the whole kernel tree via a single network command). | ||
22 | * Very high performance. | ||
23 | * Fast and scalable multithreaded userspace server. Being in userspace it works | ||
24 | with any underlying filesystem and still is much faster than async in-kernel NFS one. | ||
25 | * Client is able to switch between different servers (if one goes down, client | ||
26 | automatically reconnects to second and so on). | ||
27 | * Transactions support. Full failover for all operations. | ||
28 | Resending transactions to different servers on timeout or error. | ||
29 | * Read request (data read, directory listing, lookup requests) balancing between multiple servers. | ||
30 | * Write requests are replicated to multiple servers and completed only when all of them are acked. | ||
31 | * Ability to add and/or remove servers from the working set at run-time. | ||
32 | * Strong authentification and possible data encryption in network channel. | ||
33 | * Extended attributes support. | ||
34 | |||
35 | POHMELFS is based on transactions, which are potentially long-standing objects that live | ||
36 | in the client's memory. Each transaction contains all the information needed to process a given | ||
37 | command (or set of commands, which is frequently used during data writing: single transactions | ||
38 | can contain creation and data writing commands). Transactions are committed by all the servers | ||
39 | to which they are sent and, in case of failures, are eventually resent or dropped with an error. | ||
40 | For example, reading will return an error if no servers are available. | ||
41 | |||
42 | POHMELFS uses a asynchronous approach to data processing. Courtesy of transactions, it is | ||
43 | possible to detach replies from requests and, if the command requires data to be received, the | ||
44 | caller sleeps waiting for it. Thus, it is possible to issue multiple read commands to different | ||
45 | servers and async threads will pick up replies in parallel, find appropriate transactions in the | ||
46 | system and put the data where it belongs (like the page or inode cache). | ||
47 | |||
48 | The main feature of POHMELFS is writeback data and the metadata cache. | ||
49 | Only a few non-performance critical operations use the write-through cache and | ||
50 | are synchronous: hard and symbolic link creation, and object rename. Creation, | ||
51 | removal of objects and data writing are asynchronous and are sent to | ||
52 | the server during system writeback. Only one writer at a time is allowed for any | ||
53 | given inode, which is guarded by an appropriate locking protocol. | ||
54 | Because of this feature, POHMELFS is extremely fast at metadata intensive | ||
55 | workloads and can fully utilize the bandwidth to the servers when doing bulk | ||
56 | data transfers. | ||
57 | |||
58 | POHMELFS clients operate with a working set of servers and are capable of balancing read-only | ||
59 | operations (like lookups or directory listings) between them. | ||
60 | Administrators can add or remove servers from the set at run-time via special commands (described | ||
61 | in Documentation/pohmelfs/info.txt file). Writes are replicated to all servers. | ||
62 | |||
63 | POHMELFS is capable of full data channel encryption and/or strong crypto hashing. | ||
64 | One can select any kernel supported cipher, encryption mode, hash type and operation mode | ||
65 | (hmac or digest). It is also possible to use both or neither (default). Crypto configuration | ||
66 | is checked during mount time and, if the server does not support it, appropriate capabilities | ||
67 | will be disabled or mount will fail (if 'crypto_fail_unsupported' mount option is specified). | ||
68 | Crypto performance heavily depends on the number of crypto threads, which asynchronously perform | ||
69 | crypto operations and send the resulting data to server or submit it up the stack. This number | ||
70 | can be controlled via a mount option. | ||
diff --git a/Documentation/filesystems/pohmelfs/info.txt b/Documentation/filesystems/pohmelfs/info.txt new file mode 100644 index 000000000000..4e3d50157083 --- /dev/null +++ b/Documentation/filesystems/pohmelfs/info.txt | |||
@@ -0,0 +1,86 @@ | |||
1 | POHMELFS usage information. | ||
2 | |||
3 | Mount options: | ||
4 | idx=%u | ||
5 | Each mountpoint is associated with a special index via this option. | ||
6 | Administrator can add or remove servers from the given index, so all mounts, | ||
7 | which were attached to it, are updated. | ||
8 | Default it is 0. | ||
9 | |||
10 | trans_scan_timeout=%u | ||
11 | This timeout, expressed in milliseconds, specifies time to scan transaction | ||
12 | trees looking for stale requests, which have to be resent, or if number of | ||
13 | retries exceed specified limit, dropped with error. | ||
14 | Default is 5 seconds. | ||
15 | |||
16 | drop_scan_timeout=%u | ||
17 | Internal timeout, expressed in milliseconds, which specifies how frequently | ||
18 | inodes marked to be dropped are freed. It also specifies how frequently | ||
19 | the system checks that servers have to be added or removed from current working set. | ||
20 | Default is 1 second. | ||
21 | |||
22 | wait_on_page_timeout=%u | ||
23 | Number of milliseconds to wait for reply from remote server for data reading command. | ||
24 | If this timeout is exceeded, reading returns an error. | ||
25 | Default is 5 seconds. | ||
26 | |||
27 | trans_retries=%u | ||
28 | This is the number of times that a transaction will be resent to a server that did | ||
29 | not answer for the last @trans_scan_timeout milliseconds. | ||
30 | When the number of resends exceeds this limit, the transaction is completed with error. | ||
31 | Default is 5 resends. | ||
32 | |||
33 | crypto_thread_num=%u | ||
34 | Number of crypto processing threads. Threads are used both for RX and TX traffic. | ||
35 | Default is 2, or no threads if crypto operations are not supported. | ||
36 | |||
37 | trans_max_pages=%u | ||
38 | Maximum number of pages in a single transaction. This parameter also controls | ||
39 | the number of pages, allocated for crypto processing (each crypto thread has | ||
40 | pool of pages, the number of which is equal to 'trans_max_pages'. | ||
41 | Default is 100 pages. | ||
42 | |||
43 | crypto_fail_unsupported | ||
44 | If specified, mount will fail if the server does not support requested crypto operations. | ||
45 | By default mount will disable non-matching crypto operations. | ||
46 | |||
47 | mcache_timeout=%u | ||
48 | Maximum number of milliseconds to wait for the mcache objects to be processed. | ||
49 | Mcache includes locks (given lock should be granted by server), attributes (they should be | ||
50 | fully received in the given timeframe). | ||
51 | Default is 5 seconds. | ||
52 | |||
53 | Usage examples. | ||
54 | |||
55 | Add (or remove if it already exists) server server1.net:1025 into the working set with index $idx | ||
56 | with appropriate hash algorithm and key file and cipher algorithm, mode and key file: | ||
57 | $cfg -a server1.net -p 1025 -i $idx -K $hash_key -k $cipher_key | ||
58 | |||
59 | Mount filesystem with given index $idx to /mnt mountpoint. | ||
60 | Client will connect to all servers specified in the working set via previous command: | ||
61 | mount -t pohmel -o idx=$idx q /mnt | ||
62 | |||
63 | One can add or remove servers from working set after mounting too. | ||
64 | |||
65 | |||
66 | Server installation. | ||
67 | |||
68 | Creating a server, which listens at port 1025 and 0.0.0.0 address. | ||
69 | Working root directory (note, that server chroots there, so you have to have appropriate permissions) | ||
70 | is set to /mnt, server will negotiate hash/cipher with client, in case client requested it, there | ||
71 | are appropriate key files. | ||
72 | Number of working threads is set to 10. | ||
73 | |||
74 | # ./fserver -a 0.0.0.0 -p 1025 -r /mnt -w 10 -K hash_key -k cipher_key | ||
75 | |||
76 | -A 6 - listen on ipv6 address. Default: Disabled. | ||
77 | -r root - path to root directory. Default: /tmp. | ||
78 | -a addr - listen address. Default: 0.0.0.0. | ||
79 | -p port - listen port. Default: 1025. | ||
80 | -w workers - number of workers per connected client. Default: 1. | ||
81 | -K file - hash key size. Default: none. | ||
82 | -k file - cipher key size. Default: none. | ||
83 | -h - this help. | ||
84 | |||
85 | Number of worker threads specifies how many workers will be created for each client. | ||
86 | Bulk single-client transafers usually are better handled with smaller number (like 1-3). | ||
diff --git a/Documentation/filesystems/pohmelfs/network_protocol.txt b/Documentation/filesystems/pohmelfs/network_protocol.txt new file mode 100644 index 000000000000..40ea6c295afb --- /dev/null +++ b/Documentation/filesystems/pohmelfs/network_protocol.txt | |||
@@ -0,0 +1,227 @@ | |||
1 | POHMELFS network protocol. | ||
2 | |||
3 | Basic structure used in network communication is following command: | ||
4 | |||
5 | struct netfs_cmd | ||
6 | { | ||
7 | __u16 cmd; /* Command number */ | ||
8 | __u16 csize; /* Attached crypto information size */ | ||
9 | __u16 cpad; /* Attached padding size */ | ||
10 | __u16 ext; /* External flags */ | ||
11 | __u32 size; /* Size of the attached data */ | ||
12 | __u32 trans; /* Transaction id */ | ||
13 | __u64 id; /* Object ID to operate on. Used for feedback.*/ | ||
14 | __u64 start; /* Start of the object. */ | ||
15 | __u64 iv; /* IV sequence */ | ||
16 | __u8 data[0]; | ||
17 | }; | ||
18 | |||
19 | Commands can be embedded into transaction command (which in turn has own command), | ||
20 | so one can extend protocol as needed without breaking backward compatibility as long | ||
21 | as old commands are supported. All string lengths include tail 0 byte. | ||
22 | |||
23 | All commans are transfered over the network in big-endian. CPU endianess is used at the end peers. | ||
24 | |||
25 | @cmd - command number, which specifies command to be processed. Following | ||
26 | commands are used currently: | ||
27 | |||
28 | NETFS_READDIR = 1, /* Read directory for given inode number */ | ||
29 | NETFS_READ_PAGE, /* Read data page from the server */ | ||
30 | NETFS_WRITE_PAGE, /* Write data page to the server */ | ||
31 | NETFS_CREATE, /* Create directory entry */ | ||
32 | NETFS_REMOVE, /* Remove directory entry */ | ||
33 | NETFS_LOOKUP, /* Lookup single object */ | ||
34 | NETFS_LINK, /* Create a link */ | ||
35 | NETFS_TRANS, /* Transaction */ | ||
36 | NETFS_OPEN, /* Open intent */ | ||
37 | NETFS_INODE_INFO, /* Metadata cache coherency synchronization message */ | ||
38 | NETFS_PAGE_CACHE, /* Page cache invalidation message */ | ||
39 | NETFS_READ_PAGES, /* Read multiple contiguous pages in one go */ | ||
40 | NETFS_RENAME, /* Rename object */ | ||
41 | NETFS_CAPABILITIES, /* Capabilities of the client, for example supported crypto */ | ||
42 | NETFS_LOCK, /* Distributed lock message */ | ||
43 | NETFS_XATTR_SET, /* Set extended attribute */ | ||
44 | NETFS_XATTR_GET, /* Get extended attribute */ | ||
45 | |||
46 | @ext - external flags. Used by different commands to specify some extra arguments | ||
47 | like partial size of the embedded objects or creation flags. | ||
48 | |||
49 | @size - size of the attached data. For NETFS_READ_PAGE and NETFS_READ_PAGES no data is attached, | ||
50 | but size of the requested data is incorporated here. It does not include size of the command | ||
51 | header (struct netfs_cmd) itself. | ||
52 | |||
53 | @id - id of the object this command operates on. Each command can use it for own purpose. | ||
54 | |||
55 | @start - start of the object this command operates on. Each command can use it for own purpose. | ||
56 | |||
57 | @csize, @cpad - size and padding size of the (attached if needed) crypto information. | ||
58 | |||
59 | Command specifications. | ||
60 | |||
61 | @NETFS_READDIR | ||
62 | This command is used to sync content of the remote dir to the client. | ||
63 | |||
64 | @ext - length of the path to object. | ||
65 | @size - the same. | ||
66 | @id - local inode number of the directory to read. | ||
67 | @start - zero. | ||
68 | |||
69 | |||
70 | @NETFS_READ_PAGE | ||
71 | This command is used to read data from remote server. | ||
72 | Data size does not exceed local page cache size. | ||
73 | |||
74 | @id - inode number. | ||
75 | @start - first byte offset. | ||
76 | @size - number of bytes to read plus length of the path to object. | ||
77 | @ext - object path length. | ||
78 | |||
79 | |||
80 | @NETFS_CREATE | ||
81 | Used to create object. | ||
82 | It does not require that all directories on top of the object were | ||
83 | already created, it will create them automatically. Each object has | ||
84 | associated @netfs_path_entry data structure, which contains creation | ||
85 | mode (permissions and type) and length of the name as long as name itself. | ||
86 | |||
87 | @start - 0 | ||
88 | @size - size of the all data structures needed to create a path | ||
89 | @id - local inode number | ||
90 | @ext - 0 | ||
91 | |||
92 | |||
93 | @NETFS_REMOVE | ||
94 | Used to remove object. | ||
95 | |||
96 | @ext - length of the path to object. | ||
97 | @size - the same. | ||
98 | @id - local inode number. | ||
99 | @start - zero. | ||
100 | |||
101 | |||
102 | @NETFS_LOOKUP | ||
103 | Lookup information about object on server. | ||
104 | |||
105 | @ext - length of the path to object. | ||
106 | @size - the same. | ||
107 | @id - local inode number of the directory to look object in. | ||
108 | @start - local inode number of the object to look at. | ||
109 | |||
110 | |||
111 | @NETFS_LINK | ||
112 | Create hard of symlink. | ||
113 | Command is sent as "object_path|target_path". | ||
114 | |||
115 | @size - size of the above string. | ||
116 | @id - parent local inode number. | ||
117 | @start - 1 for symlink, 0 for hardlink. | ||
118 | @ext - size of the "object_path" above. | ||
119 | |||
120 | |||
121 | @NETFS_TRANS | ||
122 | Transaction header. | ||
123 | |||
124 | @size - incorporates all embedded command sizes including theirs header sizes. | ||
125 | @start - transaction generation number - unique id used to find transaction. | ||
126 | @ext - transaction flags. Unused at the moment. | ||
127 | @id - 0. | ||
128 | |||
129 | |||
130 | @NETFS_OPEN | ||
131 | Open intent for given transaction. | ||
132 | |||
133 | @id - local inode number. | ||
134 | @start - 0. | ||
135 | @size - path length to the object. | ||
136 | @ext - open flags (O_RDWR and so on). | ||
137 | |||
138 | |||
139 | @NETFS_INODE_INFO | ||
140 | Metadata update command. | ||
141 | It is sent to servers when attributes of the object are changed and received | ||
142 | when data or metadata were updated. It operates with the following structure: | ||
143 | |||
144 | struct netfs_inode_info | ||
145 | { | ||
146 | unsigned int mode; | ||
147 | unsigned int nlink; | ||
148 | unsigned int uid; | ||
149 | unsigned int gid; | ||
150 | unsigned int blocksize; | ||
151 | unsigned int padding; | ||
152 | __u64 ino; | ||
153 | __u64 blocks; | ||
154 | __u64 rdev; | ||
155 | __u64 size; | ||
156 | __u64 version; | ||
157 | }; | ||
158 | |||
159 | It effectively mirrors stat(2) returned data. | ||
160 | |||
161 | |||
162 | @ext - path length to the object. | ||
163 | @size - the same plus size of the netfs_inode_info structure. | ||
164 | @id - local inode number. | ||
165 | @start - 0. | ||
166 | |||
167 | |||
168 | @NETFS_PAGE_CACHE | ||
169 | Command is only received by clients. It contains information about | ||
170 | page to be marked as not up-to-date. | ||
171 | |||
172 | @id - client's inode number. | ||
173 | @start - last byte of the page to be invalidated. If it is not equal to | ||
174 | current inode size, it will be vmtruncated(). | ||
175 | @size - 0 | ||
176 | @ext - 0 | ||
177 | |||
178 | |||
179 | @NETFS_READ_PAGES | ||
180 | Used to read multiple contiguous pages in one go. | ||
181 | |||
182 | @start - first byte of the contiguous region to read. | ||
183 | @size - contains of two fields: lower 8 bits are used to represent page cache shift | ||
184 | used by client, another 3 bytes are used to get number of pages. | ||
185 | @id - local inode number. | ||
186 | @ext - path length to the object. | ||
187 | |||
188 | |||
189 | @NETFS_RENAME | ||
190 | Used to rename object. | ||
191 | Attached data is formed into following string: "old_path|new_path". | ||
192 | |||
193 | @id - local inode number. | ||
194 | @start - parent inode number. | ||
195 | @size - length of the above string. | ||
196 | @ext - length of the old path part. | ||
197 | |||
198 | |||
199 | @NETFS_CAPABILITIES | ||
200 | Used to exchange crypto capabilities with server. | ||
201 | If crypto capabilities are not supported by server, then client will disable it | ||
202 | or fail (if 'crypto_fail_unsupported' mount options was specified). | ||
203 | |||
204 | @id - superblock index. Used to specify crypto information for group of servers. | ||
205 | @size - size of the attached capabilities structure. | ||
206 | @start - 0. | ||
207 | @size - 0. | ||
208 | @scsize - 0. | ||
209 | |||
210 | @NETFS_LOCK | ||
211 | Used to send lock request/release messages. Although it sends byte range request | ||
212 | and is capable of flushing pages based on that, it is not used, since all Linux | ||
213 | filesystems lock the whole inode. | ||
214 | |||
215 | @id - lock generation number. | ||
216 | @start - start of the locked range. | ||
217 | @size - size of the locked range. | ||
218 | @ext - lock type: read/write. Not used actually. 15'th bit is used to determine, | ||
219 | if it is lock request (1) or release (0). | ||
220 | |||
221 | @NETFS_XATTR_SET | ||
222 | @NETFS_XATTR_GET | ||
223 | Used to set/get extended attributes for given inode. | ||
224 | @id - attribute generation number or xattr setting type | ||
225 | @start - size of the attribute (request or attached) | ||
226 | @size - name length, path len and data size for given attribute | ||
227 | @ext - path length for given object | ||
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index a87be42f8211..ce84cfc9eae0 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt | |||
@@ -5,6 +5,7 @@ | |||
5 | Bodo Bauer <bb@ricochet.net> | 5 | Bodo Bauer <bb@ricochet.net> |
6 | 6 | ||
7 | 2.4.x update Jorge Nerin <comandante@zaralinux.com> November 14 2000 | 7 | 2.4.x update Jorge Nerin <comandante@zaralinux.com> November 14 2000 |
8 | move /proc/sys Shen Feng <shen@cn.fujitsu.com> April 1 2009 | ||
8 | ------------------------------------------------------------------------------ | 9 | ------------------------------------------------------------------------------ |
9 | Version 1.3 Kernel version 2.2.12 | 10 | Version 1.3 Kernel version 2.2.12 |
10 | Kernel version 2.4.0-test11-pre4 | 11 | Kernel version 2.4.0-test11-pre4 |
@@ -26,25 +27,17 @@ Table of Contents | |||
26 | 1.6 Parallel port info in /proc/parport | 27 | 1.6 Parallel port info in /proc/parport |
27 | 1.7 TTY info in /proc/tty | 28 | 1.7 TTY info in /proc/tty |
28 | 1.8 Miscellaneous kernel statistics in /proc/stat | 29 | 1.8 Miscellaneous kernel statistics in /proc/stat |
30 | 1.9 Ext4 file system parameters | ||
29 | 31 | ||
30 | 2 Modifying System Parameters | 32 | 2 Modifying System Parameters |
31 | 2.1 /proc/sys/fs - File system data | 33 | |
32 | 2.2 /proc/sys/fs/binfmt_misc - Miscellaneous binary formats | 34 | 3 Per-Process Parameters |
33 | 2.3 /proc/sys/kernel - general kernel parameters | 35 | 3.1 /proc/<pid>/oom_adj - Adjust the oom-killer score |
34 | 2.4 /proc/sys/vm - The virtual memory subsystem | 36 | 3.2 /proc/<pid>/oom_score - Display current oom-killer score |
35 | 2.5 /proc/sys/dev - Device specific parameters | 37 | 3.3 /proc/<pid>/io - Display the IO accounting fields |
36 | 2.6 /proc/sys/sunrpc - Remote procedure calls | 38 | 3.4 /proc/<pid>/coredump_filter - Core dump filtering settings |
37 | 2.7 /proc/sys/net - Networking stuff | 39 | 3.5 /proc/<pid>/mountinfo - Information about mounts |
38 | 2.8 /proc/sys/net/ipv4 - IPV4 settings | 40 | |
39 | 2.9 Appletalk | ||
40 | 2.10 IPX | ||
41 | 2.11 /proc/sys/fs/mqueue - POSIX message queues filesystem | ||
42 | 2.12 /proc/<pid>/oom_adj - Adjust the oom-killer score | ||
43 | 2.13 /proc/<pid>/oom_score - Display current oom-killer score | ||
44 | 2.14 /proc/<pid>/io - Display the IO accounting fields | ||
45 | 2.15 /proc/<pid>/coredump_filter - Core dump filtering settings | ||
46 | 2.16 /proc/<pid>/mountinfo - Information about mounts | ||
47 | 2.17 /proc/sys/fs/epoll - Configuration options for the epoll interface | ||
48 | 41 | ||
49 | ------------------------------------------------------------------------------ | 42 | ------------------------------------------------------------------------------ |
50 | Preface | 43 | Preface |
@@ -940,27 +933,6 @@ Table 1-10: Files in /proc/fs/ext4/<devname> | |||
940 | File Content | 933 | File Content |
941 | mb_groups details of multiblock allocator buddy cache of free blocks | 934 | mb_groups details of multiblock allocator buddy cache of free blocks |
942 | mb_history multiblock allocation history | 935 | mb_history multiblock allocation history |
943 | stats controls whether the multiblock allocator should start | ||
944 | collecting statistics, which are shown during the unmount | ||
945 | group_prealloc the multiblock allocator will round up allocation | ||
946 | requests to a multiple of this tuning parameter if the | ||
947 | stripe size is not set in the ext4 superblock | ||
948 | max_to_scan The maximum number of extents the multiblock allocator | ||
949 | will search to find the best extent | ||
950 | min_to_scan The minimum number of extents the multiblock allocator | ||
951 | will search to find the best extent | ||
952 | order2_req Tuning parameter which controls the minimum size for | ||
953 | requests (as a power of 2) where the buddy cache is | ||
954 | used | ||
955 | stream_req Files which have fewer blocks than this tunable | ||
956 | parameter will have their blocks allocated out of a | ||
957 | block group specific preallocation pool, so that small | ||
958 | files are packed closely together. Each large file | ||
959 | will have its blocks allocated out of its own unique | ||
960 | preallocation pool. | ||
961 | inode_readahead Tuning parameter which controls the maximum number of | ||
962 | inode table blocks that ext4's inode table readahead | ||
963 | algorithm will pre-read into the buffer cache | ||
964 | .............................................................................. | 936 | .............................................................................. |
965 | 937 | ||
966 | 938 | ||
@@ -1011,1014 +983,24 @@ review the kernel documentation in the directory /usr/src/linux/Documentation. | |||
1011 | This chapter is heavily based on the documentation included in the pre 2.2 | 983 | This chapter is heavily based on the documentation included in the pre 2.2 |
1012 | kernels, and became part of it in version 2.2.1 of the Linux kernel. | 984 | kernels, and became part of it in version 2.2.1 of the Linux kernel. |
1013 | 985 | ||
1014 | 2.1 /proc/sys/fs - File system data | 986 | Please see: Documentation/sysctls/ directory for descriptions of these |
1015 | ----------------------------------- | ||
1016 | |||
1017 | This subdirectory contains specific file system, file handle, inode, dentry | ||
1018 | and quota information. | ||
1019 | |||
1020 | Currently, these files are in /proc/sys/fs: | ||
1021 | |||
1022 | dentry-state | ||
1023 | ------------ | ||
1024 | |||
1025 | Status of the directory cache. Since directory entries are dynamically | ||
1026 | allocated and deallocated, this file indicates the current status. It holds | ||
1027 | six values, in which the last two are not used and are always zero. The others | ||
1028 | are listed in table 2-1. | ||
1029 | |||
1030 | |||
1031 | Table 2-1: Status files of the directory cache | ||
1032 | .............................................................................. | ||
1033 | File Content | ||
1034 | nr_dentry Almost always zero | ||
1035 | nr_unused Number of unused cache entries | ||
1036 | age_limit | ||
1037 | in seconds after the entry may be reclaimed, when memory is short | ||
1038 | want_pages internally | ||
1039 | .............................................................................. | ||
1040 | |||
1041 | dquot-nr and dquot-max | ||
1042 | ---------------------- | ||
1043 | |||
1044 | The file dquot-max shows the maximum number of cached disk quota entries. | ||
1045 | |||
1046 | The file dquot-nr shows the number of allocated disk quota entries and the | ||
1047 | number of free disk quota entries. | ||
1048 | |||
1049 | If the number of available cached disk quotas is very low and you have a large | ||
1050 | number of simultaneous system users, you might want to raise the limit. | ||
1051 | |||
1052 | file-nr and file-max | ||
1053 | -------------------- | ||
1054 | |||
1055 | The kernel allocates file handles dynamically, but doesn't free them again at | ||
1056 | this time. | ||
1057 | |||
1058 | The value in file-max denotes the maximum number of file handles that the | ||
1059 | Linux kernel will allocate. When you get a lot of error messages about running | ||
1060 | out of file handles, you might want to raise this limit. The default value is | ||
1061 | 10% of RAM in kilobytes. To change it, just write the new number into the | ||
1062 | file: | ||
1063 | |||
1064 | # cat /proc/sys/fs/file-max | ||
1065 | 4096 | ||
1066 | # echo 8192 > /proc/sys/fs/file-max | ||
1067 | # cat /proc/sys/fs/file-max | ||
1068 | 8192 | ||
1069 | |||
1070 | |||
1071 | This method of revision is useful for all customizable parameters of the | ||
1072 | kernel - simply echo the new value to the corresponding file. | ||
1073 | |||
1074 | Historically, the three values in file-nr denoted the number of allocated file | ||
1075 | handles, the number of allocated but unused file handles, and the maximum | ||
1076 | number of file handles. Linux 2.6 always reports 0 as the number of free file | ||
1077 | handles -- this is not an error, it just means that the number of allocated | ||
1078 | file handles exactly matches the number of used file handles. | ||
1079 | |||
1080 | Attempts to allocate more file descriptors than file-max are reported with | ||
1081 | printk, look for "VFS: file-max limit <number> reached". | ||
1082 | |||
1083 | inode-state and inode-nr | ||
1084 | ------------------------ | ||
1085 | |||
1086 | The file inode-nr contains the first two items from inode-state, so we'll skip | ||
1087 | to that file... | ||
1088 | |||
1089 | inode-state contains two actual numbers and five dummy values. The numbers | ||
1090 | are nr_inodes and nr_free_inodes (in order of appearance). | ||
1091 | |||
1092 | nr_inodes | ||
1093 | ~~~~~~~~~ | ||
1094 | |||
1095 | Denotes the number of inodes the system has allocated. This number will | ||
1096 | grow and shrink dynamically. | ||
1097 | |||
1098 | nr_open | ||
1099 | ------- | ||
1100 | |||
1101 | Denotes the maximum number of file-handles a process can | ||
1102 | allocate. Default value is 1024*1024 (1048576) which should be | ||
1103 | enough for most machines. Actual limit depends on RLIMIT_NOFILE | ||
1104 | resource limit. | ||
1105 | |||
1106 | nr_free_inodes | ||
1107 | -------------- | ||
1108 | |||
1109 | Represents the number of free inodes. Ie. The number of inuse inodes is | ||
1110 | (nr_inodes - nr_free_inodes). | ||
1111 | |||
1112 | aio-nr and aio-max-nr | ||
1113 | --------------------- | ||
1114 | |||
1115 | aio-nr is the running total of the number of events specified on the | ||
1116 | io_setup system call for all currently active aio contexts. If aio-nr | ||
1117 | reaches aio-max-nr then io_setup will fail with EAGAIN. Note that | ||
1118 | raising aio-max-nr does not result in the pre-allocation or re-sizing | ||
1119 | of any kernel data structures. | ||
1120 | |||
1121 | 2.2 /proc/sys/fs/binfmt_misc - Miscellaneous binary formats | ||
1122 | ----------------------------------------------------------- | ||
1123 | |||
1124 | Besides these files, there is the subdirectory /proc/sys/fs/binfmt_misc. This | ||
1125 | handles the kernel support for miscellaneous binary formats. | ||
1126 | |||
1127 | Binfmt_misc provides the ability to register additional binary formats to the | ||
1128 | Kernel without compiling an additional module/kernel. Therefore, binfmt_misc | ||
1129 | needs to know magic numbers at the beginning or the filename extension of the | ||
1130 | binary. | ||
1131 | |||
1132 | It works by maintaining a linked list of structs that contain a description of | ||
1133 | a binary format, including a magic with size (or the filename extension), | ||
1134 | offset and mask, and the interpreter name. On request it invokes the given | ||
1135 | interpreter with the original program as argument, as binfmt_java and | ||
1136 | binfmt_em86 and binfmt_mz do. Since binfmt_misc does not define any default | ||
1137 | binary-formats, you have to register an additional binary-format. | ||
1138 | |||
1139 | There are two general files in binfmt_misc and one file per registered format. | ||
1140 | The two general files are register and status. | ||
1141 | |||
1142 | Registering a new binary format | ||
1143 | ------------------------------- | ||
1144 | |||
1145 | To register a new binary format you have to issue the command | ||
1146 | |||
1147 | echo :name:type:offset:magic:mask:interpreter: > /proc/sys/fs/binfmt_misc/register | ||
1148 | |||
1149 | |||
1150 | |||
1151 | with appropriate name (the name for the /proc-dir entry), offset (defaults to | ||
1152 | 0, if omitted), magic, mask (which can be omitted, defaults to all 0xff) and | ||
1153 | last but not least, the interpreter that is to be invoked (for example and | ||
1154 | testing /bin/echo). Type can be M for usual magic matching or E for filename | ||
1155 | extension matching (give extension in place of magic). | ||
1156 | |||
1157 | Check or reset the status of the binary format handler | ||
1158 | ------------------------------------------------------ | ||
1159 | |||
1160 | If you do a cat on the file /proc/sys/fs/binfmt_misc/status, you will get the | ||
1161 | current status (enabled/disabled) of binfmt_misc. Change the status by echoing | ||
1162 | 0 (disables) or 1 (enables) or -1 (caution: this clears all previously | ||
1163 | registered binary formats) to status. For example echo 0 > status to disable | ||
1164 | binfmt_misc (temporarily). | ||
1165 | |||
1166 | Status of a single handler | ||
1167 | -------------------------- | ||
1168 | |||
1169 | Each registered handler has an entry in /proc/sys/fs/binfmt_misc. These files | ||
1170 | perform the same function as status, but their scope is limited to the actual | ||
1171 | binary format. By cating this file, you also receive all related information | ||
1172 | about the interpreter/magic of the binfmt. | ||
1173 | |||
1174 | Example usage of binfmt_misc (emulate binfmt_java) | ||
1175 | -------------------------------------------------- | ||
1176 | |||
1177 | cd /proc/sys/fs/binfmt_misc | ||
1178 | echo ':Java:M::\xca\xfe\xba\xbe::/usr/local/java/bin/javawrapper:' > register | ||
1179 | echo ':HTML:E::html::/usr/local/java/bin/appletviewer:' > register | ||
1180 | echo ':Applet:M::<!--applet::/usr/local/java/bin/appletviewer:' > register | ||
1181 | echo ':DEXE:M::\x0eDEX::/usr/bin/dosexec:' > register | ||
1182 | |||
1183 | |||
1184 | These four lines add support for Java executables and Java applets (like | ||
1185 | binfmt_java, additionally recognizing the .html extension with no need to put | ||
1186 | <!--applet> to every applet file). You have to install the JDK and the | ||
1187 | shell-script /usr/local/java/bin/javawrapper too. It works around the | ||
1188 | brokenness of the Java filename handling. To add a Java binary, just create a | ||
1189 | link to the class-file somewhere in the path. | ||
1190 | |||
1191 | 2.3 /proc/sys/kernel - general kernel parameters | ||
1192 | ------------------------------------------------ | ||
1193 | |||
1194 | This directory reflects general kernel behaviors. As I've said before, the | ||
1195 | contents depend on your configuration. Here you'll find the most important | ||
1196 | files, along with descriptions of what they mean and how to use them. | ||
1197 | |||
1198 | acct | ||
1199 | ---- | ||
1200 | |||
1201 | The file contains three values; highwater, lowwater, and frequency. | ||
1202 | |||
1203 | It exists only when BSD-style process accounting is enabled. These values | ||
1204 | control its behavior. If the free space on the file system where the log lives | ||
1205 | goes below lowwater percentage, accounting suspends. If it goes above | ||
1206 | highwater percentage, accounting resumes. Frequency determines how often you | ||
1207 | check the amount of free space (value is in seconds). Default settings are: 4, | ||
1208 | 2, and 30. That is, suspend accounting if there is less than 2 percent free; | ||
1209 | resume it if we have a value of 3 or more percent; consider information about | ||
1210 | the amount of free space valid for 30 seconds | ||
1211 | |||
1212 | ctrl-alt-del | ||
1213 | ------------ | ||
1214 | |||
1215 | When the value in this file is 0, ctrl-alt-del is trapped and sent to the init | ||
1216 | program to handle a graceful restart. However, when the value is greater that | ||
1217 | zero, Linux's reaction to this key combination will be an immediate reboot, | ||
1218 | without syncing its dirty buffers. | ||
1219 | |||
1220 | [NOTE] | ||
1221 | When a program (like dosemu) has the keyboard in raw mode, the | ||
1222 | ctrl-alt-del is intercepted by the program before it ever reaches the | ||
1223 | kernel tty layer, and it is up to the program to decide what to do with | ||
1224 | it. | ||
1225 | |||
1226 | domainname and hostname | ||
1227 | ----------------------- | ||
1228 | |||
1229 | These files can be controlled to set the NIS domainname and hostname of your | ||
1230 | box. For the classic darkstar.frop.org a simple: | ||
1231 | |||
1232 | # echo "darkstar" > /proc/sys/kernel/hostname | ||
1233 | # echo "frop.org" > /proc/sys/kernel/domainname | ||
1234 | |||
1235 | |||
1236 | would suffice to set your hostname and NIS domainname. | ||
1237 | |||
1238 | osrelease, ostype and version | ||
1239 | ----------------------------- | ||
1240 | |||
1241 | The names make it pretty obvious what these fields contain: | ||
1242 | |||
1243 | > cat /proc/sys/kernel/osrelease | ||
1244 | 2.2.12 | ||
1245 | |||
1246 | > cat /proc/sys/kernel/ostype | ||
1247 | Linux | ||
1248 | |||
1249 | > cat /proc/sys/kernel/version | ||
1250 | #4 Fri Oct 1 12:41:14 PDT 1999 | ||
1251 | |||
1252 | |||
1253 | The files osrelease and ostype should be clear enough. Version needs a little | ||
1254 | more clarification. The #4 means that this is the 4th kernel built from this | ||
1255 | source base and the date after it indicates the time the kernel was built. The | ||
1256 | only way to tune these values is to rebuild the kernel. | ||
1257 | |||
1258 | panic | ||
1259 | ----- | ||
1260 | |||
1261 | The value in this file represents the number of seconds the kernel waits | ||
1262 | before rebooting on a panic. When you use the software watchdog, the | ||
1263 | recommended setting is 60. If set to 0, the auto reboot after a kernel panic | ||
1264 | is disabled, which is the default setting. | ||
1265 | |||
1266 | printk | ||
1267 | ------ | ||
1268 | |||
1269 | The four values in printk denote | ||
1270 | * console_loglevel, | ||
1271 | * default_message_loglevel, | ||
1272 | * minimum_console_loglevel and | ||
1273 | * default_console_loglevel | ||
1274 | respectively. | ||
1275 | |||
1276 | These values influence printk() behavior when printing or logging error | ||
1277 | messages, which come from inside the kernel. See syslog(2) for more | ||
1278 | information on the different log levels. | ||
1279 | |||
1280 | console_loglevel | ||
1281 | ---------------- | ||
1282 | |||
1283 | Messages with a higher priority than this will be printed to the console. | ||
1284 | |||
1285 | default_message_level | ||
1286 | --------------------- | ||
1287 | |||
1288 | Messages without an explicit priority will be printed with this priority. | ||
1289 | |||
1290 | minimum_console_loglevel | ||
1291 | ------------------------ | ||
1292 | |||
1293 | Minimum (highest) value to which the console_loglevel can be set. | ||
1294 | |||
1295 | default_console_loglevel | ||
1296 | ------------------------ | ||
1297 | |||
1298 | Default value for console_loglevel. | ||
1299 | |||
1300 | sg-big-buff | ||
1301 | ----------- | ||
1302 | |||
1303 | This file shows the size of the generic SCSI (sg) buffer. At this point, you | ||
1304 | can't tune it yet, but you can change it at compile time by editing | ||
1305 | include/scsi/sg.h and changing the value of SG_BIG_BUFF. | ||
1306 | |||
1307 | If you use a scanner with SANE (Scanner Access Now Easy) you might want to set | ||
1308 | this to a higher value. Refer to the SANE documentation on this issue. | ||
1309 | |||
1310 | modprobe | ||
1311 | -------- | ||
1312 | |||
1313 | The location where the modprobe binary is located. The kernel uses this | ||
1314 | program to load modules on demand. | ||
1315 | |||
1316 | unknown_nmi_panic | ||
1317 | ----------------- | ||
1318 | |||
1319 | The value in this file affects behavior of handling NMI. When the value is | ||
1320 | non-zero, unknown NMI is trapped and then panic occurs. At that time, kernel | ||
1321 | debugging information is displayed on console. | ||
1322 | |||
1323 | NMI switch that most IA32 servers have fires unknown NMI up, for example. | ||
1324 | If a system hangs up, try pressing the NMI switch. | ||
1325 | |||
1326 | panic_on_unrecovered_nmi | ||
1327 | ------------------------ | ||
1328 | |||
1329 | The default Linux behaviour on an NMI of either memory or unknown is to continue | ||
1330 | operation. For many environments such as scientific computing it is preferable | ||
1331 | that the box is taken out and the error dealt with than an uncorrected | ||
1332 | parity/ECC error get propogated. | ||
1333 | |||
1334 | A small number of systems do generate NMI's for bizarre random reasons such as | ||
1335 | power management so the default is off. That sysctl works like the existing | ||
1336 | panic controls already in that directory. | ||
1337 | |||
1338 | nmi_watchdog | ||
1339 | ------------ | ||
1340 | |||
1341 | Enables/Disables the NMI watchdog on x86 systems. When the value is non-zero | ||
1342 | the NMI watchdog is enabled and will continuously test all online cpus to | ||
1343 | determine whether or not they are still functioning properly. Currently, | ||
1344 | passing "nmi_watchdog=" parameter at boot time is required for this function | ||
1345 | to work. | ||
1346 | |||
1347 | If LAPIC NMI watchdog method is in use (nmi_watchdog=2 kernel parameter), the | ||
1348 | NMI watchdog shares registers with oprofile. By disabling the NMI watchdog, | ||
1349 | oprofile may have more registers to utilize. | ||
1350 | |||
1351 | msgmni | ||
1352 | ------ | ||
1353 | |||
1354 | Maximum number of message queue ids on the system. | ||
1355 | This value scales to the amount of lowmem. It is automatically recomputed | ||
1356 | upon memory add/remove or ipc namespace creation/removal. | ||
1357 | When a value is written into this file, msgmni's value becomes fixed, i.e. it | ||
1358 | is not recomputed anymore when one of the above events occurs. | ||
1359 | Use auto_msgmni to change this behavior. | ||
1360 | |||
1361 | auto_msgmni | ||
1362 | ----------- | ||
1363 | |||
1364 | Enables/Disables automatic recomputing of msgmni upon memory add/remove or | ||
1365 | upon ipc namespace creation/removal (see the msgmni description above). | ||
1366 | Echoing "1" into this file enables msgmni automatic recomputing. | ||
1367 | Echoing "0" turns it off. | ||
1368 | auto_msgmni default value is 1. | ||
1369 | |||
1370 | |||
1371 | 2.4 /proc/sys/vm - The virtual memory subsystem | ||
1372 | ----------------------------------------------- | ||
1373 | |||
1374 | Please see: Documentation/sysctls/vm.txt for a description of these | ||
1375 | entries. | 987 | entries. |
1376 | 988 | ||
989 | ------------------------------------------------------------------------------ | ||
990 | Summary | ||
991 | ------------------------------------------------------------------------------ | ||
992 | Certain aspects of kernel behavior can be modified at runtime, without the | ||
993 | need to recompile the kernel, or even to reboot the system. The files in the | ||
994 | /proc/sys tree can not only be read, but also modified. You can use the echo | ||
995 | command to write value into these files, thereby changing the default settings | ||
996 | of the kernel. | ||
997 | ------------------------------------------------------------------------------ | ||
1377 | 998 | ||
1378 | 2.5 /proc/sys/dev - Device specific parameters | 999 | ------------------------------------------------------------------------------ |
1379 | ---------------------------------------------- | 1000 | CHAPTER 3: PER-PROCESS PARAMETERS |
1380 | 1001 | ------------------------------------------------------------------------------ | |
1381 | Currently there is only support for CDROM drives, and for those, there is only | ||
1382 | one read-only file containing information about the CD-ROM drives attached to | ||
1383 | the system: | ||
1384 | |||
1385 | >cat /proc/sys/dev/cdrom/info | ||
1386 | CD-ROM information, Id: cdrom.c 2.55 1999/04/25 | ||
1387 | |||
1388 | drive name: sr0 hdb | ||
1389 | drive speed: 32 40 | ||
1390 | drive # of slots: 1 0 | ||
1391 | Can close tray: 1 1 | ||
1392 | Can open tray: 1 1 | ||
1393 | Can lock tray: 1 1 | ||
1394 | Can change speed: 1 1 | ||
1395 | Can select disk: 0 1 | ||
1396 | Can read multisession: 1 1 | ||
1397 | Can read MCN: 1 1 | ||
1398 | Reports media changed: 1 1 | ||
1399 | Can play audio: 1 1 | ||
1400 | |||
1401 | |||
1402 | You see two drives, sr0 and hdb, along with a list of their features. | ||
1403 | |||
1404 | 2.6 /proc/sys/sunrpc - Remote procedure calls | ||
1405 | --------------------------------------------- | ||
1406 | |||
1407 | This directory contains four files, which enable or disable debugging for the | ||
1408 | RPC functions NFS, NFS-daemon, RPC and NLM. The default values are 0. They can | ||
1409 | be set to one to turn debugging on. (The default value is 0 for each) | ||
1410 | |||
1411 | 2.7 /proc/sys/net - Networking stuff | ||
1412 | ------------------------------------ | ||
1413 | |||
1414 | The interface to the networking parts of the kernel is located in | ||
1415 | /proc/sys/net. Table 2-3 shows all possible subdirectories. You may see only | ||
1416 | some of them, depending on your kernel's configuration. | ||
1417 | |||
1418 | |||
1419 | Table 2-3: Subdirectories in /proc/sys/net | ||
1420 | .............................................................................. | ||
1421 | Directory Content Directory Content | ||
1422 | core General parameter appletalk Appletalk protocol | ||
1423 | unix Unix domain sockets netrom NET/ROM | ||
1424 | 802 E802 protocol ax25 AX25 | ||
1425 | ethernet Ethernet protocol rose X.25 PLP layer | ||
1426 | ipv4 IP version 4 x25 X.25 protocol | ||
1427 | ipx IPX token-ring IBM token ring | ||
1428 | bridge Bridging decnet DEC net | ||
1429 | ipv6 IP version 6 | ||
1430 | .............................................................................. | ||
1431 | |||
1432 | We will concentrate on IP networking here. Since AX15, X.25, and DEC Net are | ||
1433 | only minor players in the Linux world, we'll skip them in this chapter. You'll | ||
1434 | find some short info on Appletalk and IPX further on in this chapter. Review | ||
1435 | the online documentation and the kernel source to get a detailed view of the | ||
1436 | parameters for those protocols. In this section we'll discuss the | ||
1437 | subdirectories printed in bold letters in the table above. As default values | ||
1438 | are suitable for most needs, there is no need to change these values. | ||
1439 | |||
1440 | /proc/sys/net/core - Network core options | ||
1441 | ----------------------------------------- | ||
1442 | |||
1443 | rmem_default | ||
1444 | ------------ | ||
1445 | |||
1446 | The default setting of the socket receive buffer in bytes. | ||
1447 | |||
1448 | rmem_max | ||
1449 | -------- | ||
1450 | |||
1451 | The maximum receive socket buffer size in bytes. | ||
1452 | |||
1453 | wmem_default | ||
1454 | ------------ | ||
1455 | |||
1456 | The default setting (in bytes) of the socket send buffer. | ||
1457 | |||
1458 | wmem_max | ||
1459 | -------- | ||
1460 | |||
1461 | The maximum send socket buffer size in bytes. | ||
1462 | |||
1463 | message_burst and message_cost | ||
1464 | ------------------------------ | ||
1465 | |||
1466 | These parameters are used to limit the warning messages written to the kernel | ||
1467 | log from the networking code. They enforce a rate limit to make a | ||
1468 | denial-of-service attack impossible. A higher message_cost factor, results in | ||
1469 | fewer messages that will be written. Message_burst controls when messages will | ||
1470 | be dropped. The default settings limit warning messages to one every five | ||
1471 | seconds. | ||
1472 | |||
1473 | warnings | ||
1474 | -------- | ||
1475 | |||
1476 | This controls console messages from the networking stack that can occur because | ||
1477 | of problems on the network like duplicate address or bad checksums. Normally, | ||
1478 | this should be enabled, but if the problem persists the messages can be | ||
1479 | disabled. | ||
1480 | |||
1481 | |||
1482 | netdev_max_backlog | ||
1483 | ------------------ | ||
1484 | |||
1485 | Maximum number of packets, queued on the INPUT side, when the interface | ||
1486 | receives packets faster than kernel can process them. | ||
1487 | |||
1488 | optmem_max | ||
1489 | ---------- | ||
1490 | |||
1491 | Maximum ancillary buffer size allowed per socket. Ancillary data is a sequence | ||
1492 | of struct cmsghdr structures with appended data. | ||
1493 | |||
1494 | /proc/sys/net/unix - Parameters for Unix domain sockets | ||
1495 | ------------------------------------------------------- | ||
1496 | |||
1497 | There are only two files in this subdirectory. They control the delays for | ||
1498 | deleting and destroying socket descriptors. | ||
1499 | |||
1500 | 2.8 /proc/sys/net/ipv4 - IPV4 settings | ||
1501 | -------------------------------------- | ||
1502 | |||
1503 | IP version 4 is still the most used protocol in Unix networking. It will be | ||
1504 | replaced by IP version 6 in the next couple of years, but for the moment it's | ||
1505 | the de facto standard for the internet and is used in most networking | ||
1506 | environments around the world. Because of the importance of this protocol, | ||
1507 | we'll have a deeper look into the subtree controlling the behavior of the IPv4 | ||
1508 | subsystem of the Linux kernel. | ||
1509 | |||
1510 | Let's start with the entries in /proc/sys/net/ipv4. | ||
1511 | |||
1512 | ICMP settings | ||
1513 | ------------- | ||
1514 | |||
1515 | icmp_echo_ignore_all and icmp_echo_ignore_broadcasts | ||
1516 | ---------------------------------------------------- | ||
1517 | |||
1518 | Turn on (1) or off (0), if the kernel should ignore all ICMP ECHO requests, or | ||
1519 | just those to broadcast and multicast addresses. | ||
1520 | |||
1521 | Please note that if you accept ICMP echo requests with a broadcast/multi\-cast | ||
1522 | destination address your network may be used as an exploder for denial of | ||
1523 | service packet flooding attacks to other hosts. | ||
1524 | |||
1525 | icmp_destunreach_rate, icmp_echoreply_rate, icmp_paramprob_rate and icmp_timeexeed_rate | ||
1526 | --------------------------------------------------------------------------------------- | ||
1527 | |||
1528 | Sets limits for sending ICMP packets to specific targets. A value of zero | ||
1529 | disables all limiting. Any positive value sets the maximum package rate in | ||
1530 | hundredth of a second (on Intel systems). | ||
1531 | |||
1532 | IP settings | ||
1533 | ----------- | ||
1534 | |||
1535 | ip_autoconfig | ||
1536 | ------------- | ||
1537 | |||
1538 | This file contains the number one if the host received its IP configuration by | ||
1539 | RARP, BOOTP, DHCP or a similar mechanism. Otherwise it is zero. | ||
1540 | |||
1541 | ip_default_ttl | ||
1542 | -------------- | ||
1543 | |||
1544 | TTL (Time To Live) for IPv4 interfaces. This is simply the maximum number of | ||
1545 | hops a packet may travel. | ||
1546 | |||
1547 | ip_dynaddr | ||
1548 | ---------- | ||
1549 | |||
1550 | Enable dynamic socket address rewriting on interface address change. This is | ||
1551 | useful for dialup interface with changing IP addresses. | ||
1552 | |||
1553 | ip_forward | ||
1554 | ---------- | ||
1555 | |||
1556 | Enable or disable forwarding of IP packages between interfaces. Changing this | ||
1557 | value resets all other parameters to their default values. They differ if the | ||
1558 | kernel is configured as host or router. | ||
1559 | |||
1560 | ip_local_port_range | ||
1561 | ------------------- | ||
1562 | |||
1563 | Range of ports used by TCP and UDP to choose the local port. Contains two | ||
1564 | numbers, the first number is the lowest port, the second number the highest | ||
1565 | local port. Default is 1024-4999. Should be changed to 32768-61000 for | ||
1566 | high-usage systems. | ||
1567 | |||
1568 | ip_no_pmtu_disc | ||
1569 | --------------- | ||
1570 | |||
1571 | Global switch to turn path MTU discovery off. It can also be set on a per | ||
1572 | socket basis by the applications or on a per route basis. | ||
1573 | |||
1574 | ip_masq_debug | ||
1575 | ------------- | ||
1576 | |||
1577 | Enable/disable debugging of IP masquerading. | ||
1578 | |||
1579 | IP fragmentation settings | ||
1580 | ------------------------- | ||
1581 | |||
1582 | ipfrag_high_trash and ipfrag_low_trash | ||
1583 | -------------------------------------- | ||
1584 | |||
1585 | Maximum memory used to reassemble IP fragments. When ipfrag_high_thresh bytes | ||
1586 | of memory is allocated for this purpose, the fragment handler will toss | ||
1587 | packets until ipfrag_low_thresh is reached. | ||
1588 | |||
1589 | ipfrag_time | ||
1590 | ----------- | ||
1591 | |||
1592 | Time in seconds to keep an IP fragment in memory. | ||
1593 | |||
1594 | TCP settings | ||
1595 | ------------ | ||
1596 | |||
1597 | tcp_ecn | ||
1598 | ------- | ||
1599 | |||
1600 | This file controls the use of the ECN bit in the IPv4 headers. This is a new | ||
1601 | feature about Explicit Congestion Notification, but some routers and firewalls | ||
1602 | block traffic that has this bit set, so it could be necessary to echo 0 to | ||
1603 | /proc/sys/net/ipv4/tcp_ecn if you want to talk to these sites. For more info | ||
1604 | you could read RFC2481. | ||
1605 | |||
1606 | tcp_retrans_collapse | ||
1607 | -------------------- | ||
1608 | |||
1609 | Bug-to-bug compatibility with some broken printers. On retransmit, try to send | ||
1610 | larger packets to work around bugs in certain TCP stacks. Can be turned off by | ||
1611 | setting it to zero. | ||
1612 | |||
1613 | tcp_keepalive_probes | ||
1614 | -------------------- | ||
1615 | |||
1616 | Number of keep alive probes TCP sends out, until it decides that the | ||
1617 | connection is broken. | ||
1618 | |||
1619 | tcp_keepalive_time | ||
1620 | ------------------ | ||
1621 | |||
1622 | How often TCP sends out keep alive messages, when keep alive is enabled. The | ||
1623 | default is 2 hours. | ||
1624 | |||
1625 | tcp_syn_retries | ||
1626 | --------------- | ||
1627 | |||
1628 | Number of times initial SYNs for a TCP connection attempt will be | ||
1629 | retransmitted. Should not be higher than 255. This is only the timeout for | ||
1630 | outgoing connections, for incoming connections the number of retransmits is | ||
1631 | defined by tcp_retries1. | ||
1632 | |||
1633 | tcp_sack | ||
1634 | -------- | ||
1635 | |||
1636 | Enable select acknowledgments after RFC2018. | ||
1637 | |||
1638 | tcp_timestamps | ||
1639 | -------------- | ||
1640 | |||
1641 | Enable timestamps as defined in RFC1323. | ||
1642 | |||
1643 | tcp_stdurg | ||
1644 | ---------- | ||
1645 | |||
1646 | Enable the strict RFC793 interpretation of the TCP urgent pointer field. The | ||
1647 | default is to use the BSD compatible interpretation of the urgent pointer | ||
1648 | pointing to the first byte after the urgent data. The RFC793 interpretation is | ||
1649 | to have it point to the last byte of urgent data. Enabling this option may | ||
1650 | lead to interoperability problems. Disabled by default. | ||
1651 | |||
1652 | tcp_syncookies | ||
1653 | -------------- | ||
1654 | |||
1655 | Only valid when the kernel was compiled with CONFIG_SYNCOOKIES. Send out | ||
1656 | syncookies when the syn backlog queue of a socket overflows. This is to ward | ||
1657 | off the common 'syn flood attack'. Disabled by default. | ||
1658 | |||
1659 | Note that the concept of a socket backlog is abandoned. This means the peer | ||
1660 | may not receive reliable error messages from an over loaded server with | ||
1661 | syncookies enabled. | ||
1662 | |||
1663 | tcp_window_scaling | ||
1664 | ------------------ | ||
1665 | |||
1666 | Enable window scaling as defined in RFC1323. | ||
1667 | |||
1668 | tcp_fin_timeout | ||
1669 | --------------- | ||
1670 | |||
1671 | The length of time in seconds it takes to receive a final FIN before the | ||
1672 | socket is always closed. This is strictly a violation of the TCP | ||
1673 | specification, but required to prevent denial-of-service attacks. | ||
1674 | |||
1675 | tcp_max_ka_probes | ||
1676 | ----------------- | ||
1677 | |||
1678 | Indicates how many keep alive probes are sent per slow timer run. Should not | ||
1679 | be set too high to prevent bursts. | ||
1680 | |||
1681 | tcp_max_syn_backlog | ||
1682 | ------------------- | ||
1683 | |||
1684 | Length of the per socket backlog queue. Since Linux 2.2 the backlog specified | ||
1685 | in listen(2) only specifies the length of the backlog queue of already | ||
1686 | established sockets. When more connection requests arrive Linux starts to drop | ||
1687 | packets. When syncookies are enabled the packets are still answered and the | ||
1688 | maximum queue is effectively ignored. | ||
1689 | |||
1690 | tcp_retries1 | ||
1691 | ------------ | ||
1692 | |||
1693 | Defines how often an answer to a TCP connection request is retransmitted | ||
1694 | before giving up. | ||
1695 | |||
1696 | tcp_retries2 | ||
1697 | ------------ | ||
1698 | |||
1699 | Defines how often a TCP packet is retransmitted before giving up. | ||
1700 | |||
1701 | Interface specific settings | ||
1702 | --------------------------- | ||
1703 | |||
1704 | In the directory /proc/sys/net/ipv4/conf you'll find one subdirectory for each | ||
1705 | interface the system knows about and one directory calls all. Changes in the | ||
1706 | all subdirectory affect all interfaces, whereas changes in the other | ||
1707 | subdirectories affect only one interface. All directories have the same | ||
1708 | entries: | ||
1709 | |||
1710 | accept_redirects | ||
1711 | ---------------- | ||
1712 | |||
1713 | This switch decides if the kernel accepts ICMP redirect messages or not. The | ||
1714 | default is 'yes' if the kernel is configured for a regular host and 'no' for a | ||
1715 | router configuration. | ||
1716 | |||
1717 | accept_source_route | ||
1718 | ------------------- | ||
1719 | |||
1720 | Should source routed packages be accepted or declined. The default is | ||
1721 | dependent on the kernel configuration. It's 'yes' for routers and 'no' for | ||
1722 | hosts. | ||
1723 | |||
1724 | bootp_relay | ||
1725 | ~~~~~~~~~~~ | ||
1726 | |||
1727 | Accept packets with source address 0.b.c.d with destinations not to this host | ||
1728 | as local ones. It is supposed that a BOOTP relay daemon will catch and forward | ||
1729 | such packets. | ||
1730 | |||
1731 | The default is 0, since this feature is not implemented yet (kernel version | ||
1732 | 2.2.12). | ||
1733 | |||
1734 | forwarding | ||
1735 | ---------- | ||
1736 | |||
1737 | Enable or disable IP forwarding on this interface. | ||
1738 | |||
1739 | log_martians | ||
1740 | ------------ | ||
1741 | |||
1742 | Log packets with source addresses with no known route to kernel log. | ||
1743 | |||
1744 | mc_forwarding | ||
1745 | ------------- | ||
1746 | |||
1747 | Do multicast routing. The kernel needs to be compiled with CONFIG_MROUTE and a | ||
1748 | multicast routing daemon is required. | ||
1749 | |||
1750 | proxy_arp | ||
1751 | --------- | ||
1752 | |||
1753 | Does (1) or does not (0) perform proxy ARP. | ||
1754 | |||
1755 | rp_filter | ||
1756 | --------- | ||
1757 | |||
1758 | Integer value determines if a source validation should be made. 1 means yes, 0 | ||
1759 | means no. Disabled by default, but local/broadcast address spoofing is always | ||
1760 | on. | ||
1761 | |||
1762 | If you set this to 1 on a router that is the only connection for a network to | ||
1763 | the net, it will prevent spoofing attacks against your internal networks | ||
1764 | (external addresses can still be spoofed), without the need for additional | ||
1765 | firewall rules. | ||
1766 | |||
1767 | secure_redirects | ||
1768 | ---------------- | ||
1769 | |||
1770 | Accept ICMP redirect messages only for gateways, listed in default gateway | ||
1771 | list. Enabled by default. | ||
1772 | |||
1773 | shared_media | ||
1774 | ------------ | ||
1775 | |||
1776 | If it is not set the kernel does not assume that different subnets on this | ||
1777 | device can communicate directly. Default setting is 'yes'. | ||
1778 | |||
1779 | send_redirects | ||
1780 | -------------- | ||
1781 | |||
1782 | Determines whether to send ICMP redirects to other hosts. | ||
1783 | |||
1784 | Routing settings | ||
1785 | ---------------- | ||
1786 | |||
1787 | The directory /proc/sys/net/ipv4/route contains several file to control | ||
1788 | routing issues. | ||
1789 | |||
1790 | error_burst and error_cost | ||
1791 | -------------------------- | ||
1792 | |||
1793 | These parameters are used to limit how many ICMP destination unreachable to | ||
1794 | send from the host in question. ICMP destination unreachable messages are | ||
1795 | sent when we cannot reach the next hop while trying to transmit a packet. | ||
1796 | It will also print some error messages to kernel logs if someone is ignoring | ||
1797 | our ICMP redirects. The higher the error_cost factor is, the fewer | ||
1798 | destination unreachable and error messages will be let through. Error_burst | ||
1799 | controls when destination unreachable messages and error messages will be | ||
1800 | dropped. The default settings limit warning messages to five every second. | ||
1801 | |||
1802 | flush | ||
1803 | ----- | ||
1804 | |||
1805 | Writing to this file results in a flush of the routing cache. | ||
1806 | |||
1807 | gc_elasticity, gc_interval, gc_min_interval_ms, gc_timeout, gc_thresh | ||
1808 | --------------------------------------------------------------------- | ||
1809 | |||
1810 | Values to control the frequency and behavior of the garbage collection | ||
1811 | algorithm for the routing cache. gc_min_interval is deprecated and replaced | ||
1812 | by gc_min_interval_ms. | ||
1813 | |||
1814 | |||
1815 | max_size | ||
1816 | -------- | ||
1817 | |||
1818 | Maximum size of the routing cache. Old entries will be purged once the cache | ||
1819 | reached has this size. | ||
1820 | |||
1821 | redirect_load, redirect_number | ||
1822 | ------------------------------ | ||
1823 | |||
1824 | Factors which determine if more ICPM redirects should be sent to a specific | ||
1825 | host. No redirects will be sent once the load limit or the maximum number of | ||
1826 | redirects has been reached. | ||
1827 | |||
1828 | redirect_silence | ||
1829 | ---------------- | ||
1830 | |||
1831 | Timeout for redirects. After this period redirects will be sent again, even if | ||
1832 | this has been stopped, because the load or number limit has been reached. | ||
1833 | |||
1834 | Network Neighbor handling | ||
1835 | ------------------------- | ||
1836 | |||
1837 | Settings about how to handle connections with direct neighbors (nodes attached | ||
1838 | to the same link) can be found in the directory /proc/sys/net/ipv4/neigh. | ||
1839 | |||
1840 | As we saw it in the conf directory, there is a default subdirectory which | ||
1841 | holds the default values, and one directory for each interface. The contents | ||
1842 | of the directories are identical, with the single exception that the default | ||
1843 | settings contain additional options to set garbage collection parameters. | ||
1844 | |||
1845 | In the interface directories you'll find the following entries: | ||
1846 | |||
1847 | base_reachable_time, base_reachable_time_ms | ||
1848 | ------------------------------------------- | ||
1849 | |||
1850 | A base value used for computing the random reachable time value as specified | ||
1851 | in RFC2461. | ||
1852 | |||
1853 | Expression of base_reachable_time, which is deprecated, is in seconds. | ||
1854 | Expression of base_reachable_time_ms is in milliseconds. | ||
1855 | |||
1856 | retrans_time, retrans_time_ms | ||
1857 | ----------------------------- | ||
1858 | |||
1859 | The time between retransmitted Neighbor Solicitation messages. | ||
1860 | Used for address resolution and to determine if a neighbor is | ||
1861 | unreachable. | ||
1862 | |||
1863 | Expression of retrans_time, which is deprecated, is in 1/100 seconds (for | ||
1864 | IPv4) or in jiffies (for IPv6). | ||
1865 | Expression of retrans_time_ms is in milliseconds. | ||
1866 | |||
1867 | unres_qlen | ||
1868 | ---------- | ||
1869 | |||
1870 | Maximum queue length for a pending arp request - the number of packets which | ||
1871 | are accepted from other layers while the ARP address is still resolved. | ||
1872 | |||
1873 | anycast_delay | ||
1874 | ------------- | ||
1875 | |||
1876 | Maximum for random delay of answers to neighbor solicitation messages in | ||
1877 | jiffies (1/100 sec). Not yet implemented (Linux does not have anycast support | ||
1878 | yet). | ||
1879 | |||
1880 | ucast_solicit | ||
1881 | ------------- | ||
1882 | |||
1883 | Maximum number of retries for unicast solicitation. | ||
1884 | |||
1885 | mcast_solicit | ||
1886 | ------------- | ||
1887 | |||
1888 | Maximum number of retries for multicast solicitation. | ||
1889 | |||
1890 | delay_first_probe_time | ||
1891 | ---------------------- | ||
1892 | |||
1893 | Delay for the first time probe if the neighbor is reachable. (see | ||
1894 | gc_stale_time) | ||
1895 | |||
1896 | locktime | ||
1897 | -------- | ||
1898 | |||
1899 | An ARP/neighbor entry is only replaced with a new one if the old is at least | ||
1900 | locktime old. This prevents ARP cache thrashing. | ||
1901 | |||
1902 | proxy_delay | ||
1903 | ----------- | ||
1904 | |||
1905 | Maximum time (real time is random [0..proxytime]) before answering to an ARP | ||
1906 | request for which we have an proxy ARP entry. In some cases, this is used to | ||
1907 | prevent network flooding. | ||
1908 | |||
1909 | proxy_qlen | ||
1910 | ---------- | ||
1911 | |||
1912 | Maximum queue length of the delayed proxy arp timer. (see proxy_delay). | ||
1913 | |||
1914 | app_solicit | ||
1915 | ---------- | ||
1916 | |||
1917 | Determines the number of requests to send to the user level ARP daemon. Use 0 | ||
1918 | to turn off. | ||
1919 | |||
1920 | gc_stale_time | ||
1921 | ------------- | ||
1922 | |||
1923 | Determines how often to check for stale ARP entries. After an ARP entry is | ||
1924 | stale it will be resolved again (which is useful when an IP address migrates | ||
1925 | to another machine). When ucast_solicit is greater than 0 it first tries to | ||
1926 | send an ARP packet directly to the known host When that fails and | ||
1927 | mcast_solicit is greater than 0, an ARP request is broadcasted. | ||
1928 | |||
1929 | 2.9 Appletalk | ||
1930 | ------------- | ||
1931 | |||
1932 | The /proc/sys/net/appletalk directory holds the Appletalk configuration data | ||
1933 | when Appletalk is loaded. The configurable parameters are: | ||
1934 | |||
1935 | aarp-expiry-time | ||
1936 | ---------------- | ||
1937 | |||
1938 | The amount of time we keep an ARP entry before expiring it. Used to age out | ||
1939 | old hosts. | ||
1940 | |||
1941 | aarp-resolve-time | ||
1942 | ----------------- | ||
1943 | |||
1944 | The amount of time we will spend trying to resolve an Appletalk address. | ||
1945 | |||
1946 | aarp-retransmit-limit | ||
1947 | --------------------- | ||
1948 | |||
1949 | The number of times we will retransmit a query before giving up. | ||
1950 | |||
1951 | aarp-tick-time | ||
1952 | -------------- | ||
1953 | |||
1954 | Controls the rate at which expires are checked. | ||
1955 | |||
1956 | The directory /proc/net/appletalk holds the list of active Appletalk sockets | ||
1957 | on a machine. | ||
1958 | |||
1959 | The fields indicate the DDP type, the local address (in network:node format) | ||
1960 | the remote address, the size of the transmit pending queue, the size of the | ||
1961 | received queue (bytes waiting for applications to read) the state and the uid | ||
1962 | owning the socket. | ||
1963 | |||
1964 | /proc/net/atalk_iface lists all the interfaces configured for appletalk.It | ||
1965 | shows the name of the interface, its Appletalk address, the network range on | ||
1966 | that address (or network number for phase 1 networks), and the status of the | ||
1967 | interface. | ||
1968 | |||
1969 | /proc/net/atalk_route lists each known network route. It lists the target | ||
1970 | (network) that the route leads to, the router (may be directly connected), the | ||
1971 | route flags, and the device the route is using. | ||
1972 | |||
1973 | 2.10 IPX | ||
1974 | -------- | ||
1975 | |||
1976 | The IPX protocol has no tunable values in proc/sys/net. | ||
1977 | |||
1978 | The IPX protocol does, however, provide proc/net/ipx. This lists each IPX | ||
1979 | socket giving the local and remote addresses in Novell format (that is | ||
1980 | network:node:port). In accordance with the strange Novell tradition, | ||
1981 | everything but the port is in hex. Not_Connected is displayed for sockets that | ||
1982 | are not tied to a specific remote address. The Tx and Rx queue sizes indicate | ||
1983 | the number of bytes pending for transmission and reception. The state | ||
1984 | indicates the state the socket is in and the uid is the owning uid of the | ||
1985 | socket. | ||
1986 | |||
1987 | The /proc/net/ipx_interface file lists all IPX interfaces. For each interface | ||
1988 | it gives the network number, the node number, and indicates if the network is | ||
1989 | the primary network. It also indicates which device it is bound to (or | ||
1990 | Internal for internal networks) and the Frame Type if appropriate. Linux | ||
1991 | supports 802.3, 802.2, 802.2 SNAP and DIX (Blue Book) ethernet framing for | ||
1992 | IPX. | ||
1993 | |||
1994 | The /proc/net/ipx_route table holds a list of IPX routes. For each route it | ||
1995 | gives the destination network, the router node (or Directly) and the network | ||
1996 | address of the router (or Connected) for internal networks. | ||
1997 | |||
1998 | 2.11 /proc/sys/fs/mqueue - POSIX message queues filesystem | ||
1999 | ---------------------------------------------------------- | ||
2000 | |||
2001 | The "mqueue" filesystem provides the necessary kernel features to enable the | ||
2002 | creation of a user space library that implements the POSIX message queues | ||
2003 | API (as noted by the MSG tag in the POSIX 1003.1-2001 version of the System | ||
2004 | Interfaces specification.) | ||
2005 | |||
2006 | The "mqueue" filesystem contains values for determining/setting the amount of | ||
2007 | resources used by the file system. | ||
2008 | |||
2009 | /proc/sys/fs/mqueue/queues_max is a read/write file for setting/getting the | ||
2010 | maximum number of message queues allowed on the system. | ||
2011 | |||
2012 | /proc/sys/fs/mqueue/msg_max is a read/write file for setting/getting the | ||
2013 | maximum number of messages in a queue value. In fact it is the limiting value | ||
2014 | for another (user) limit which is set in mq_open invocation. This attribute of | ||
2015 | a queue must be less or equal then msg_max. | ||
2016 | |||
2017 | /proc/sys/fs/mqueue/msgsize_max is a read/write file for setting/getting the | ||
2018 | maximum message size value (it is every message queue's attribute set during | ||
2019 | its creation). | ||
2020 | 1002 | ||
2021 | 2.12 /proc/<pid>/oom_adj - Adjust the oom-killer score | 1003 | 3.1 /proc/<pid>/oom_adj - Adjust the oom-killer score |
2022 | ------------------------------------------------------ | 1004 | ------------------------------------------------------ |
2023 | 1005 | ||
2024 | This file can be used to adjust the score used to select which processes | 1006 | This file can be used to adjust the score used to select which processes |
@@ -2055,25 +1037,15 @@ The task with the highest badness score is then selected and its children | |||
2055 | are killed, process itself will be killed in an OOM situation when it does | 1037 | are killed, process itself will be killed in an OOM situation when it does |
2056 | not have children or some of them disabled oom like described above. | 1038 | not have children or some of them disabled oom like described above. |
2057 | 1039 | ||
2058 | 2.13 /proc/<pid>/oom_score - Display current oom-killer score | 1040 | 3.2 /proc/<pid>/oom_score - Display current oom-killer score |
2059 | ------------------------------------------------------------- | 1041 | ------------------------------------------------------------- |
2060 | 1042 | ||
2061 | ------------------------------------------------------------------------------ | ||
2062 | This file can be used to check the current score used by the oom-killer is for | 1043 | This file can be used to check the current score used by the oom-killer is for |
2063 | any given <pid>. Use it together with /proc/<pid>/oom_adj to tune which | 1044 | any given <pid>. Use it together with /proc/<pid>/oom_adj to tune which |
2064 | process should be killed in an out-of-memory situation. | 1045 | process should be killed in an out-of-memory situation. |
2065 | 1046 | ||
2066 | ------------------------------------------------------------------------------ | ||
2067 | Summary | ||
2068 | ------------------------------------------------------------------------------ | ||
2069 | Certain aspects of kernel behavior can be modified at runtime, without the | ||
2070 | need to recompile the kernel, or even to reboot the system. The files in the | ||
2071 | /proc/sys tree can not only be read, but also modified. You can use the echo | ||
2072 | command to write value into these files, thereby changing the default settings | ||
2073 | of the kernel. | ||
2074 | ------------------------------------------------------------------------------ | ||
2075 | 1047 | ||
2076 | 2.14 /proc/<pid>/io - Display the IO accounting fields | 1048 | 3.3 /proc/<pid>/io - Display the IO accounting fields |
2077 | ------------------------------------------------------- | 1049 | ------------------------------------------------------- |
2078 | 1050 | ||
2079 | This file contains IO statistics for each running process | 1051 | This file contains IO statistics for each running process |
@@ -2175,7 +1147,7 @@ those 64-bit counters, process A could see an intermediate result. | |||
2175 | More information about this can be found within the taskstats documentation in | 1147 | More information about this can be found within the taskstats documentation in |
2176 | Documentation/accounting. | 1148 | Documentation/accounting. |
2177 | 1149 | ||
2178 | 2.15 /proc/<pid>/coredump_filter - Core dump filtering settings | 1150 | 3.4 /proc/<pid>/coredump_filter - Core dump filtering settings |
2179 | --------------------------------------------------------------- | 1151 | --------------------------------------------------------------- |
2180 | When a process is dumped, all anonymous memory is written to a core file as | 1152 | When a process is dumped, all anonymous memory is written to a core file as |
2181 | long as the size of the core file isn't limited. But sometimes we don't want | 1153 | long as the size of the core file isn't limited. But sometimes we don't want |
@@ -2219,7 +1191,7 @@ For example: | |||
2219 | $ echo 0x7 > /proc/self/coredump_filter | 1191 | $ echo 0x7 > /proc/self/coredump_filter |
2220 | $ ./some_program | 1192 | $ ./some_program |
2221 | 1193 | ||
2222 | 2.16 /proc/<pid>/mountinfo - Information about mounts | 1194 | 3.5 /proc/<pid>/mountinfo - Information about mounts |
2223 | -------------------------------------------------------- | 1195 | -------------------------------------------------------- |
2224 | 1196 | ||
2225 | This file contains lines of the form: | 1197 | This file contains lines of the form: |
@@ -2256,30 +1228,3 @@ For more information on mount propagation see: | |||
2256 | 1228 | ||
2257 | Documentation/filesystems/sharedsubtree.txt | 1229 | Documentation/filesystems/sharedsubtree.txt |
2258 | 1230 | ||
2259 | 2.17 /proc/sys/fs/epoll - Configuration options for the epoll interface | ||
2260 | -------------------------------------------------------- | ||
2261 | |||
2262 | This directory contains configuration options for the epoll(7) interface. | ||
2263 | |||
2264 | max_user_instances | ||
2265 | ------------------ | ||
2266 | |||
2267 | This is the maximum number of epoll file descriptors that a single user can | ||
2268 | have open at a given time. The default value is 128, and should be enough | ||
2269 | for normal users. | ||
2270 | |||
2271 | max_user_watches | ||
2272 | ---------------- | ||
2273 | |||
2274 | Every epoll file descriptor can store a number of files to be monitored | ||
2275 | for event readiness. Each one of these monitored files constitutes a "watch". | ||
2276 | This configuration option sets the maximum number of "watches" that are | ||
2277 | allowed for each user. | ||
2278 | Each "watch" costs roughly 90 bytes on a 32bit kernel, and roughly 160 bytes | ||
2279 | on a 64bit one. | ||
2280 | The current default value for max_user_watches is the 1/32 of the available | ||
2281 | low memory, divided for the "watch" cost in bytes. | ||
2282 | |||
2283 | |||
2284 | ------------------------------------------------------------------------------ | ||
2285 | |||
diff --git a/Documentation/filesystems/squashfs.txt b/Documentation/filesystems/squashfs.txt index 3e79e4a7a392..b324c033035a 100644 --- a/Documentation/filesystems/squashfs.txt +++ b/Documentation/filesystems/squashfs.txt | |||
@@ -22,7 +22,7 @@ Squashfs filesystem features versus Cramfs: | |||
22 | 22 | ||
23 | Squashfs Cramfs | 23 | Squashfs Cramfs |
24 | 24 | ||
25 | Max filesystem size: 2^64 16 MiB | 25 | Max filesystem size: 2^64 256 MiB |
26 | Max file size: ~ 2 TiB 16 MiB | 26 | Max file size: ~ 2 TiB 16 MiB |
27 | Max files: unlimited unlimited | 27 | Max files: unlimited unlimited |
28 | Max directories: unlimited unlimited | 28 | Max directories: unlimited unlimited |
diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt index 68ef48839c04..26e4b8bc53ee 100644 --- a/Documentation/filesystems/sysfs-pci.txt +++ b/Documentation/filesystems/sysfs-pci.txt | |||
@@ -9,8 +9,10 @@ that support it. For example, a given bus might look like this: | |||
9 | | |-- class | 9 | | |-- class |
10 | | |-- config | 10 | | |-- config |
11 | | |-- device | 11 | | |-- device |
12 | | |-- enable | ||
12 | | |-- irq | 13 | | |-- irq |
13 | | |-- local_cpus | 14 | | |-- local_cpus |
15 | | |-- remove | ||
14 | | |-- resource | 16 | | |-- resource |
15 | | |-- resource0 | 17 | | |-- resource0 |
16 | | |-- resource1 | 18 | | |-- resource1 |
@@ -32,8 +34,10 @@ files, each with their own function. | |||
32 | class PCI class (ascii, ro) | 34 | class PCI class (ascii, ro) |
33 | config PCI config space (binary, rw) | 35 | config PCI config space (binary, rw) |
34 | device PCI device (ascii, ro) | 36 | device PCI device (ascii, ro) |
37 | enable Whether the device is enabled (ascii, rw) | ||
35 | irq IRQ number (ascii, ro) | 38 | irq IRQ number (ascii, ro) |
36 | local_cpus nearby CPU mask (cpumask, ro) | 39 | local_cpus nearby CPU mask (cpumask, ro) |
40 | remove remove device from kernel's list (ascii, wo) | ||
37 | resource PCI resource host addresses (ascii, ro) | 41 | resource PCI resource host addresses (ascii, ro) |
38 | resource0..N PCI resource N, if present (binary, mmap) | 42 | resource0..N PCI resource N, if present (binary, mmap) |
39 | resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap) | 43 | resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap) |
@@ -44,6 +48,7 @@ files, each with their own function. | |||
44 | 48 | ||
45 | ro - read only file | 49 | ro - read only file |
46 | rw - file is readable and writable | 50 | rw - file is readable and writable |
51 | wo - write only file | ||
47 | mmap - file is mmapable | 52 | mmap - file is mmapable |
48 | ascii - file contains ascii text | 53 | ascii - file contains ascii text |
49 | binary - file contains binary data | 54 | binary - file contains binary data |
@@ -57,10 +62,26 @@ used to do actual device programming from userspace. Note that some platforms | |||
57 | don't support mmapping of certain resources, so be sure to check the return | 62 | don't support mmapping of certain resources, so be sure to check the return |
58 | value from any attempted mmap. | 63 | value from any attempted mmap. |
59 | 64 | ||
65 | The 'enable' file provides a counter that indicates how many times the device | ||
66 | has been enabled. If the 'enable' file currently returns '4', and a '1' is | ||
67 | echoed into it, it will then return '5'. Echoing a '0' into it will decrease | ||
68 | the count. Even when it returns to 0, though, some of the initialisation | ||
69 | may not be reversed. | ||
70 | |||
60 | The 'rom' file is special in that it provides read-only access to the device's | 71 | The 'rom' file is special in that it provides read-only access to the device's |
61 | ROM file, if available. It's disabled by default, however, so applications | 72 | ROM file, if available. It's disabled by default, however, so applications |
62 | should write the string "1" to the file to enable it before attempting a read | 73 | should write the string "1" to the file to enable it before attempting a read |
63 | call, and disable it following the access by writing "0" to the file. | 74 | call, and disable it following the access by writing "0" to the file. Note |
75 | that the device must be enabled for a rom read to return data succesfully. | ||
76 | In the event a driver is not bound to the device, it can be enabled using the | ||
77 | 'enable' file, documented above. | ||
78 | |||
79 | The 'remove' file is used to remove the PCI device, by writing a non-zero | ||
80 | integer to the file. This does not involve any kind of hot-plug functionality, | ||
81 | e.g. powering off the device. The device is removed from the kernel's list of | ||
82 | PCI devices, the sysfs directory for it is removed, and the device will be | ||
83 | removed from any drivers attached to it. Removal of PCI root buses is | ||
84 | disallowed. | ||
64 | 85 | ||
65 | Accessing legacy resources through sysfs | 86 | Accessing legacy resources through sysfs |
66 | ---------------------------------------- | 87 | ---------------------------------------- |
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index 9e9c348275a9..7e81e37c0b1e 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt | |||
@@ -2,8 +2,10 @@ | |||
2 | sysfs - _The_ filesystem for exporting kernel objects. | 2 | sysfs - _The_ filesystem for exporting kernel objects. |
3 | 3 | ||
4 | Patrick Mochel <mochel@osdl.org> | 4 | Patrick Mochel <mochel@osdl.org> |
5 | Mike Murphy <mamurph@cs.clemson.edu> | ||
5 | 6 | ||
6 | 10 January 2003 | 7 | Revised: 22 February 2009 |
8 | Original: 10 January 2003 | ||
7 | 9 | ||
8 | 10 | ||
9 | What it is: | 11 | What it is: |
@@ -64,12 +66,13 @@ An attribute definition is simply: | |||
64 | 66 | ||
65 | struct attribute { | 67 | struct attribute { |
66 | char * name; | 68 | char * name; |
69 | struct module *owner; | ||
67 | mode_t mode; | 70 | mode_t mode; |
68 | }; | 71 | }; |
69 | 72 | ||
70 | 73 | ||
71 | int sysfs_create_file(struct kobject * kobj, struct attribute * attr); | 74 | int sysfs_create_file(struct kobject * kobj, const struct attribute * attr); |
72 | void sysfs_remove_file(struct kobject * kobj, struct attribute * attr); | 75 | void sysfs_remove_file(struct kobject * kobj, const struct attribute * attr); |
73 | 76 | ||
74 | 77 | ||
75 | A bare attribute contains no means to read or write the value of the | 78 | A bare attribute contains no means to read or write the value of the |
@@ -80,9 +83,11 @@ a specific object type. | |||
80 | For example, the driver model defines struct device_attribute like: | 83 | For example, the driver model defines struct device_attribute like: |
81 | 84 | ||
82 | struct device_attribute { | 85 | struct device_attribute { |
83 | struct attribute attr; | 86 | struct attribute attr; |
84 | ssize_t (*show)(struct device * dev, char * buf); | 87 | ssize_t (*show)(struct device *dev, struct device_attribute *attr, |
85 | ssize_t (*store)(struct device * dev, const char * buf); | 88 | char *buf); |
89 | ssize_t (*store)(struct device *dev, struct device_attribute *attr, | ||
90 | const char *buf, size_t count); | ||
86 | }; | 91 | }; |
87 | 92 | ||
88 | int device_create_file(struct device *, struct device_attribute *); | 93 | int device_create_file(struct device *, struct device_attribute *); |
@@ -90,12 +95,8 @@ void device_remove_file(struct device *, struct device_attribute *); | |||
90 | 95 | ||
91 | It also defines this helper for defining device attributes: | 96 | It also defines this helper for defining device attributes: |
92 | 97 | ||
93 | #define DEVICE_ATTR(_name, _mode, _show, _store) \ | 98 | #define DEVICE_ATTR(_name, _mode, _show, _store) \ |
94 | struct device_attribute dev_attr_##_name = { \ | 99 | struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store) |
95 | .attr = {.name = __stringify(_name) , .mode = _mode }, \ | ||
96 | .show = _show, \ | ||
97 | .store = _store, \ | ||
98 | }; | ||
99 | 100 | ||
100 | For example, declaring | 101 | For example, declaring |
101 | 102 | ||
@@ -107,9 +108,9 @@ static struct device_attribute dev_attr_foo = { | |||
107 | .attr = { | 108 | .attr = { |
108 | .name = "foo", | 109 | .name = "foo", |
109 | .mode = S_IWUSR | S_IRUGO, | 110 | .mode = S_IWUSR | S_IRUGO, |
111 | .show = show_foo, | ||
112 | .store = store_foo, | ||
110 | }, | 113 | }, |
111 | .show = show_foo, | ||
112 | .store = store_foo, | ||
113 | }; | 114 | }; |
114 | 115 | ||
115 | 116 | ||
@@ -161,10 +162,12 @@ To read or write attributes, show() or store() methods must be | |||
161 | specified when declaring the attribute. The method types should be as | 162 | specified when declaring the attribute. The method types should be as |
162 | simple as those defined for device attributes: | 163 | simple as those defined for device attributes: |
163 | 164 | ||
164 | ssize_t (*show)(struct device * dev, char * buf); | 165 | ssize_t (*show)(struct device * dev, struct device_attribute * attr, |
165 | ssize_t (*store)(struct device * dev, const char * buf); | 166 | char * buf); |
167 | ssize_t (*store)(struct device * dev, struct device_attribute * attr, | ||
168 | const char * buf); | ||
166 | 169 | ||
167 | IOW, they should take only an object and a buffer as parameters. | 170 | IOW, they should take only an object, an attribute, and a buffer as parameters. |
168 | 171 | ||
169 | 172 | ||
170 | sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the | 173 | sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the |
@@ -299,14 +302,16 @@ The following interface layers currently exist in sysfs: | |||
299 | Structure: | 302 | Structure: |
300 | 303 | ||
301 | struct device_attribute { | 304 | struct device_attribute { |
302 | struct attribute attr; | 305 | struct attribute attr; |
303 | ssize_t (*show)(struct device * dev, char * buf); | 306 | ssize_t (*show)(struct device *dev, struct device_attribute *attr, |
304 | ssize_t (*store)(struct device * dev, const char * buf); | 307 | char *buf); |
308 | ssize_t (*store)(struct device *dev, struct device_attribute *attr, | ||
309 | const char *buf, size_t count); | ||
305 | }; | 310 | }; |
306 | 311 | ||
307 | Declaring: | 312 | Declaring: |
308 | 313 | ||
309 | DEVICE_ATTR(_name, _str, _mode, _show, _store); | 314 | DEVICE_ATTR(_name, _mode, _show, _store); |
310 | 315 | ||
311 | Creation/Removal: | 316 | Creation/Removal: |
312 | 317 | ||
@@ -342,7 +347,8 @@ Structure: | |||
342 | struct driver_attribute { | 347 | struct driver_attribute { |
343 | struct attribute attr; | 348 | struct attribute attr; |
344 | ssize_t (*show)(struct device_driver *, char * buf); | 349 | ssize_t (*show)(struct device_driver *, char * buf); |
345 | ssize_t (*store)(struct device_driver *, const char * buf); | 350 | ssize_t (*store)(struct device_driver *, const char * buf, |
351 | size_t count); | ||
346 | }; | 352 | }; |
347 | 353 | ||
348 | Declaring: | 354 | Declaring: |
diff --git a/Documentation/filesystems/udf.txt b/Documentation/filesystems/udf.txt index fde829a756e6..902b95d0ee51 100644 --- a/Documentation/filesystems/udf.txt +++ b/Documentation/filesystems/udf.txt | |||
@@ -24,6 +24,8 @@ The following mount options are supported: | |||
24 | 24 | ||
25 | gid= Set the default group. | 25 | gid= Set the default group. |
26 | umask= Set the default umask. | 26 | umask= Set the default umask. |
27 | mode= Set the default file permissions. | ||
28 | dmode= Set the default directory permissions. | ||
27 | uid= Set the default user. | 29 | uid= Set the default user. |
28 | bs= Set the block size. | 30 | bs= Set the block size. |
29 | unhide Show otherwise hidden files. | 31 | unhide Show otherwise hidden files. |
diff --git a/Documentation/ftrace.txt b/Documentation/ftrace.txt index 803b1318b13d..fd9a3e693813 100644 --- a/Documentation/ftrace.txt +++ b/Documentation/ftrace.txt | |||
@@ -15,31 +15,31 @@ Introduction | |||
15 | 15 | ||
16 | Ftrace is an internal tracer designed to help out developers and | 16 | Ftrace is an internal tracer designed to help out developers and |
17 | designers of systems to find what is going on inside the kernel. | 17 | designers of systems to find what is going on inside the kernel. |
18 | It can be used for debugging or analyzing latencies and performance | 18 | It can be used for debugging or analyzing latencies and |
19 | issues that take place outside of user-space. | 19 | performance issues that take place outside of user-space. |
20 | 20 | ||
21 | Although ftrace is the function tracer, it also includes an | 21 | Although ftrace is the function tracer, it also includes an |
22 | infrastructure that allows for other types of tracing. Some of the | 22 | infrastructure that allows for other types of tracing. Some of |
23 | tracers that are currently in ftrace include a tracer to trace | 23 | the tracers that are currently in ftrace include a tracer to |
24 | context switches, the time it takes for a high priority task to | 24 | trace context switches, the time it takes for a high priority |
25 | run after it was woken up, the time interrupts are disabled, and | 25 | task to run after it was woken up, the time interrupts are |
26 | more (ftrace allows for tracer plugins, which means that the list of | 26 | disabled, and more (ftrace allows for tracer plugins, which |
27 | tracers can always grow). | 27 | means that the list of tracers can always grow). |
28 | 28 | ||
29 | 29 | ||
30 | The File System | 30 | The File System |
31 | --------------- | 31 | --------------- |
32 | 32 | ||
33 | Ftrace uses the debugfs file system to hold the control files as well | 33 | Ftrace uses the debugfs file system to hold the control files as |
34 | as the files to display output. | 34 | well as the files to display output. |
35 | 35 | ||
36 | To mount the debugfs system: | 36 | To mount the debugfs system: |
37 | 37 | ||
38 | # mkdir /debug | 38 | # mkdir /debug |
39 | # mount -t debugfs nodev /debug | 39 | # mount -t debugfs nodev /debug |
40 | 40 | ||
41 | (Note: it is more common to mount at /sys/kernel/debug, but for simplicity | 41 | ( Note: it is more common to mount at /sys/kernel/debug, but for |
42 | this document will use /debug) | 42 | simplicity this document will use /debug) |
43 | 43 | ||
44 | That's it! (assuming that you have ftrace configured into your kernel) | 44 | That's it! (assuming that you have ftrace configured into your kernel) |
45 | 45 | ||
@@ -50,90 +50,124 @@ of ftrace. Here is a list of some of the key files: | |||
50 | 50 | ||
51 | Note: all time values are in microseconds. | 51 | Note: all time values are in microseconds. |
52 | 52 | ||
53 | current_tracer: This is used to set or display the current tracer | 53 | current_tracer: |
54 | that is configured. | 54 | |
55 | 55 | This is used to set or display the current tracer | |
56 | available_tracers: This holds the different types of tracers that | 56 | that is configured. |
57 | have been compiled into the kernel. The tracers | 57 | |
58 | listed here can be configured by echoing their name | 58 | available_tracers: |
59 | into current_tracer. | 59 | |
60 | 60 | This holds the different types of tracers that | |
61 | tracing_enabled: This sets or displays whether the current_tracer | 61 | have been compiled into the kernel. The |
62 | is activated and tracing or not. Echo 0 into this | 62 | tracers listed here can be configured by |
63 | file to disable the tracer or 1 to enable it. | 63 | echoing their name into current_tracer. |
64 | 64 | ||
65 | trace: This file holds the output of the trace in a human readable | 65 | tracing_enabled: |
66 | format (described below). | 66 | |
67 | 67 | This sets or displays whether the current_tracer | |
68 | latency_trace: This file shows the same trace but the information | 68 | is activated and tracing or not. Echo 0 into this |
69 | is organized more to display possible latencies | 69 | file to disable the tracer or 1 to enable it. |
70 | in the system (described below). | 70 | |
71 | 71 | trace: | |
72 | trace_pipe: The output is the same as the "trace" file but this | 72 | |
73 | file is meant to be streamed with live tracing. | 73 | This file holds the output of the trace in a human |
74 | Reads from this file will block until new data | 74 | readable format (described below). |
75 | is retrieved. Unlike the "trace" and "latency_trace" | 75 | |
76 | files, this file is a consumer. This means reading | 76 | latency_trace: |
77 | from this file causes sequential reads to display | 77 | |
78 | more current data. Once data is read from this | 78 | This file shows the same trace but the information |
79 | file, it is consumed, and will not be read | 79 | is organized more to display possible latencies |
80 | again with a sequential read. The "trace" and | 80 | in the system (described below). |
81 | "latency_trace" files are static, and if the | 81 | |
82 | tracer is not adding more data, they will display | 82 | trace_pipe: |
83 | the same information every time they are read. | 83 | |
84 | 84 | The output is the same as the "trace" file but this | |
85 | trace_options: This file lets the user control the amount of data | 85 | file is meant to be streamed with live tracing. |
86 | that is displayed in one of the above output | 86 | Reads from this file will block until new data |
87 | files. | 87 | is retrieved. Unlike the "trace" and "latency_trace" |
88 | 88 | files, this file is a consumer. This means reading | |
89 | trace_max_latency: Some of the tracers record the max latency. | 89 | from this file causes sequential reads to display |
90 | For example, the time interrupts are disabled. | 90 | more current data. Once data is read from this |
91 | This time is saved in this file. The max trace | 91 | file, it is consumed, and will not be read |
92 | will also be stored, and displayed by either | 92 | again with a sequential read. The "trace" and |
93 | "trace" or "latency_trace". A new max trace will | 93 | "latency_trace" files are static, and if the |
94 | only be recorded if the latency is greater than | 94 | tracer is not adding more data, they will display |
95 | the value in this file. (in microseconds) | 95 | the same information every time they are read. |
96 | 96 | ||
97 | buffer_size_kb: This sets or displays the number of kilobytes each CPU | 97 | trace_options: |
98 | buffer can hold. The tracer buffers are the same size | 98 | |
99 | for each CPU. The displayed number is the size of the | 99 | This file lets the user control the amount of data |
100 | CPU buffer and not total size of all buffers. The | 100 | that is displayed in one of the above output |
101 | trace buffers are allocated in pages (blocks of memory | 101 | files. |
102 | that the kernel uses for allocation, usually 4 KB in size). | 102 | |
103 | If the last page allocated has room for more bytes | 103 | tracing_max_latency: |
104 | than requested, the rest of the page will be used, | 104 | |
105 | making the actual allocation bigger than requested. | 105 | Some of the tracers record the max latency. |
106 | (Note, the size may not be a multiple of the page size due | 106 | For example, the time interrupts are disabled. |
107 | to buffer managment overhead.) | 107 | This time is saved in this file. The max trace |
108 | 108 | will also be stored, and displayed by either | |
109 | This can only be updated when the current_tracer | 109 | "trace" or "latency_trace". A new max trace will |
110 | is set to "nop". | 110 | only be recorded if the latency is greater than |
111 | 111 | the value in this file. (in microseconds) | |
112 | tracing_cpumask: This is a mask that lets the user only trace | 112 | |
113 | on specified CPUS. The format is a hex string | 113 | buffer_size_kb: |
114 | representing the CPUS. | 114 | |
115 | 115 | This sets or displays the number of kilobytes each CPU | |
116 | set_ftrace_filter: When dynamic ftrace is configured in (see the | 116 | buffer can hold. The tracer buffers are the same size |
117 | section below "dynamic ftrace"), the code is dynamically | 117 | for each CPU. The displayed number is the size of the |
118 | modified (code text rewrite) to disable calling of the | 118 | CPU buffer and not total size of all buffers. The |
119 | function profiler (mcount). This lets tracing be configured | 119 | trace buffers are allocated in pages (blocks of memory |
120 | in with practically no overhead in performance. This also | 120 | that the kernel uses for allocation, usually 4 KB in size). |
121 | has a side effect of enabling or disabling specific functions | 121 | If the last page allocated has room for more bytes |
122 | to be traced. Echoing names of functions into this file | 122 | than requested, the rest of the page will be used, |
123 | will limit the trace to only those functions. | 123 | making the actual allocation bigger than requested. |
124 | 124 | ( Note, the size may not be a multiple of the page size | |
125 | set_ftrace_notrace: This has an effect opposite to that of | 125 | due to buffer managment overhead. ) |
126 | set_ftrace_filter. Any function that is added here will not | 126 | |
127 | be traced. If a function exists in both set_ftrace_filter | 127 | This can only be updated when the current_tracer |
128 | and set_ftrace_notrace, the function will _not_ be traced. | 128 | is set to "nop". |
129 | 129 | ||
130 | set_ftrace_pid: Have the function tracer only trace a single thread. | 130 | tracing_cpumask: |
131 | 131 | ||
132 | available_filter_functions: This lists the functions that ftrace | 132 | This is a mask that lets the user only trace |
133 | has processed and can trace. These are the function | 133 | on specified CPUS. The format is a hex string |
134 | names that you can pass to "set_ftrace_filter" or | 134 | representing the CPUS. |
135 | "set_ftrace_notrace". (See the section "dynamic ftrace" | 135 | |
136 | below for more details.) | 136 | set_ftrace_filter: |
137 | |||
138 | When dynamic ftrace is configured in (see the | ||
139 | section below "dynamic ftrace"), the code is dynamically | ||
140 | modified (code text rewrite) to disable calling of the | ||
141 | function profiler (mcount). This lets tracing be configured | ||
142 | in with practically no overhead in performance. This also | ||
143 | has a side effect of enabling or disabling specific functions | ||
144 | to be traced. Echoing names of functions into this file | ||
145 | will limit the trace to only those functions. | ||
146 | |||
147 | set_ftrace_notrace: | ||
148 | |||
149 | This has an effect opposite to that of | ||
150 | set_ftrace_filter. Any function that is added here will not | ||
151 | be traced. If a function exists in both set_ftrace_filter | ||
152 | and set_ftrace_notrace, the function will _not_ be traced. | ||
153 | |||
154 | set_ftrace_pid: | ||
155 | |||
156 | Have the function tracer only trace a single thread. | ||
157 | |||
158 | set_graph_function: | ||
159 | |||
160 | Set a "trigger" function where tracing should start | ||
161 | with the function graph tracer (See the section | ||
162 | "dynamic ftrace" for more details). | ||
163 | |||
164 | available_filter_functions: | ||
165 | |||
166 | This lists the functions that ftrace | ||
167 | has processed and can trace. These are the function | ||
168 | names that you can pass to "set_ftrace_filter" or | ||
169 | "set_ftrace_notrace". (See the section "dynamic ftrace" | ||
170 | below for more details.) | ||
137 | 171 | ||
138 | 172 | ||
139 | The Tracers | 173 | The Tracers |
@@ -141,36 +175,66 @@ The Tracers | |||
141 | 175 | ||
142 | Here is the list of current tracers that may be configured. | 176 | Here is the list of current tracers that may be configured. |
143 | 177 | ||
144 | function - function tracer that uses mcount to trace all functions. | 178 | "function" |
179 | |||
180 | Function call tracer to trace all kernel functions. | ||
181 | |||
182 | "function_graph_tracer" | ||
183 | |||
184 | Similar to the function tracer except that the | ||
185 | function tracer probes the functions on their entry | ||
186 | whereas the function graph tracer traces on both entry | ||
187 | and exit of the functions. It then provides the ability | ||
188 | to draw a graph of function calls similar to C code | ||
189 | source. | ||
145 | 190 | ||
146 | sched_switch - traces the context switches between tasks. | 191 | "sched_switch" |
147 | 192 | ||
148 | irqsoff - traces the areas that disable interrupts and saves | 193 | Traces the context switches and wakeups between tasks. |
149 | the trace with the longest max latency. | ||
150 | See tracing_max_latency. When a new max is recorded, | ||
151 | it replaces the old trace. It is best to view this | ||
152 | trace via the latency_trace file. | ||
153 | 194 | ||
154 | preemptoff - Similar to irqsoff but traces and records the amount of | 195 | "irqsoff" |
155 | time for which preemption is disabled. | ||
156 | 196 | ||
157 | preemptirqsoff - Similar to irqsoff and preemptoff, but traces and | 197 | Traces the areas that disable interrupts and saves |
158 | records the largest time for which irqs and/or preemption | 198 | the trace with the longest max latency. |
159 | is disabled. | 199 | See tracing_max_latency. When a new max is recorded, |
200 | it replaces the old trace. It is best to view this | ||
201 | trace via the latency_trace file. | ||
160 | 202 | ||
161 | wakeup - Traces and records the max latency that it takes for | 203 | "preemptoff" |
162 | the highest priority task to get scheduled after | ||
163 | it has been woken up. | ||
164 | 204 | ||
165 | nop - This is not a tracer. To remove all tracers from tracing | 205 | Similar to irqsoff but traces and records the amount of |
166 | simply echo "nop" into current_tracer. | 206 | time for which preemption is disabled. |
207 | |||
208 | "preemptirqsoff" | ||
209 | |||
210 | Similar to irqsoff and preemptoff, but traces and | ||
211 | records the largest time for which irqs and/or preemption | ||
212 | is disabled. | ||
213 | |||
214 | "wakeup" | ||
215 | |||
216 | Traces and records the max latency that it takes for | ||
217 | the highest priority task to get scheduled after | ||
218 | it has been woken up. | ||
219 | |||
220 | "hw-branch-tracer" | ||
221 | |||
222 | Uses the BTS CPU feature on x86 CPUs to traces all | ||
223 | branches executed. | ||
224 | |||
225 | "nop" | ||
226 | |||
227 | This is the "trace nothing" tracer. To remove all | ||
228 | tracers from tracing simply echo "nop" into | ||
229 | current_tracer. | ||
167 | 230 | ||
168 | 231 | ||
169 | Examples of using the tracer | 232 | Examples of using the tracer |
170 | ---------------------------- | 233 | ---------------------------- |
171 | 234 | ||
172 | Here are typical examples of using the tracers when controlling them only | 235 | Here are typical examples of using the tracers when controlling |
173 | with the debugfs interface (without using any user-land utilities). | 236 | them only with the debugfs interface (without using any |
237 | user-land utilities). | ||
174 | 238 | ||
175 | Output format: | 239 | Output format: |
176 | -------------- | 240 | -------------- |
@@ -187,16 +251,16 @@ Here is an example of the output format of the file "trace" | |||
187 | bash-4251 [01] 10152.583855: _atomic_dec_and_lock <-dput | 251 | bash-4251 [01] 10152.583855: _atomic_dec_and_lock <-dput |
188 | -------- | 252 | -------- |
189 | 253 | ||
190 | A header is printed with the tracer name that is represented by the trace. | 254 | A header is printed with the tracer name that is represented by |
191 | In this case the tracer is "function". Then a header showing the format. Task | 255 | the trace. In this case the tracer is "function". Then a header |
192 | name "bash", the task PID "4251", the CPU that it was running on | 256 | showing the format. Task name "bash", the task PID "4251", the |
193 | "01", the timestamp in <secs>.<usecs> format, the function name that was | 257 | CPU that it was running on "01", the timestamp in <secs>.<usecs> |
194 | traced "path_put" and the parent function that called this function | 258 | format, the function name that was traced "path_put" and the |
195 | "path_walk". The timestamp is the time at which the function was | 259 | parent function that called this function "path_walk". The |
196 | entered. | 260 | timestamp is the time at which the function was entered. |
197 | 261 | ||
198 | The sched_switch tracer also includes tracing of task wakeups and | 262 | The sched_switch tracer also includes tracing of task wakeups |
199 | context switches. | 263 | and context switches. |
200 | 264 | ||
201 | ksoftirqd/1-7 [01] 1453.070013: 7:115:R + 2916:115:S | 265 | ksoftirqd/1-7 [01] 1453.070013: 7:115:R + 2916:115:S |
202 | ksoftirqd/1-7 [01] 1453.070013: 7:115:R + 10:115:S | 266 | ksoftirqd/1-7 [01] 1453.070013: 7:115:R + 10:115:S |
@@ -205,8 +269,8 @@ context switches. | |||
205 | kondemand/1-2916 [01] 1453.070013: 2916:115:S ==> 7:115:R | 269 | kondemand/1-2916 [01] 1453.070013: 2916:115:S ==> 7:115:R |
206 | ksoftirqd/1-7 [01] 1453.070013: 7:115:S ==> 0:140:R | 270 | ksoftirqd/1-7 [01] 1453.070013: 7:115:S ==> 0:140:R |
207 | 271 | ||
208 | Wake ups are represented by a "+" and the context switches are shown as | 272 | Wake ups are represented by a "+" and the context switches are |
209 | "==>". The format is: | 273 | shown as "==>". The format is: |
210 | 274 | ||
211 | Context switches: | 275 | Context switches: |
212 | 276 | ||
@@ -220,19 +284,20 @@ Wake ups are represented by a "+" and the context switches are shown as | |||
220 | 284 | ||
221 | <pid>:<prio>:<state> + <pid>:<prio>:<state> | 285 | <pid>:<prio>:<state> + <pid>:<prio>:<state> |
222 | 286 | ||
223 | The prio is the internal kernel priority, which is the inverse of the | 287 | The prio is the internal kernel priority, which is the inverse |
224 | priority that is usually displayed by user-space tools. Zero represents | 288 | of the priority that is usually displayed by user-space tools. |
225 | the highest priority (99). Prio 100 starts the "nice" priorities with | 289 | Zero represents the highest priority (99). Prio 100 starts the |
226 | 100 being equal to nice -20 and 139 being nice 19. The prio "140" is | 290 | "nice" priorities with 100 being equal to nice -20 and 139 being |
227 | reserved for the idle task which is the lowest priority thread (pid 0). | 291 | nice 19. The prio "140" is reserved for the idle task which is |
292 | the lowest priority thread (pid 0). | ||
228 | 293 | ||
229 | 294 | ||
230 | Latency trace format | 295 | Latency trace format |
231 | -------------------- | 296 | -------------------- |
232 | 297 | ||
233 | For traces that display latency times, the latency_trace file gives | 298 | For traces that display latency times, the latency_trace file |
234 | somewhat more information to see why a latency happened. Here is a typical | 299 | gives somewhat more information to see why a latency happened. |
235 | trace. | 300 | Here is a typical trace. |
236 | 301 | ||
237 | # tracer: irqsoff | 302 | # tracer: irqsoff |
238 | # | 303 | # |
@@ -259,20 +324,20 @@ irqsoff latency trace v1.1.5 on 2.6.26-rc8 | |||
259 | <idle>-0 0d.s1 98us : trace_hardirqs_on (do_softirq) | 324 | <idle>-0 0d.s1 98us : trace_hardirqs_on (do_softirq) |
260 | 325 | ||
261 | 326 | ||
327 | This shows that the current tracer is "irqsoff" tracing the time | ||
328 | for which interrupts were disabled. It gives the trace version | ||
329 | and the version of the kernel upon which this was executed on | ||
330 | (2.6.26-rc8). Then it displays the max latency in microsecs (97 | ||
331 | us). The number of trace entries displayed and the total number | ||
332 | recorded (both are three: #3/3). The type of preemption that was | ||
333 | used (PREEMPT). VP, KP, SP, and HP are always zero and are | ||
334 | reserved for later use. #P is the number of online CPUS (#P:2). | ||
262 | 335 | ||
263 | This shows that the current tracer is "irqsoff" tracing the time for which | 336 | The task is the process that was running when the latency |
264 | interrupts were disabled. It gives the trace version and the version | 337 | occurred. (swapper pid: 0). |
265 | of the kernel upon which this was executed on (2.6.26-rc8). Then it displays | ||
266 | the max latency in microsecs (97 us). The number of trace entries displayed | ||
267 | and the total number recorded (both are three: #3/3). The type of | ||
268 | preemption that was used (PREEMPT). VP, KP, SP, and HP are always zero | ||
269 | and are reserved for later use. #P is the number of online CPUS (#P:2). | ||
270 | |||
271 | The task is the process that was running when the latency occurred. | ||
272 | (swapper pid: 0). | ||
273 | 338 | ||
274 | The start and stop (the functions in which the interrupts were disabled and | 339 | The start and stop (the functions in which the interrupts were |
275 | enabled respectively) that caused the latencies: | 340 | disabled and enabled respectively) that caused the latencies: |
276 | 341 | ||
277 | apic_timer_interrupt is where the interrupts were disabled. | 342 | apic_timer_interrupt is where the interrupts were disabled. |
278 | do_softirq is where they were enabled again. | 343 | do_softirq is where they were enabled again. |
@@ -308,12 +373,12 @@ The above is mostly meaningful for kernel developers. | |||
308 | latency_trace file is relative to the start of the trace. | 373 | latency_trace file is relative to the start of the trace. |
309 | 374 | ||
310 | delay: This is just to help catch your eye a bit better. And | 375 | delay: This is just to help catch your eye a bit better. And |
311 | needs to be fixed to be only relative to the same CPU. | 376 | needs to be fixed to be only relative to the same CPU. |
312 | The marks are determined by the difference between this | 377 | The marks are determined by the difference between this |
313 | current trace and the next trace. | 378 | current trace and the next trace. |
314 | '!' - greater than preempt_mark_thresh (default 100) | 379 | '!' - greater than preempt_mark_thresh (default 100) |
315 | '+' - greater than 1 microsecond | 380 | '+' - greater than 1 microsecond |
316 | ' ' - less than or equal to 1 microsecond. | 381 | ' ' - less than or equal to 1 microsecond. |
317 | 382 | ||
318 | The rest is the same as the 'trace' file. | 383 | The rest is the same as the 'trace' file. |
319 | 384 | ||
@@ -321,14 +386,15 @@ The above is mostly meaningful for kernel developers. | |||
321 | trace_options | 386 | trace_options |
322 | ------------- | 387 | ------------- |
323 | 388 | ||
324 | The trace_options file is used to control what gets printed in the trace | 389 | The trace_options file is used to control what gets printed in |
325 | output. To see what is available, simply cat the file: | 390 | the trace output. To see what is available, simply cat the file: |
326 | 391 | ||
327 | cat /debug/tracing/trace_options | 392 | cat /debug/tracing/trace_options |
328 | print-parent nosym-offset nosym-addr noverbose noraw nohex nobin \ | 393 | print-parent nosym-offset nosym-addr noverbose noraw nohex nobin \ |
329 | noblock nostacktrace nosched-tree nouserstacktrace nosym-userobj | 394 | noblock nostacktrace nosched-tree nouserstacktrace nosym-userobj |
330 | 395 | ||
331 | To disable one of the options, echo in the option prepended with "no". | 396 | To disable one of the options, echo in the option prepended with |
397 | "no". | ||
332 | 398 | ||
333 | echo noprint-parent > /debug/tracing/trace_options | 399 | echo noprint-parent > /debug/tracing/trace_options |
334 | 400 | ||
@@ -338,8 +404,8 @@ To enable an option, leave off the "no". | |||
338 | 404 | ||
339 | Here are the available options: | 405 | Here are the available options: |
340 | 406 | ||
341 | print-parent - On function traces, display the calling function | 407 | print-parent - On function traces, display the calling (parent) |
342 | as well as the function being traced. | 408 | function as well as the function being traced. |
343 | 409 | ||
344 | print-parent: | 410 | print-parent: |
345 | bash-4000 [01] 1477.606694: simple_strtoul <-strict_strtoul | 411 | bash-4000 [01] 1477.606694: simple_strtoul <-strict_strtoul |
@@ -348,15 +414,16 @@ Here are the available options: | |||
348 | bash-4000 [01] 1477.606694: simple_strtoul | 414 | bash-4000 [01] 1477.606694: simple_strtoul |
349 | 415 | ||
350 | 416 | ||
351 | sym-offset - Display not only the function name, but also the offset | 417 | sym-offset - Display not only the function name, but also the |
352 | in the function. For example, instead of seeing just | 418 | offset in the function. For example, instead of |
353 | "ktime_get", you will see "ktime_get+0xb/0x20". | 419 | seeing just "ktime_get", you will see |
420 | "ktime_get+0xb/0x20". | ||
354 | 421 | ||
355 | sym-offset: | 422 | sym-offset: |
356 | bash-4000 [01] 1477.606694: simple_strtoul+0x6/0xa0 | 423 | bash-4000 [01] 1477.606694: simple_strtoul+0x6/0xa0 |
357 | 424 | ||
358 | sym-addr - this will also display the function address as well as | 425 | sym-addr - this will also display the function address as well |
359 | the function name. | 426 | as the function name. |
360 | 427 | ||
361 | sym-addr: | 428 | sym-addr: |
362 | bash-4000 [01] 1477.606694: simple_strtoul <c0339346> | 429 | bash-4000 [01] 1477.606694: simple_strtoul <c0339346> |
@@ -366,35 +433,41 @@ Here are the available options: | |||
366 | bash 4000 1 0 00000000 00010a95 [58127d26] 1720.415ms \ | 433 | bash 4000 1 0 00000000 00010a95 [58127d26] 1720.415ms \ |
367 | (+0.000ms): simple_strtoul (strict_strtoul) | 434 | (+0.000ms): simple_strtoul (strict_strtoul) |
368 | 435 | ||
369 | raw - This will display raw numbers. This option is best for use with | 436 | raw - This will display raw numbers. This option is best for |
370 | user applications that can translate the raw numbers better than | 437 | use with user applications that can translate the raw |
371 | having it done in the kernel. | 438 | numbers better than having it done in the kernel. |
372 | 439 | ||
373 | hex - Similar to raw, but the numbers will be in a hexadecimal format. | 440 | hex - Similar to raw, but the numbers will be in a hexadecimal |
441 | format. | ||
374 | 442 | ||
375 | bin - This will print out the formats in raw binary. | 443 | bin - This will print out the formats in raw binary. |
376 | 444 | ||
377 | block - TBD (needs update) | 445 | block - TBD (needs update) |
378 | 446 | ||
379 | stacktrace - This is one of the options that changes the trace itself. | 447 | stacktrace - This is one of the options that changes the trace |
380 | When a trace is recorded, so is the stack of functions. | 448 | itself. When a trace is recorded, so is the stack |
381 | This allows for back traces of trace sites. | 449 | of functions. This allows for back traces of |
450 | trace sites. | ||
382 | 451 | ||
383 | userstacktrace - This option changes the trace. | 452 | userstacktrace - This option changes the trace. It records a |
384 | It records a stacktrace of the current userspace thread. | 453 | stacktrace of the current userspace thread. |
385 | 454 | ||
386 | sym-userobj - when user stacktrace are enabled, look up which object the | 455 | sym-userobj - when user stacktrace are enabled, look up which |
387 | address belongs to, and print a relative address | 456 | object the address belongs to, and print a |
388 | This is especially useful when ASLR is on, otherwise you don't | 457 | relative address. This is especially useful when |
389 | get a chance to resolve the address to object/file/line after the app is no | 458 | ASLR is on, otherwise you don't get a chance to |
390 | longer running | 459 | resolve the address to object/file/line after |
460 | the app is no longer running | ||
391 | 461 | ||
392 | The lookup is performed when you read trace,trace_pipe,latency_trace. Example: | 462 | The lookup is performed when you read |
463 | trace,trace_pipe,latency_trace. Example: | ||
393 | 464 | ||
394 | a.out-1623 [000] 40874.465068: /root/a.out[+0x480] <-/root/a.out[+0 | 465 | a.out-1623 [000] 40874.465068: /root/a.out[+0x480] <-/root/a.out[+0 |
395 | x494] <- /root/a.out[+0x4a8] <- /lib/libc-2.7.so[+0x1e1a6] | 466 | x494] <- /root/a.out[+0x4a8] <- /lib/libc-2.7.so[+0x1e1a6] |
396 | 467 | ||
397 | sched-tree - TBD (any users??) | 468 | sched-tree - trace all tasks that are on the runqueue, at |
469 | every scheduling event. Will add overhead if | ||
470 | there's a lot of tasks running at once. | ||
398 | 471 | ||
399 | 472 | ||
400 | sched_switch | 473 | sched_switch |
@@ -431,18 +504,19 @@ of how to use it. | |||
431 | [...] | 504 | [...] |
432 | 505 | ||
433 | 506 | ||
434 | As we have discussed previously about this format, the header shows | 507 | As we have discussed previously about this format, the header |
435 | the name of the trace and points to the options. The "FUNCTION" | 508 | shows the name of the trace and points to the options. The |
436 | is a misnomer since here it represents the wake ups and context | 509 | "FUNCTION" is a misnomer since here it represents the wake ups |
437 | switches. | 510 | and context switches. |
438 | 511 | ||
439 | The sched_switch file only lists the wake ups (represented with '+') | 512 | The sched_switch file only lists the wake ups (represented with |
440 | and context switches ('==>') with the previous task or current task | 513 | '+') and context switches ('==>') with the previous task or |
441 | first followed by the next task or task waking up. The format for both | 514 | current task first followed by the next task or task waking up. |
442 | of these is PID:KERNEL-PRIO:TASK-STATE. Remember that the KERNEL-PRIO | 515 | The format for both of these is PID:KERNEL-PRIO:TASK-STATE. |
443 | is the inverse of the actual priority with zero (0) being the highest | 516 | Remember that the KERNEL-PRIO is the inverse of the actual |
444 | priority and the nice values starting at 100 (nice -20). Below is | 517 | priority with zero (0) being the highest priority and the nice |
445 | a quick chart to map the kernel priority to user land priorities. | 518 | values starting at 100 (nice -20). Below is a quick chart to map |
519 | the kernel priority to user land priorities. | ||
446 | 520 | ||
447 | Kernel priority: 0 to 99 ==> user RT priority 99 to 0 | 521 | Kernel priority: 0 to 99 ==> user RT priority 99 to 0 |
448 | Kernel priority: 100 to 139 ==> user nice -20 to 19 | 522 | Kernel priority: 100 to 139 ==> user nice -20 to 19 |
@@ -463,10 +537,10 @@ The task states are: | |||
463 | ftrace_enabled | 537 | ftrace_enabled |
464 | -------------- | 538 | -------------- |
465 | 539 | ||
466 | The following tracers (listed below) give different output depending | 540 | The following tracers (listed below) give different output |
467 | on whether or not the sysctl ftrace_enabled is set. To set ftrace_enabled, | 541 | depending on whether or not the sysctl ftrace_enabled is set. To |
468 | one can either use the sysctl function or set it via the proc | 542 | set ftrace_enabled, one can either use the sysctl function or |
469 | file system interface. | 543 | set it via the proc file system interface. |
470 | 544 | ||
471 | sysctl kernel.ftrace_enabled=1 | 545 | sysctl kernel.ftrace_enabled=1 |
472 | 546 | ||
@@ -474,12 +548,12 @@ file system interface. | |||
474 | 548 | ||
475 | echo 1 > /proc/sys/kernel/ftrace_enabled | 549 | echo 1 > /proc/sys/kernel/ftrace_enabled |
476 | 550 | ||
477 | To disable ftrace_enabled simply replace the '1' with '0' in | 551 | To disable ftrace_enabled simply replace the '1' with '0' in the |
478 | the above commands. | 552 | above commands. |
479 | 553 | ||
480 | When ftrace_enabled is set the tracers will also record the functions | 554 | When ftrace_enabled is set the tracers will also record the |
481 | that are within the trace. The descriptions of the tracers | 555 | functions that are within the trace. The descriptions of the |
482 | will also show an example with ftrace enabled. | 556 | tracers will also show an example with ftrace enabled. |
483 | 557 | ||
484 | 558 | ||
485 | irqsoff | 559 | irqsoff |
@@ -487,17 +561,18 @@ irqsoff | |||
487 | 561 | ||
488 | When interrupts are disabled, the CPU can not react to any other | 562 | When interrupts are disabled, the CPU can not react to any other |
489 | external event (besides NMIs and SMIs). This prevents the timer | 563 | external event (besides NMIs and SMIs). This prevents the timer |
490 | interrupt from triggering or the mouse interrupt from letting the | 564 | interrupt from triggering or the mouse interrupt from letting |
491 | kernel know of a new mouse event. The result is a latency with the | 565 | the kernel know of a new mouse event. The result is a latency |
492 | reaction time. | 566 | with the reaction time. |
493 | 567 | ||
494 | The irqsoff tracer tracks the time for which interrupts are disabled. | 568 | The irqsoff tracer tracks the time for which interrupts are |
495 | When a new maximum latency is hit, the tracer saves the trace leading up | 569 | disabled. When a new maximum latency is hit, the tracer saves |
496 | to that latency point so that every time a new maximum is reached, the old | 570 | the trace leading up to that latency point so that every time a |
497 | saved trace is discarded and the new trace is saved. | 571 | new maximum is reached, the old saved trace is discarded and the |
572 | new trace is saved. | ||
498 | 573 | ||
499 | To reset the maximum, echo 0 into tracing_max_latency. Here is an | 574 | To reset the maximum, echo 0 into tracing_max_latency. Here is |
500 | example: | 575 | an example: |
501 | 576 | ||
502 | # echo irqsoff > /debug/tracing/current_tracer | 577 | # echo irqsoff > /debug/tracing/current_tracer |
503 | # echo 0 > /debug/tracing/tracing_max_latency | 578 | # echo 0 > /debug/tracing/tracing_max_latency |
@@ -532,10 +607,11 @@ irqsoff latency trace v1.1.5 on 2.6.26 | |||
532 | 607 | ||
533 | 608 | ||
534 | Here we see that that we had a latency of 12 microsecs (which is | 609 | Here we see that that we had a latency of 12 microsecs (which is |
535 | very good). The _write_lock_irq in sys_setpgid disabled interrupts. | 610 | very good). The _write_lock_irq in sys_setpgid disabled |
536 | The difference between the 12 and the displayed timestamp 14us occurred | 611 | interrupts. The difference between the 12 and the displayed |
537 | because the clock was incremented between the time of recording the max | 612 | timestamp 14us occurred because the clock was incremented |
538 | latency and the time of recording the function that had that latency. | 613 | between the time of recording the max latency and the time of |
614 | recording the function that had that latency. | ||
539 | 615 | ||
540 | Note the above example had ftrace_enabled not set. If we set the | 616 | Note the above example had ftrace_enabled not set. If we set the |
541 | ftrace_enabled, we get a much larger output: | 617 | ftrace_enabled, we get a much larger output: |
@@ -586,24 +662,24 @@ irqsoff latency trace v1.1.5 on 2.6.26-rc8 | |||
586 | 662 | ||
587 | 663 | ||
588 | Here we traced a 50 microsecond latency. But we also see all the | 664 | Here we traced a 50 microsecond latency. But we also see all the |
589 | functions that were called during that time. Note that by enabling | 665 | functions that were called during that time. Note that by |
590 | function tracing, we incur an added overhead. This overhead may | 666 | enabling function tracing, we incur an added overhead. This |
591 | extend the latency times. But nevertheless, this trace has provided | 667 | overhead may extend the latency times. But nevertheless, this |
592 | some very helpful debugging information. | 668 | trace has provided some very helpful debugging information. |
593 | 669 | ||
594 | 670 | ||
595 | preemptoff | 671 | preemptoff |
596 | ---------- | 672 | ---------- |
597 | 673 | ||
598 | When preemption is disabled, we may be able to receive interrupts but | 674 | When preemption is disabled, we may be able to receive |
599 | the task cannot be preempted and a higher priority task must wait | 675 | interrupts but the task cannot be preempted and a higher |
600 | for preemption to be enabled again before it can preempt a lower | 676 | priority task must wait for preemption to be enabled again |
601 | priority task. | 677 | before it can preempt a lower priority task. |
602 | 678 | ||
603 | The preemptoff tracer traces the places that disable preemption. | 679 | The preemptoff tracer traces the places that disable preemption. |
604 | Like the irqsoff tracer, it records the maximum latency for which preemption | 680 | Like the irqsoff tracer, it records the maximum latency for |
605 | was disabled. The control of preemptoff tracer is much like the irqsoff | 681 | which preemption was disabled. The control of preemptoff tracer |
606 | tracer. | 682 | is much like the irqsoff tracer. |
607 | 683 | ||
608 | # echo preemptoff > /debug/tracing/current_tracer | 684 | # echo preemptoff > /debug/tracing/current_tracer |
609 | # echo 0 > /debug/tracing/tracing_max_latency | 685 | # echo 0 > /debug/tracing/tracing_max_latency |
@@ -637,11 +713,12 @@ preemptoff latency trace v1.1.5 on 2.6.26-rc8 | |||
637 | sshd-4261 0d.s1 30us : trace_preempt_on (__do_softirq) | 713 | sshd-4261 0d.s1 30us : trace_preempt_on (__do_softirq) |
638 | 714 | ||
639 | 715 | ||
640 | This has some more changes. Preemption was disabled when an interrupt | 716 | This has some more changes. Preemption was disabled when an |
641 | came in (notice the 'h'), and was enabled while doing a softirq. | 717 | interrupt came in (notice the 'h'), and was enabled while doing |
642 | (notice the 's'). But we also see that interrupts have been disabled | 718 | a softirq. (notice the 's'). But we also see that interrupts |
643 | when entering the preempt off section and leaving it (the 'd'). | 719 | have been disabled when entering the preempt off section and |
644 | We do not know if interrupts were enabled in the mean time. | 720 | leaving it (the 'd'). We do not know if interrupts were enabled |
721 | in the mean time. | ||
645 | 722 | ||
646 | # tracer: preemptoff | 723 | # tracer: preemptoff |
647 | # | 724 | # |
@@ -700,28 +777,30 @@ preemptoff latency trace v1.1.5 on 2.6.26-rc8 | |||
700 | sshd-4261 0d.s1 64us : trace_preempt_on (__do_softirq) | 777 | sshd-4261 0d.s1 64us : trace_preempt_on (__do_softirq) |
701 | 778 | ||
702 | 779 | ||
703 | The above is an example of the preemptoff trace with ftrace_enabled | 780 | The above is an example of the preemptoff trace with |
704 | set. Here we see that interrupts were disabled the entire time. | 781 | ftrace_enabled set. Here we see that interrupts were disabled |
705 | The irq_enter code lets us know that we entered an interrupt 'h'. | 782 | the entire time. The irq_enter code lets us know that we entered |
706 | Before that, the functions being traced still show that it is not | 783 | an interrupt 'h'. Before that, the functions being traced still |
707 | in an interrupt, but we can see from the functions themselves that | 784 | show that it is not in an interrupt, but we can see from the |
708 | this is not the case. | 785 | functions themselves that this is not the case. |
709 | 786 | ||
710 | Notice that __do_softirq when called does not have a preempt_count. | 787 | Notice that __do_softirq when called does not have a |
711 | It may seem that we missed a preempt enabling. What really happened | 788 | preempt_count. It may seem that we missed a preempt enabling. |
712 | is that the preempt count is held on the thread's stack and we | 789 | What really happened is that the preempt count is held on the |
713 | switched to the softirq stack (4K stacks in effect). The code | 790 | thread's stack and we switched to the softirq stack (4K stacks |
714 | does not copy the preempt count, but because interrupts are disabled, | 791 | in effect). The code does not copy the preempt count, but |
715 | we do not need to worry about it. Having a tracer like this is good | 792 | because interrupts are disabled, we do not need to worry about |
716 | for letting people know what really happens inside the kernel. | 793 | it. Having a tracer like this is good for letting people know |
794 | what really happens inside the kernel. | ||
717 | 795 | ||
718 | 796 | ||
719 | preemptirqsoff | 797 | preemptirqsoff |
720 | -------------- | 798 | -------------- |
721 | 799 | ||
722 | Knowing the locations that have interrupts disabled or preemption | 800 | Knowing the locations that have interrupts disabled or |
723 | disabled for the longest times is helpful. But sometimes we would | 801 | preemption disabled for the longest times is helpful. But |
724 | like to know when either preemption and/or interrupts are disabled. | 802 | sometimes we would like to know when either preemption and/or |
803 | interrupts are disabled. | ||
725 | 804 | ||
726 | Consider the following code: | 805 | Consider the following code: |
727 | 806 | ||
@@ -741,11 +820,13 @@ The preemptoff tracer will record the total length of | |||
741 | call_function_with_irqs_and_preemption_off() and | 820 | call_function_with_irqs_and_preemption_off() and |
742 | call_function_with_preemption_off(). | 821 | call_function_with_preemption_off(). |
743 | 822 | ||
744 | But neither will trace the time that interrupts and/or preemption | 823 | But neither will trace the time that interrupts and/or |
745 | is disabled. This total time is the time that we can not schedule. | 824 | preemption is disabled. This total time is the time that we can |
746 | To record this time, use the preemptirqsoff tracer. | 825 | not schedule. To record this time, use the preemptirqsoff |
826 | tracer. | ||
747 | 827 | ||
748 | Again, using this trace is much like the irqsoff and preemptoff tracers. | 828 | Again, using this trace is much like the irqsoff and preemptoff |
829 | tracers. | ||
749 | 830 | ||
750 | # echo preemptirqsoff > /debug/tracing/current_tracer | 831 | # echo preemptirqsoff > /debug/tracing/current_tracer |
751 | # echo 0 > /debug/tracing/tracing_max_latency | 832 | # echo 0 > /debug/tracing/tracing_max_latency |
@@ -781,9 +862,10 @@ preemptirqsoff latency trace v1.1.5 on 2.6.26-rc8 | |||
781 | 862 | ||
782 | 863 | ||
783 | The trace_hardirqs_off_thunk is called from assembly on x86 when | 864 | The trace_hardirqs_off_thunk is called from assembly on x86 when |
784 | interrupts are disabled in the assembly code. Without the function | 865 | interrupts are disabled in the assembly code. Without the |
785 | tracing, we do not know if interrupts were enabled within the preemption | 866 | function tracing, we do not know if interrupts were enabled |
786 | points. We do see that it started with preemption enabled. | 867 | within the preemption points. We do see that it started with |
868 | preemption enabled. | ||
787 | 869 | ||
788 | Here is a trace with ftrace_enabled set: | 870 | Here is a trace with ftrace_enabled set: |
789 | 871 | ||
@@ -871,40 +953,42 @@ preemptirqsoff latency trace v1.1.5 on 2.6.26-rc8 | |||
871 | sshd-4261 0d.s1 105us : trace_preempt_on (__do_softirq) | 953 | sshd-4261 0d.s1 105us : trace_preempt_on (__do_softirq) |
872 | 954 | ||
873 | 955 | ||
874 | This is a very interesting trace. It started with the preemption of | 956 | This is a very interesting trace. It started with the preemption |
875 | the ls task. We see that the task had the "need_resched" bit set | 957 | of the ls task. We see that the task had the "need_resched" bit |
876 | via the 'N' in the trace. Interrupts were disabled before the spin_lock | 958 | set via the 'N' in the trace. Interrupts were disabled before |
877 | at the beginning of the trace. We see that a schedule took place to run | 959 | the spin_lock at the beginning of the trace. We see that a |
878 | sshd. When the interrupts were enabled, we took an interrupt. | 960 | schedule took place to run sshd. When the interrupts were |
879 | On return from the interrupt handler, the softirq ran. We took another | 961 | enabled, we took an interrupt. On return from the interrupt |
880 | interrupt while running the softirq as we see from the capital 'H'. | 962 | handler, the softirq ran. We took another interrupt while |
963 | running the softirq as we see from the capital 'H'. | ||
881 | 964 | ||
882 | 965 | ||
883 | wakeup | 966 | wakeup |
884 | ------ | 967 | ------ |
885 | 968 | ||
886 | In a Real-Time environment it is very important to know the wakeup | 969 | In a Real-Time environment it is very important to know the |
887 | time it takes for the highest priority task that is woken up to the | 970 | wakeup time it takes for the highest priority task that is woken |
888 | time that it executes. This is also known as "schedule latency". | 971 | up to the time that it executes. This is also known as "schedule |
889 | I stress the point that this is about RT tasks. It is also important | 972 | latency". I stress the point that this is about RT tasks. It is |
890 | to know the scheduling latency of non-RT tasks, but the average | 973 | also important to know the scheduling latency of non-RT tasks, |
891 | schedule latency is better for non-RT tasks. Tools like | 974 | but the average schedule latency is better for non-RT tasks. |
892 | LatencyTop are more appropriate for such measurements. | 975 | Tools like LatencyTop are more appropriate for such |
976 | measurements. | ||
893 | 977 | ||
894 | Real-Time environments are interested in the worst case latency. | 978 | Real-Time environments are interested in the worst case latency. |
895 | That is the longest latency it takes for something to happen, and | 979 | That is the longest latency it takes for something to happen, |
896 | not the average. We can have a very fast scheduler that may only | 980 | and not the average. We can have a very fast scheduler that may |
897 | have a large latency once in a while, but that would not work well | 981 | only have a large latency once in a while, but that would not |
898 | with Real-Time tasks. The wakeup tracer was designed to record | 982 | work well with Real-Time tasks. The wakeup tracer was designed |
899 | the worst case wakeups of RT tasks. Non-RT tasks are not recorded | 983 | to record the worst case wakeups of RT tasks. Non-RT tasks are |
900 | because the tracer only records one worst case and tracing non-RT | 984 | not recorded because the tracer only records one worst case and |
901 | tasks that are unpredictable will overwrite the worst case latency | 985 | tracing non-RT tasks that are unpredictable will overwrite the |
902 | of RT tasks. | 986 | worst case latency of RT tasks. |
903 | 987 | ||
904 | Since this tracer only deals with RT tasks, we will run this slightly | 988 | Since this tracer only deals with RT tasks, we will run this |
905 | differently than we did with the previous tracers. Instead of performing | 989 | slightly differently than we did with the previous tracers. |
906 | an 'ls', we will run 'sleep 1' under 'chrt' which changes the | 990 | Instead of performing an 'ls', we will run 'sleep 1' under |
907 | priority of the task. | 991 | 'chrt' which changes the priority of the task. |
908 | 992 | ||
909 | # echo wakeup > /debug/tracing/current_tracer | 993 | # echo wakeup > /debug/tracing/current_tracer |
910 | # echo 0 > /debug/tracing/tracing_max_latency | 994 | # echo 0 > /debug/tracing/tracing_max_latency |
@@ -934,17 +1018,16 @@ wakeup latency trace v1.1.5 on 2.6.26-rc8 | |||
934 | <idle>-0 1d..4 4us : schedule (cpu_idle) | 1018 | <idle>-0 1d..4 4us : schedule (cpu_idle) |
935 | 1019 | ||
936 | 1020 | ||
1021 | Running this on an idle system, we see that it only took 4 | ||
1022 | microseconds to perform the task switch. Note, since the trace | ||
1023 | marker in the schedule is before the actual "switch", we stop | ||
1024 | the tracing when the recorded task is about to schedule in. This | ||
1025 | may change if we add a new marker at the end of the scheduler. | ||
937 | 1026 | ||
938 | Running this on an idle system, we see that it only took 4 microseconds | 1027 | Notice that the recorded task is 'sleep' with the PID of 4901 |
939 | to perform the task switch. Note, since the trace marker in the | 1028 | and it has an rt_prio of 5. This priority is user-space priority |
940 | schedule is before the actual "switch", we stop the tracing when | 1029 | and not the internal kernel priority. The policy is 1 for |
941 | the recorded task is about to schedule in. This may change if | 1030 | SCHED_FIFO and 2 for SCHED_RR. |
942 | we add a new marker at the end of the scheduler. | ||
943 | |||
944 | Notice that the recorded task is 'sleep' with the PID of 4901 and it | ||
945 | has an rt_prio of 5. This priority is user-space priority and not | ||
946 | the internal kernel priority. The policy is 1 for SCHED_FIFO and 2 | ||
947 | for SCHED_RR. | ||
948 | 1031 | ||
949 | Doing the same with chrt -r 5 and ftrace_enabled set. | 1032 | Doing the same with chrt -r 5 and ftrace_enabled set. |
950 | 1033 | ||
@@ -1001,24 +1084,25 @@ ksoftirq-7 1d..6 49us : _spin_unlock (tracing_record_cmdline) | |||
1001 | ksoftirq-7 1d..6 49us : sub_preempt_count (_spin_unlock) | 1084 | ksoftirq-7 1d..6 49us : sub_preempt_count (_spin_unlock) |
1002 | ksoftirq-7 1d..4 50us : schedule (__cond_resched) | 1085 | ksoftirq-7 1d..4 50us : schedule (__cond_resched) |
1003 | 1086 | ||
1004 | The interrupt went off while running ksoftirqd. This task runs at | 1087 | The interrupt went off while running ksoftirqd. This task runs |
1005 | SCHED_OTHER. Why did not we see the 'N' set early? This may be | 1088 | at SCHED_OTHER. Why did not we see the 'N' set early? This may |
1006 | a harmless bug with x86_32 and 4K stacks. On x86_32 with 4K stacks | 1089 | be a harmless bug with x86_32 and 4K stacks. On x86_32 with 4K |
1007 | configured, the interrupt and softirq run with their own stack. | 1090 | stacks configured, the interrupt and softirq run with their own |
1008 | Some information is held on the top of the task's stack (need_resched | 1091 | stack. Some information is held on the top of the task's stack |
1009 | and preempt_count are both stored there). The setting of the NEED_RESCHED | 1092 | (need_resched and preempt_count are both stored there). The |
1010 | bit is done directly to the task's stack, but the reading of the | 1093 | setting of the NEED_RESCHED bit is done directly to the task's |
1011 | NEED_RESCHED is done by looking at the current stack, which in this case | 1094 | stack, but the reading of the NEED_RESCHED is done by looking at |
1012 | is the stack for the hard interrupt. This hides the fact that NEED_RESCHED | 1095 | the current stack, which in this case is the stack for the hard |
1013 | has been set. We do not see the 'N' until we switch back to the task's | 1096 | interrupt. This hides the fact that NEED_RESCHED has been set. |
1097 | We do not see the 'N' until we switch back to the task's | ||
1014 | assigned stack. | 1098 | assigned stack. |
1015 | 1099 | ||
1016 | function | 1100 | function |
1017 | -------- | 1101 | -------- |
1018 | 1102 | ||
1019 | This tracer is the function tracer. Enabling the function tracer | 1103 | This tracer is the function tracer. Enabling the function tracer |
1020 | can be done from the debug file system. Make sure the ftrace_enabled is | 1104 | can be done from the debug file system. Make sure the |
1021 | set; otherwise this tracer is a nop. | 1105 | ftrace_enabled is set; otherwise this tracer is a nop. |
1022 | 1106 | ||
1023 | # sysctl kernel.ftrace_enabled=1 | 1107 | # sysctl kernel.ftrace_enabled=1 |
1024 | # echo function > /debug/tracing/current_tracer | 1108 | # echo function > /debug/tracing/current_tracer |
@@ -1048,14 +1132,15 @@ set; otherwise this tracer is a nop. | |||
1048 | [...] | 1132 | [...] |
1049 | 1133 | ||
1050 | 1134 | ||
1051 | Note: function tracer uses ring buffers to store the above entries. | 1135 | Note: function tracer uses ring buffers to store the above |
1052 | The newest data may overwrite the oldest data. Sometimes using echo to | 1136 | entries. The newest data may overwrite the oldest data. |
1053 | stop the trace is not sufficient because the tracing could have overwritten | 1137 | Sometimes using echo to stop the trace is not sufficient because |
1054 | the data that you wanted to record. For this reason, it is sometimes better to | 1138 | the tracing could have overwritten the data that you wanted to |
1055 | disable tracing directly from a program. This allows you to stop the | 1139 | record. For this reason, it is sometimes better to disable |
1056 | tracing at the point that you hit the part that you are interested in. | 1140 | tracing directly from a program. This allows you to stop the |
1057 | To disable the tracing directly from a C program, something like following | 1141 | tracing at the point that you hit the part that you are |
1058 | code snippet can be used: | 1142 | interested in. To disable the tracing directly from a C program, |
1143 | something like following code snippet can be used: | ||
1059 | 1144 | ||
1060 | int trace_fd; | 1145 | int trace_fd; |
1061 | [...] | 1146 | [...] |
@@ -1070,10 +1155,10 @@ int main(int argc, char *argv[]) { | |||
1070 | } | 1155 | } |
1071 | 1156 | ||
1072 | Note: Here we hard coded the path name. The debugfs mount is not | 1157 | Note: Here we hard coded the path name. The debugfs mount is not |
1073 | guaranteed to be at /debug (and is more commonly at /sys/kernel/debug). | 1158 | guaranteed to be at /debug (and is more commonly at |
1074 | For simple one time traces, the above is sufficent. For anything else, | 1159 | /sys/kernel/debug). For simple one time traces, the above is |
1075 | a search through /proc/mounts may be needed to find where the debugfs | 1160 | sufficent. For anything else, a search through /proc/mounts may |
1076 | file-system is mounted. | 1161 | be needed to find where the debugfs file-system is mounted. |
1077 | 1162 | ||
1078 | 1163 | ||
1079 | Single thread tracing | 1164 | Single thread tracing |
@@ -1152,49 +1237,297 @@ int main (int argc, char **argv) | |||
1152 | return 0; | 1237 | return 0; |
1153 | } | 1238 | } |
1154 | 1239 | ||
1240 | |||
1241 | hw-branch-tracer (x86 only) | ||
1242 | --------------------------- | ||
1243 | |||
1244 | This tracer uses the x86 last branch tracing hardware feature to | ||
1245 | collect a branch trace on all cpus with relatively low overhead. | ||
1246 | |||
1247 | The tracer uses a fixed-size circular buffer per cpu and only | ||
1248 | traces ring 0 branches. The trace file dumps that buffer in the | ||
1249 | following format: | ||
1250 | |||
1251 | # tracer: hw-branch-tracer | ||
1252 | # | ||
1253 | # CPU# TO <- FROM | ||
1254 | 0 scheduler_tick+0xb5/0x1bf <- task_tick_idle+0x5/0x6 | ||
1255 | 2 run_posix_cpu_timers+0x2b/0x72a <- run_posix_cpu_timers+0x25/0x72a | ||
1256 | 0 scheduler_tick+0x139/0x1bf <- scheduler_tick+0xed/0x1bf | ||
1257 | 0 scheduler_tick+0x17c/0x1bf <- scheduler_tick+0x148/0x1bf | ||
1258 | 2 run_posix_cpu_timers+0x9e/0x72a <- run_posix_cpu_timers+0x5e/0x72a | ||
1259 | 0 scheduler_tick+0x1b6/0x1bf <- scheduler_tick+0x1aa/0x1bf | ||
1260 | |||
1261 | |||
1262 | The tracer may be used to dump the trace for the oops'ing cpu on | ||
1263 | a kernel oops into the system log. To enable this, | ||
1264 | ftrace_dump_on_oops must be set. To set ftrace_dump_on_oops, one | ||
1265 | can either use the sysctl function or set it via the proc system | ||
1266 | interface. | ||
1267 | |||
1268 | sysctl kernel.ftrace_dump_on_oops=1 | ||
1269 | |||
1270 | or | ||
1271 | |||
1272 | echo 1 > /proc/sys/kernel/ftrace_dump_on_oops | ||
1273 | |||
1274 | |||
1275 | Here's an example of such a dump after a null pointer | ||
1276 | dereference in a kernel module: | ||
1277 | |||
1278 | [57848.105921] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 | ||
1279 | [57848.106019] IP: [<ffffffffa0000006>] open+0x6/0x14 [oops] | ||
1280 | [57848.106019] PGD 2354e9067 PUD 2375e7067 PMD 0 | ||
1281 | [57848.106019] Oops: 0002 [#1] SMP | ||
1282 | [57848.106019] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:20:05.0/local_cpus | ||
1283 | [57848.106019] Dumping ftrace buffer: | ||
1284 | [57848.106019] --------------------------------- | ||
1285 | [...] | ||
1286 | [57848.106019] 0 chrdev_open+0xe6/0x165 <- cdev_put+0x23/0x24 | ||
1287 | [57848.106019] 0 chrdev_open+0x117/0x165 <- chrdev_open+0xfa/0x165 | ||
1288 | [57848.106019] 0 chrdev_open+0x120/0x165 <- chrdev_open+0x11c/0x165 | ||
1289 | [57848.106019] 0 chrdev_open+0x134/0x165 <- chrdev_open+0x12b/0x165 | ||
1290 | [57848.106019] 0 open+0x0/0x14 [oops] <- chrdev_open+0x144/0x165 | ||
1291 | [57848.106019] 0 page_fault+0x0/0x30 <- open+0x6/0x14 [oops] | ||
1292 | [57848.106019] 0 error_entry+0x0/0x5b <- page_fault+0x4/0x30 | ||
1293 | [57848.106019] 0 error_kernelspace+0x0/0x31 <- error_entry+0x59/0x5b | ||
1294 | [57848.106019] 0 error_sti+0x0/0x1 <- error_kernelspace+0x2d/0x31 | ||
1295 | [57848.106019] 0 page_fault+0x9/0x30 <- error_sti+0x0/0x1 | ||
1296 | [57848.106019] 0 do_page_fault+0x0/0x881 <- page_fault+0x1a/0x30 | ||
1297 | [...] | ||
1298 | [57848.106019] 0 do_page_fault+0x66b/0x881 <- is_prefetch+0x1ee/0x1f2 | ||
1299 | [57848.106019] 0 do_page_fault+0x6e0/0x881 <- do_page_fault+0x67a/0x881 | ||
1300 | [57848.106019] 0 oops_begin+0x0/0x96 <- do_page_fault+0x6e0/0x881 | ||
1301 | [57848.106019] 0 trace_hw_branch_oops+0x0/0x2d <- oops_begin+0x9/0x96 | ||
1302 | [...] | ||
1303 | [57848.106019] 0 ds_suspend_bts+0x2a/0xe3 <- ds_suspend_bts+0x1a/0xe3 | ||
1304 | [57848.106019] --------------------------------- | ||
1305 | [57848.106019] CPU 0 | ||
1306 | [57848.106019] Modules linked in: oops | ||
1307 | [57848.106019] Pid: 5542, comm: cat Tainted: G W 2.6.28 #23 | ||
1308 | [57848.106019] RIP: 0010:[<ffffffffa0000006>] [<ffffffffa0000006>] open+0x6/0x14 [oops] | ||
1309 | [57848.106019] RSP: 0018:ffff880235457d48 EFLAGS: 00010246 | ||
1310 | [...] | ||
1311 | |||
1312 | |||
1313 | function graph tracer | ||
1314 | --------------------------- | ||
1315 | |||
1316 | This tracer is similar to the function tracer except that it | ||
1317 | probes a function on its entry and its exit. This is done by | ||
1318 | using a dynamically allocated stack of return addresses in each | ||
1319 | task_struct. On function entry the tracer overwrites the return | ||
1320 | address of each function traced to set a custom probe. Thus the | ||
1321 | original return address is stored on the stack of return address | ||
1322 | in the task_struct. | ||
1323 | |||
1324 | Probing on both ends of a function leads to special features | ||
1325 | such as: | ||
1326 | |||
1327 | - measure of a function's time execution | ||
1328 | - having a reliable call stack to draw function calls graph | ||
1329 | |||
1330 | This tracer is useful in several situations: | ||
1331 | |||
1332 | - you want to find the reason of a strange kernel behavior and | ||
1333 | need to see what happens in detail on any areas (or specific | ||
1334 | ones). | ||
1335 | |||
1336 | - you are experiencing weird latencies but it's difficult to | ||
1337 | find its origin. | ||
1338 | |||
1339 | - you want to find quickly which path is taken by a specific | ||
1340 | function | ||
1341 | |||
1342 | - you just want to peek inside a working kernel and want to see | ||
1343 | what happens there. | ||
1344 | |||
1345 | # tracer: function_graph | ||
1346 | # | ||
1347 | # CPU DURATION FUNCTION CALLS | ||
1348 | # | | | | | | | | ||
1349 | |||
1350 | 0) | sys_open() { | ||
1351 | 0) | do_sys_open() { | ||
1352 | 0) | getname() { | ||
1353 | 0) | kmem_cache_alloc() { | ||
1354 | 0) 1.382 us | __might_sleep(); | ||
1355 | 0) 2.478 us | } | ||
1356 | 0) | strncpy_from_user() { | ||
1357 | 0) | might_fault() { | ||
1358 | 0) 1.389 us | __might_sleep(); | ||
1359 | 0) 2.553 us | } | ||
1360 | 0) 3.807 us | } | ||
1361 | 0) 7.876 us | } | ||
1362 | 0) | alloc_fd() { | ||
1363 | 0) 0.668 us | _spin_lock(); | ||
1364 | 0) 0.570 us | expand_files(); | ||
1365 | 0) 0.586 us | _spin_unlock(); | ||
1366 | |||
1367 | |||
1368 | There are several columns that can be dynamically | ||
1369 | enabled/disabled. You can use every combination of options you | ||
1370 | want, depending on your needs. | ||
1371 | |||
1372 | - The cpu number on which the function executed is default | ||
1373 | enabled. It is sometimes better to only trace one cpu (see | ||
1374 | tracing_cpu_mask file) or you might sometimes see unordered | ||
1375 | function calls while cpu tracing switch. | ||
1376 | |||
1377 | hide: echo nofuncgraph-cpu > /debug/tracing/trace_options | ||
1378 | show: echo funcgraph-cpu > /debug/tracing/trace_options | ||
1379 | |||
1380 | - The duration (function's time of execution) is displayed on | ||
1381 | the closing bracket line of a function or on the same line | ||
1382 | than the current function in case of a leaf one. It is default | ||
1383 | enabled. | ||
1384 | |||
1385 | hide: echo nofuncgraph-duration > /debug/tracing/trace_options | ||
1386 | show: echo funcgraph-duration > /debug/tracing/trace_options | ||
1387 | |||
1388 | - The overhead field precedes the duration field in case of | ||
1389 | reached duration thresholds. | ||
1390 | |||
1391 | hide: echo nofuncgraph-overhead > /debug/tracing/trace_options | ||
1392 | show: echo funcgraph-overhead > /debug/tracing/trace_options | ||
1393 | depends on: funcgraph-duration | ||
1394 | |||
1395 | ie: | ||
1396 | |||
1397 | 0) | up_write() { | ||
1398 | 0) 0.646 us | _spin_lock_irqsave(); | ||
1399 | 0) 0.684 us | _spin_unlock_irqrestore(); | ||
1400 | 0) 3.123 us | } | ||
1401 | 0) 0.548 us | fput(); | ||
1402 | 0) + 58.628 us | } | ||
1403 | |||
1404 | [...] | ||
1405 | |||
1406 | 0) | putname() { | ||
1407 | 0) | kmem_cache_free() { | ||
1408 | 0) 0.518 us | __phys_addr(); | ||
1409 | 0) 1.757 us | } | ||
1410 | 0) 2.861 us | } | ||
1411 | 0) ! 115.305 us | } | ||
1412 | 0) ! 116.402 us | } | ||
1413 | |||
1414 | + means that the function exceeded 10 usecs. | ||
1415 | ! means that the function exceeded 100 usecs. | ||
1416 | |||
1417 | |||
1418 | - The task/pid field displays the thread cmdline and pid which | ||
1419 | executed the function. It is default disabled. | ||
1420 | |||
1421 | hide: echo nofuncgraph-proc > /debug/tracing/trace_options | ||
1422 | show: echo funcgraph-proc > /debug/tracing/trace_options | ||
1423 | |||
1424 | ie: | ||
1425 | |||
1426 | # tracer: function_graph | ||
1427 | # | ||
1428 | # CPU TASK/PID DURATION FUNCTION CALLS | ||
1429 | # | | | | | | | | | | ||
1430 | 0) sh-4802 | | d_free() { | ||
1431 | 0) sh-4802 | | call_rcu() { | ||
1432 | 0) sh-4802 | | __call_rcu() { | ||
1433 | 0) sh-4802 | 0.616 us | rcu_process_gp_end(); | ||
1434 | 0) sh-4802 | 0.586 us | check_for_new_grace_period(); | ||
1435 | 0) sh-4802 | 2.899 us | } | ||
1436 | 0) sh-4802 | 4.040 us | } | ||
1437 | 0) sh-4802 | 5.151 us | } | ||
1438 | 0) sh-4802 | + 49.370 us | } | ||
1439 | |||
1440 | |||
1441 | - The absolute time field is an absolute timestamp given by the | ||
1442 | system clock since it started. A snapshot of this time is | ||
1443 | given on each entry/exit of functions | ||
1444 | |||
1445 | hide: echo nofuncgraph-abstime > /debug/tracing/trace_options | ||
1446 | show: echo funcgraph-abstime > /debug/tracing/trace_options | ||
1447 | |||
1448 | ie: | ||
1449 | |||
1450 | # | ||
1451 | # TIME CPU DURATION FUNCTION CALLS | ||
1452 | # | | | | | | | | | ||
1453 | 360.774522 | 1) 0.541 us | } | ||
1454 | 360.774522 | 1) 4.663 us | } | ||
1455 | 360.774523 | 1) 0.541 us | __wake_up_bit(); | ||
1456 | 360.774524 | 1) 6.796 us | } | ||
1457 | 360.774524 | 1) 7.952 us | } | ||
1458 | 360.774525 | 1) 9.063 us | } | ||
1459 | 360.774525 | 1) 0.615 us | journal_mark_dirty(); | ||
1460 | 360.774527 | 1) 0.578 us | __brelse(); | ||
1461 | 360.774528 | 1) | reiserfs_prepare_for_journal() { | ||
1462 | 360.774528 | 1) | unlock_buffer() { | ||
1463 | 360.774529 | 1) | wake_up_bit() { | ||
1464 | 360.774529 | 1) | bit_waitqueue() { | ||
1465 | 360.774530 | 1) 0.594 us | __phys_addr(); | ||
1466 | |||
1467 | |||
1468 | You can put some comments on specific functions by using | ||
1469 | trace_printk() For example, if you want to put a comment inside | ||
1470 | the __might_sleep() function, you just have to include | ||
1471 | <linux/ftrace.h> and call trace_printk() inside __might_sleep() | ||
1472 | |||
1473 | trace_printk("I'm a comment!\n") | ||
1474 | |||
1475 | will produce: | ||
1476 | |||
1477 | 1) | __might_sleep() { | ||
1478 | 1) | /* I'm a comment! */ | ||
1479 | 1) 1.449 us | } | ||
1480 | |||
1481 | |||
1482 | You might find other useful features for this tracer in the | ||
1483 | following "dynamic ftrace" section such as tracing only specific | ||
1484 | functions or tasks. | ||
1485 | |||
1155 | dynamic ftrace | 1486 | dynamic ftrace |
1156 | -------------- | 1487 | -------------- |
1157 | 1488 | ||
1158 | If CONFIG_DYNAMIC_FTRACE is set, the system will run with | 1489 | If CONFIG_DYNAMIC_FTRACE is set, the system will run with |
1159 | virtually no overhead when function tracing is disabled. The way | 1490 | virtually no overhead when function tracing is disabled. The way |
1160 | this works is the mcount function call (placed at the start of | 1491 | this works is the mcount function call (placed at the start of |
1161 | every kernel function, produced by the -pg switch in gcc), starts | 1492 | every kernel function, produced by the -pg switch in gcc), |
1162 | of pointing to a simple return. (Enabling FTRACE will include the | 1493 | starts of pointing to a simple return. (Enabling FTRACE will |
1163 | -pg switch in the compiling of the kernel.) | 1494 | include the -pg switch in the compiling of the kernel.) |
1164 | 1495 | ||
1165 | At compile time every C file object is run through the | 1496 | At compile time every C file object is run through the |
1166 | recordmcount.pl script (located in the scripts directory). This | 1497 | recordmcount.pl script (located in the scripts directory). This |
1167 | script will process the C object using objdump to find all the | 1498 | script will process the C object using objdump to find all the |
1168 | locations in the .text section that call mcount. (Note, only | 1499 | locations in the .text section that call mcount. (Note, only the |
1169 | the .text section is processed, since processing other sections | 1500 | .text section is processed, since processing other sections like |
1170 | like .init.text may cause races due to those sections being freed). | 1501 | .init.text may cause races due to those sections being freed). |
1171 | 1502 | ||
1172 | A new section called "__mcount_loc" is created that holds references | 1503 | A new section called "__mcount_loc" is created that holds |
1173 | to all the mcount call sites in the .text section. This section is | 1504 | references to all the mcount call sites in the .text section. |
1174 | compiled back into the original object. The final linker will add | 1505 | This section is compiled back into the original object. The |
1175 | all these references into a single table. | 1506 | final linker will add all these references into a single table. |
1176 | 1507 | ||
1177 | On boot up, before SMP is initialized, the dynamic ftrace code | 1508 | On boot up, before SMP is initialized, the dynamic ftrace code |
1178 | scans this table and updates all the locations into nops. It also | 1509 | scans this table and updates all the locations into nops. It |
1179 | records the locations, which are added to the available_filter_functions | 1510 | also records the locations, which are added to the |
1180 | list. Modules are processed as they are loaded and before they are | 1511 | available_filter_functions list. Modules are processed as they |
1181 | executed. When a module is unloaded, it also removes its functions from | 1512 | are loaded and before they are executed. When a module is |
1182 | the ftrace function list. This is automatic in the module unload | 1513 | unloaded, it also removes its functions from the ftrace function |
1183 | code, and the module author does not need to worry about it. | 1514 | list. This is automatic in the module unload code, and the |
1184 | 1515 | module author does not need to worry about it. | |
1185 | When tracing is enabled, kstop_machine is called to prevent races | 1516 | |
1186 | with the CPUS executing code being modified (which can cause the | 1517 | When tracing is enabled, kstop_machine is called to prevent |
1187 | CPU to do undesireable things), and the nops are patched back | 1518 | races with the CPUS executing code being modified (which can |
1188 | to calls. But this time, they do not call mcount (which is just | 1519 | cause the CPU to do undesireable things), and the nops are |
1189 | a function stub). They now call into the ftrace infrastructure. | 1520 | patched back to calls. But this time, they do not call mcount |
1521 | (which is just a function stub). They now call into the ftrace | ||
1522 | infrastructure. | ||
1190 | 1523 | ||
1191 | One special side-effect to the recording of the functions being | 1524 | One special side-effect to the recording of the functions being |
1192 | traced is that we can now selectively choose which functions we | 1525 | traced is that we can now selectively choose which functions we |
1193 | wish to trace and which ones we want the mcount calls to remain as | 1526 | wish to trace and which ones we want the mcount calls to remain |
1194 | nops. | 1527 | as nops. |
1195 | 1528 | ||
1196 | Two files are used, one for enabling and one for disabling the tracing | 1529 | Two files are used, one for enabling and one for disabling the |
1197 | of specified functions. They are: | 1530 | tracing of specified functions. They are: |
1198 | 1531 | ||
1199 | set_ftrace_filter | 1532 | set_ftrace_filter |
1200 | 1533 | ||
@@ -1202,8 +1535,8 @@ and | |||
1202 | 1535 | ||
1203 | set_ftrace_notrace | 1536 | set_ftrace_notrace |
1204 | 1537 | ||
1205 | A list of available functions that you can add to these files is listed | 1538 | A list of available functions that you can add to these files is |
1206 | in: | 1539 | listed in: |
1207 | 1540 | ||
1208 | available_filter_functions | 1541 | available_filter_functions |
1209 | 1542 | ||
@@ -1240,8 +1573,8 @@ hrtimer_interrupt | |||
1240 | sys_nanosleep | 1573 | sys_nanosleep |
1241 | 1574 | ||
1242 | 1575 | ||
1243 | Perhaps this is not enough. The filters also allow simple wild cards. | 1576 | Perhaps this is not enough. The filters also allow simple wild |
1244 | Only the following are currently available | 1577 | cards. Only the following are currently available |
1245 | 1578 | ||
1246 | <match>* - will match functions that begin with <match> | 1579 | <match>* - will match functions that begin with <match> |
1247 | *<match> - will match functions that end with <match> | 1580 | *<match> - will match functions that end with <match> |
@@ -1251,9 +1584,9 @@ These are the only wild cards which are supported. | |||
1251 | 1584 | ||
1252 | <match>*<match> will not work. | 1585 | <match>*<match> will not work. |
1253 | 1586 | ||
1254 | Note: It is better to use quotes to enclose the wild cards, otherwise | 1587 | Note: It is better to use quotes to enclose the wild cards, |
1255 | the shell may expand the parameters into names of files in the local | 1588 | otherwise the shell may expand the parameters into names |
1256 | directory. | 1589 | of files in the local directory. |
1257 | 1590 | ||
1258 | # echo 'hrtimer_*' > /debug/tracing/set_ftrace_filter | 1591 | # echo 'hrtimer_*' > /debug/tracing/set_ftrace_filter |
1259 | 1592 | ||
@@ -1299,7 +1632,8 @@ This is because the '>' and '>>' act just like they do in bash. | |||
1299 | To rewrite the filters, use '>' | 1632 | To rewrite the filters, use '>' |
1300 | To append to the filters, use '>>' | 1633 | To append to the filters, use '>>' |
1301 | 1634 | ||
1302 | To clear out a filter so that all functions will be recorded again: | 1635 | To clear out a filter so that all functions will be recorded |
1636 | again: | ||
1303 | 1637 | ||
1304 | # echo > /debug/tracing/set_ftrace_filter | 1638 | # echo > /debug/tracing/set_ftrace_filter |
1305 | # cat /debug/tracing/set_ftrace_filter | 1639 | # cat /debug/tracing/set_ftrace_filter |
@@ -1331,7 +1665,8 @@ hrtimer_get_res | |||
1331 | hrtimer_init_sleeper | 1665 | hrtimer_init_sleeper |
1332 | 1666 | ||
1333 | 1667 | ||
1334 | The set_ftrace_notrace prevents those functions from being traced. | 1668 | The set_ftrace_notrace prevents those functions from being |
1669 | traced. | ||
1335 | 1670 | ||
1336 | # echo '*preempt*' '*lock*' > /debug/tracing/set_ftrace_notrace | 1671 | # echo '*preempt*' '*lock*' > /debug/tracing/set_ftrace_notrace |
1337 | 1672 | ||
@@ -1353,13 +1688,75 @@ Produces: | |||
1353 | 1688 | ||
1354 | We can see that there's no more lock or preempt tracing. | 1689 | We can see that there's no more lock or preempt tracing. |
1355 | 1690 | ||
1691 | |||
1692 | Dynamic ftrace with the function graph tracer | ||
1693 | --------------------------------------------- | ||
1694 | |||
1695 | Although what has been explained above concerns both the | ||
1696 | function tracer and the function-graph-tracer, there are some | ||
1697 | special features only available in the function-graph tracer. | ||
1698 | |||
1699 | If you want to trace only one function and all of its children, | ||
1700 | you just have to echo its name into set_graph_function: | ||
1701 | |||
1702 | echo __do_fault > set_graph_function | ||
1703 | |||
1704 | will produce the following "expanded" trace of the __do_fault() | ||
1705 | function: | ||
1706 | |||
1707 | 0) | __do_fault() { | ||
1708 | 0) | filemap_fault() { | ||
1709 | 0) | find_lock_page() { | ||
1710 | 0) 0.804 us | find_get_page(); | ||
1711 | 0) | __might_sleep() { | ||
1712 | 0) 1.329 us | } | ||
1713 | 0) 3.904 us | } | ||
1714 | 0) 4.979 us | } | ||
1715 | 0) 0.653 us | _spin_lock(); | ||
1716 | 0) 0.578 us | page_add_file_rmap(); | ||
1717 | 0) 0.525 us | native_set_pte_at(); | ||
1718 | 0) 0.585 us | _spin_unlock(); | ||
1719 | 0) | unlock_page() { | ||
1720 | 0) 0.541 us | page_waitqueue(); | ||
1721 | 0) 0.639 us | __wake_up_bit(); | ||
1722 | 0) 2.786 us | } | ||
1723 | 0) + 14.237 us | } | ||
1724 | 0) | __do_fault() { | ||
1725 | 0) | filemap_fault() { | ||
1726 | 0) | find_lock_page() { | ||
1727 | 0) 0.698 us | find_get_page(); | ||
1728 | 0) | __might_sleep() { | ||
1729 | 0) 1.412 us | } | ||
1730 | 0) 3.950 us | } | ||
1731 | 0) 5.098 us | } | ||
1732 | 0) 0.631 us | _spin_lock(); | ||
1733 | 0) 0.571 us | page_add_file_rmap(); | ||
1734 | 0) 0.526 us | native_set_pte_at(); | ||
1735 | 0) 0.586 us | _spin_unlock(); | ||
1736 | 0) | unlock_page() { | ||
1737 | 0) 0.533 us | page_waitqueue(); | ||
1738 | 0) 0.638 us | __wake_up_bit(); | ||
1739 | 0) 2.793 us | } | ||
1740 | 0) + 14.012 us | } | ||
1741 | |||
1742 | You can also expand several functions at once: | ||
1743 | |||
1744 | echo sys_open > set_graph_function | ||
1745 | echo sys_close >> set_graph_function | ||
1746 | |||
1747 | Now if you want to go back to trace all functions you can clear | ||
1748 | this special filter via: | ||
1749 | |||
1750 | echo > set_graph_function | ||
1751 | |||
1752 | |||
1356 | trace_pipe | 1753 | trace_pipe |
1357 | ---------- | 1754 | ---------- |
1358 | 1755 | ||
1359 | The trace_pipe outputs the same content as the trace file, but the effect | 1756 | The trace_pipe outputs the same content as the trace file, but |
1360 | on the tracing is different. Every read from trace_pipe is consumed. | 1757 | the effect on the tracing is different. Every read from |
1361 | This means that subsequent reads will be different. The trace | 1758 | trace_pipe is consumed. This means that subsequent reads will be |
1362 | is live. | 1759 | different. The trace is live. |
1363 | 1760 | ||
1364 | # echo function > /debug/tracing/current_tracer | 1761 | # echo function > /debug/tracing/current_tracer |
1365 | # cat /debug/tracing/trace_pipe > /tmp/trace.out & | 1762 | # cat /debug/tracing/trace_pipe > /tmp/trace.out & |
@@ -1387,38 +1784,45 @@ is live. | |||
1387 | bash-4043 [00] 41.267111: select_task_rq_rt <-try_to_wake_up | 1784 | bash-4043 [00] 41.267111: select_task_rq_rt <-try_to_wake_up |
1388 | 1785 | ||
1389 | 1786 | ||
1390 | Note, reading the trace_pipe file will block until more input is added. | 1787 | Note, reading the trace_pipe file will block until more input is |
1391 | By changing the tracer, trace_pipe will issue an EOF. We needed | 1788 | added. By changing the tracer, trace_pipe will issue an EOF. We |
1392 | to set the function tracer _before_ we "cat" the trace_pipe file. | 1789 | needed to set the function tracer _before_ we "cat" the |
1790 | trace_pipe file. | ||
1393 | 1791 | ||
1394 | 1792 | ||
1395 | trace entries | 1793 | trace entries |
1396 | ------------- | 1794 | ------------- |
1397 | 1795 | ||
1398 | Having too much or not enough data can be troublesome in diagnosing | 1796 | Having too much or not enough data can be troublesome in |
1399 | an issue in the kernel. The file buffer_size_kb is used to modify | 1797 | diagnosing an issue in the kernel. The file buffer_size_kb is |
1400 | the size of the internal trace buffers. The number listed | 1798 | used to modify the size of the internal trace buffers. The |
1401 | is the number of entries that can be recorded per CPU. To know | 1799 | number listed is the number of entries that can be recorded per |
1402 | the full size, multiply the number of possible CPUS with the | 1800 | CPU. To know the full size, multiply the number of possible CPUS |
1403 | number of entries. | 1801 | with the number of entries. |
1404 | 1802 | ||
1405 | # cat /debug/tracing/buffer_size_kb | 1803 | # cat /debug/tracing/buffer_size_kb |
1406 | 1408 (units kilobytes) | 1804 | 1408 (units kilobytes) |
1407 | 1805 | ||
1408 | Note, to modify this, you must have tracing completely disabled. To do that, | 1806 | Note, to modify this, you must have tracing completely disabled. |
1409 | echo "nop" into the current_tracer. If the current_tracer is not set | 1807 | To do that, echo "nop" into the current_tracer. If the |
1410 | to "nop", an EINVAL error will be returned. | 1808 | current_tracer is not set to "nop", an EINVAL error will be |
1809 | returned. | ||
1411 | 1810 | ||
1412 | # echo nop > /debug/tracing/current_tracer | 1811 | # echo nop > /debug/tracing/current_tracer |
1413 | # echo 10000 > /debug/tracing/buffer_size_kb | 1812 | # echo 10000 > /debug/tracing/buffer_size_kb |
1414 | # cat /debug/tracing/buffer_size_kb | 1813 | # cat /debug/tracing/buffer_size_kb |
1415 | 10000 (units kilobytes) | 1814 | 10000 (units kilobytes) |
1416 | 1815 | ||
1417 | The number of pages which will be allocated is limited to a percentage | 1816 | The number of pages which will be allocated is limited to a |
1418 | of available memory. Allocating too much will produce an error. | 1817 | percentage of available memory. Allocating too much will produce |
1818 | an error. | ||
1419 | 1819 | ||
1420 | # echo 1000000000000 > /debug/tracing/buffer_size_kb | 1820 | # echo 1000000000000 > /debug/tracing/buffer_size_kb |
1421 | -bash: echo: write error: Cannot allocate memory | 1821 | -bash: echo: write error: Cannot allocate memory |
1422 | # cat /debug/tracing/buffer_size_kb | 1822 | # cat /debug/tracing/buffer_size_kb |
1423 | 85 | 1823 | 85 |
1424 | 1824 | ||
1825 | ----------- | ||
1826 | |||
1827 | More details can be found in the source code, in the | ||
1828 | kernel/tracing/*.c files. | ||
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index b1b988701247..145c25a170c7 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt | |||
@@ -123,7 +123,10 @@ platform-specific implementation issue. | |||
123 | 123 | ||
124 | Using GPIOs | 124 | Using GPIOs |
125 | ----------- | 125 | ----------- |
126 | One of the first things to do with a GPIO, often in board setup code when | 126 | The first thing a system should do with a GPIO is allocate it, using |
127 | the gpio_request() call; see later. | ||
128 | |||
129 | One of the next things to do with a GPIO, often in board setup code when | ||
127 | setting up a platform_device using the GPIO, is mark its direction: | 130 | setting up a platform_device using the GPIO, is mark its direction: |
128 | 131 | ||
129 | /* set as input or output, returning 0 or negative errno */ | 132 | /* set as input or output, returning 0 or negative errno */ |
@@ -141,8 +144,8 @@ This helps avoid signal glitching during system startup. | |||
141 | 144 | ||
142 | For compatibility with legacy interfaces to GPIOs, setting the direction | 145 | For compatibility with legacy interfaces to GPIOs, setting the direction |
143 | of a GPIO implicitly requests that GPIO (see below) if it has not been | 146 | of a GPIO implicitly requests that GPIO (see below) if it has not been |
144 | requested already. That compatibility may be removed in the future; | 147 | requested already. That compatibility is being removed from the optional |
145 | explicitly requesting GPIOs is strongly preferred. | 148 | gpiolib framework. |
146 | 149 | ||
147 | Setting the direction can fail if the GPIO number is invalid, or when | 150 | Setting the direction can fail if the GPIO number is invalid, or when |
148 | that particular GPIO can't be used in that mode. It's generally a bad | 151 | that particular GPIO can't be used in that mode. It's generally a bad |
@@ -195,7 +198,7 @@ This requires sleeping, which can't be done from inside IRQ handlers. | |||
195 | 198 | ||
196 | Platforms that support this type of GPIO distinguish them from other GPIOs | 199 | Platforms that support this type of GPIO distinguish them from other GPIOs |
197 | by returning nonzero from this call (which requires a valid GPIO number, | 200 | by returning nonzero from this call (which requires a valid GPIO number, |
198 | either explicitly or implicitly requested): | 201 | which should have been previously allocated with gpio_request): |
199 | 202 | ||
200 | int gpio_cansleep(unsigned gpio); | 203 | int gpio_cansleep(unsigned gpio); |
201 | 204 | ||
@@ -212,10 +215,9 @@ for GPIOs that can't be accessed from IRQ handlers, these calls act the | |||
212 | same as the spinlock-safe calls. | 215 | same as the spinlock-safe calls. |
213 | 216 | ||
214 | 217 | ||
215 | Claiming and Releasing GPIOs (OPTIONAL) | 218 | Claiming and Releasing GPIOs |
216 | --------------------------------------- | 219 | ---------------------------- |
217 | To help catch system configuration errors, two calls are defined. | 220 | To help catch system configuration errors, two calls are defined. |
218 | However, many platforms don't currently support this mechanism. | ||
219 | 221 | ||
220 | /* request GPIO, returning 0 or negative errno. | 222 | /* request GPIO, returning 0 or negative errno. |
221 | * non-null labels may be useful for diagnostics. | 223 | * non-null labels may be useful for diagnostics. |
@@ -244,13 +246,6 @@ Some platforms may also use knowledge about what GPIOs are active for | |||
244 | power management, such as by powering down unused chip sectors and, more | 246 | power management, such as by powering down unused chip sectors and, more |
245 | easily, gating off unused clocks. | 247 | easily, gating off unused clocks. |
246 | 248 | ||
247 | These two calls are optional because not not all current Linux platforms | ||
248 | offer such functionality in their GPIO support; a valid implementation | ||
249 | could return success for all gpio_request() calls. Unlike the other calls, | ||
250 | the state they represent doesn't normally match anything from a hardware | ||
251 | register; it's just a software bitmap which clearly is not necessary for | ||
252 | correct operation of hardware or (bug free) drivers. | ||
253 | |||
254 | Note that requesting a GPIO does NOT cause it to be configured in any | 249 | Note that requesting a GPIO does NOT cause it to be configured in any |
255 | way; it just marks that GPIO as in use. Separate code must handle any | 250 | way; it just marks that GPIO as in use. Separate code must handle any |
256 | pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown). | 251 | pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown). |
diff --git a/Documentation/hwmon/ds1621 b/Documentation/hwmon/ds1621 index 1fee6f1e6bc5..5e97f333c4df 100644 --- a/Documentation/hwmon/ds1621 +++ b/Documentation/hwmon/ds1621 | |||
@@ -49,12 +49,9 @@ of up to +/- 0.5 degrees even when compared against precise temperature | |||
49 | readings. Be sure to have a high vs. low temperature limit gap of al least | 49 | readings. Be sure to have a high vs. low temperature limit gap of al least |
50 | 1.0 degree Celsius to avoid Tout "bouncing", though! | 50 | 1.0 degree Celsius to avoid Tout "bouncing", though! |
51 | 51 | ||
52 | As for alarms, you can read the alarm status of the DS1621 via the 'alarms' | 52 | The alarm bits are set when the high or low limits are met or exceeded and |
53 | /sys file interface. The result consists mainly of bit 6 and 5 of the | 53 | are reset by the module as soon as the respective temperature ranges are |
54 | configuration register of the chip; bit 6 (0x40 or 64) is the high alarm | 54 | left. |
55 | bit and bit 5 (0x20 or 32) the low one. These bits are set when the high or | ||
56 | low limits are met or exceeded and are reset by the module as soon as the | ||
57 | respective temperature ranges are left. | ||
58 | 55 | ||
59 | The alarm registers are in no way suitable to find out about the actual | 56 | The alarm registers are in no way suitable to find out about the actual |
60 | status of Tout. They will only tell you about its history, whether or not | 57 | status of Tout. They will only tell you about its history, whether or not |
@@ -64,45 +61,3 @@ with neither of the alarms set. | |||
64 | 61 | ||
65 | Temperature conversion of the DS1621 takes up to 1000ms; internal access to | 62 | Temperature conversion of the DS1621 takes up to 1000ms; internal access to |
66 | non-volatile registers may last for 10ms or below. | 63 | non-volatile registers may last for 10ms or below. |
67 | |||
68 | High Accuracy Temperature Reading | ||
69 | --------------------------------- | ||
70 | |||
71 | As said before, the temperature issued via the 9-bit i2c-bus data is | ||
72 | somewhat arbitrary. Internally, the temperature conversion is of a | ||
73 | different kind that is explained (not so...) well in the DS1621 data sheet. | ||
74 | To cut the long story short: Inside the DS1621 there are two oscillators, | ||
75 | both of them biassed by a temperature coefficient. | ||
76 | |||
77 | Higher resolution of the temperature reading can be achieved using the | ||
78 | internal projection, which means taking account of REG_COUNT and REG_SLOPE | ||
79 | (the driver manages them): | ||
80 | |||
81 | Taken from Dallas Semiconductors App Note 068: 'Increasing Temperature | ||
82 | Resolution on the DS1620' and App Note 105: 'High Resolution Temperature | ||
83 | Measurement with Dallas Direct-to-Digital Temperature Sensors' | ||
84 | |||
85 | - Read the 9-bit temperature and strip the LSB (Truncate the .5 degs) | ||
86 | - The resulting value is TEMP_READ. | ||
87 | - Then, read REG_COUNT. | ||
88 | - And then, REG_SLOPE. | ||
89 | |||
90 | TEMP = TEMP_READ - 0.25 + ((REG_SLOPE - REG_COUNT) / REG_SLOPE) | ||
91 | |||
92 | Note that this is what the DONE bit in the DS1621 configuration register is | ||
93 | good for: Internally, one temperature conversion takes up to 1000ms. Before | ||
94 | that conversion is complete you will not be able to read valid things out | ||
95 | of REG_COUNT and REG_SLOPE. The DONE bit, as you may have guessed by now, | ||
96 | tells you whether the conversion is complete ("done", in plain English) and | ||
97 | thus, whether the values you read are good or not. | ||
98 | |||
99 | The DS1621 has two modes of operation: "Continuous" conversion, which can | ||
100 | be understood as the default stand-alone mode where the chip gets the | ||
101 | temperature and controls external devices via its Tout pin or tells other | ||
102 | i2c's about it if they care. The other mode is called "1SHOT", that means | ||
103 | that it only figures out about the temperature when it is explicitly told | ||
104 | to do so; this can be seen as power saving mode. | ||
105 | |||
106 | Now if you want to read REG_COUNT and REG_SLOPE, you have to either stop | ||
107 | the continuous conversions until the contents of these registers are valid, | ||
108 | or, in 1SHOT mode, you have to have one conversion made. | ||
diff --git a/Documentation/hwmon/g760a b/Documentation/hwmon/g760a new file mode 100644 index 000000000000..e032eeb75629 --- /dev/null +++ b/Documentation/hwmon/g760a | |||
@@ -0,0 +1,36 @@ | |||
1 | Kernel driver g760a | ||
2 | =================== | ||
3 | |||
4 | Supported chips: | ||
5 | * Global Mixed-mode Technology Inc. G760A | ||
6 | Prefix: 'g760a' | ||
7 | Datasheet: Publicly available at the GMT website | ||
8 | http://www.gmt.com.tw/datasheet/g760a.pdf | ||
9 | |||
10 | Author: Herbert Valerio Riedel <hvr@gnu.org> | ||
11 | |||
12 | Description | ||
13 | ----------- | ||
14 | |||
15 | The GMT G760A Fan Speed PWM Controller is connected directly to a fan | ||
16 | and performs closed-loop control of the fan speed. | ||
17 | |||
18 | The fan speed is programmed by setting the period via 'pwm1' of two | ||
19 | consecutive speed pulses. The period is defined in terms of clock | ||
20 | cycle counts of an assumed 32kHz clock source. | ||
21 | |||
22 | Setting a period of 0 stops the fan; setting the period to 255 sets | ||
23 | fan to maximum speed. | ||
24 | |||
25 | The measured fan rotation speed returned via 'fan1_input' is derived | ||
26 | from the measured speed pulse period by assuming again a 32kHz clock | ||
27 | source and a 2 pulse-per-revolution fan. | ||
28 | |||
29 | The 'alarms' file provides access to the two alarm bits provided by | ||
30 | the G760A chip's status register: Bit 0 is set when the actual fan | ||
31 | speed differs more than 20% with respect to the programmed fan speed; | ||
32 | bit 1 is set when fan speed is below 1920 RPM. | ||
33 | |||
34 | The g760a driver will not update its values more frequently than every | ||
35 | other second; reading them more often will do no harm, but will return | ||
36 | 'old' values. | ||
diff --git a/Documentation/hwmon/hpfall.c b/Documentation/hwmon/hpfall.c new file mode 100644 index 000000000000..bbea1ccfd46a --- /dev/null +++ b/Documentation/hwmon/hpfall.c | |||
@@ -0,0 +1,101 @@ | |||
1 | /* Disk protection for HP machines. | ||
2 | * | ||
3 | * Copyright 2008 Eric Piel | ||
4 | * Copyright 2009 Pavel Machek <pavel@suse.cz> | ||
5 | * | ||
6 | * GPLv2. | ||
7 | */ | ||
8 | |||
9 | #include <stdio.h> | ||
10 | #include <stdlib.h> | ||
11 | #include <unistd.h> | ||
12 | #include <fcntl.h> | ||
13 | #include <sys/stat.h> | ||
14 | #include <sys/types.h> | ||
15 | #include <string.h> | ||
16 | #include <stdint.h> | ||
17 | #include <errno.h> | ||
18 | #include <signal.h> | ||
19 | |||
20 | void write_int(char *path, int i) | ||
21 | { | ||
22 | char buf[1024]; | ||
23 | int fd = open(path, O_RDWR); | ||
24 | if (fd < 0) { | ||
25 | perror("open"); | ||
26 | exit(1); | ||
27 | } | ||
28 | sprintf(buf, "%d", i); | ||
29 | if (write(fd, buf, strlen(buf)) != strlen(buf)) { | ||
30 | perror("write"); | ||
31 | exit(1); | ||
32 | } | ||
33 | close(fd); | ||
34 | } | ||
35 | |||
36 | void set_led(int on) | ||
37 | { | ||
38 | write_int("/sys/class/leds/hp::hddprotect/brightness", on); | ||
39 | } | ||
40 | |||
41 | void protect(int seconds) | ||
42 | { | ||
43 | write_int("/sys/block/sda/device/unload_heads", seconds*1000); | ||
44 | } | ||
45 | |||
46 | int on_ac(void) | ||
47 | { | ||
48 | // /sys/class/power_supply/AC0/online | ||
49 | } | ||
50 | |||
51 | int lid_open(void) | ||
52 | { | ||
53 | // /proc/acpi/button/lid/LID/state | ||
54 | } | ||
55 | |||
56 | void ignore_me(void) | ||
57 | { | ||
58 | protect(0); | ||
59 | set_led(0); | ||
60 | |||
61 | } | ||
62 | |||
63 | int main(int argc, char* argv[]) | ||
64 | { | ||
65 | int fd, ret; | ||
66 | |||
67 | fd = open("/dev/freefall", O_RDONLY); | ||
68 | if (fd < 0) { | ||
69 | perror("open"); | ||
70 | return EXIT_FAILURE; | ||
71 | } | ||
72 | |||
73 | signal(SIGALRM, ignore_me); | ||
74 | |||
75 | for (;;) { | ||
76 | unsigned char count; | ||
77 | |||
78 | ret = read(fd, &count, sizeof(count)); | ||
79 | alarm(0); | ||
80 | if ((ret == -1) && (errno == EINTR)) { | ||
81 | /* Alarm expired, time to unpark the heads */ | ||
82 | continue; | ||
83 | } | ||
84 | |||
85 | if (ret != sizeof(count)) { | ||
86 | perror("read"); | ||
87 | break; | ||
88 | } | ||
89 | |||
90 | protect(21); | ||
91 | set_led(1); | ||
92 | if (1 || on_ac() || lid_open()) { | ||
93 | alarm(2); | ||
94 | } else { | ||
95 | alarm(20); | ||
96 | } | ||
97 | } | ||
98 | |||
99 | close(fd); | ||
100 | return EXIT_SUCCESS; | ||
101 | } | ||
diff --git a/Documentation/hwmon/lis3lv02d b/Documentation/hwmon/lis3lv02d index 0fcfc4a7ccdc..effe949a7282 100644 --- a/Documentation/hwmon/lis3lv02d +++ b/Documentation/hwmon/lis3lv02d | |||
@@ -1,11 +1,11 @@ | |||
1 | Kernel driver lis3lv02d | 1 | Kernel driver lis3lv02d |
2 | ================== | 2 | ======================= |
3 | 3 | ||
4 | Supported chips: | 4 | Supported chips: |
5 | 5 | ||
6 | * STMicroelectronics LIS3LV02DL and LIS3LV02DQ | 6 | * STMicroelectronics LIS3LV02DL and LIS3LV02DQ |
7 | 7 | ||
8 | Author: | 8 | Authors: |
9 | Yan Burman <burman.yan@gmail.com> | 9 | Yan Burman <burman.yan@gmail.com> |
10 | Eric Piel <eric.piel@tremplin-utc.net> | 10 | Eric Piel <eric.piel@tremplin-utc.net> |
11 | 11 | ||
@@ -15,7 +15,7 @@ Description | |||
15 | 15 | ||
16 | This driver provides support for the accelerometer found in various HP | 16 | This driver provides support for the accelerometer found in various HP |
17 | laptops sporting the feature officially called "HP Mobile Data | 17 | laptops sporting the feature officially called "HP Mobile Data |
18 | Protection System 3D" or "HP 3D DriveGuard". It detect automatically | 18 | Protection System 3D" or "HP 3D DriveGuard". It detects automatically |
19 | laptops with this sensor. Known models (for now the HP 2133, nc6420, | 19 | laptops with this sensor. Known models (for now the HP 2133, nc6420, |
20 | nc2510, nc8510, nc84x0, nw9440 and nx9420) will have their axis | 20 | nc2510, nc8510, nc84x0, nw9440 and nx9420) will have their axis |
21 | automatically oriented on standard way (eg: you can directly play | 21 | automatically oriented on standard way (eg: you can directly play |
@@ -27,12 +27,20 @@ position - 3D position that the accelerometer reports. Format: "(x,y,z)" | |||
27 | calibrate - read: values (x, y, z) that are used as the base for input | 27 | calibrate - read: values (x, y, z) that are used as the base for input |
28 | class device operation. | 28 | class device operation. |
29 | write: forces the base to be recalibrated with the current | 29 | write: forces the base to be recalibrated with the current |
30 | position. | 30 | position. |
31 | rate - reports the sampling rate of the accelerometer device in HZ | 31 | rate - reports the sampling rate of the accelerometer device in HZ |
32 | 32 | ||
33 | This driver also provides an absolute input class device, allowing | 33 | This driver also provides an absolute input class device, allowing |
34 | the laptop to act as a pinball machine-esque joystick. | 34 | the laptop to act as a pinball machine-esque joystick. |
35 | 35 | ||
36 | Another feature of the driver is misc device called "freefall" that | ||
37 | acts similar to /dev/rtc and reacts on free-fall interrupts received | ||
38 | from the device. It supports blocking operations, poll/select and | ||
39 | fasync operation modes. You must read 1 bytes from the device. The | ||
40 | result is number of free-fall interrupts since the last successful | ||
41 | read (or 255 if number of interrupts would not fit). | ||
42 | |||
43 | |||
36 | Axes orientation | 44 | Axes orientation |
37 | ---------------- | 45 | ---------------- |
38 | 46 | ||
@@ -40,7 +48,7 @@ For better compatibility between the various laptops. The values reported by | |||
40 | the accelerometer are converted into a "standard" organisation of the axes | 48 | the accelerometer are converted into a "standard" organisation of the axes |
41 | (aka "can play neverball out of the box"): | 49 | (aka "can play neverball out of the box"): |
42 | * When the laptop is horizontal the position reported is about 0 for X and Y | 50 | * When the laptop is horizontal the position reported is about 0 for X and Y |
43 | and a positive value for Z | 51 | and a positive value for Z |
44 | * If the left side is elevated, X increases (becomes positive) | 52 | * If the left side is elevated, X increases (becomes positive) |
45 | * If the front side (where the touchpad is) is elevated, Y decreases | 53 | * If the front side (where the touchpad is) is elevated, Y decreases |
46 | (becomes negative) | 54 | (becomes negative) |
@@ -51,3 +59,13 @@ email to the authors to add it to the database. When reporting a new | |||
51 | laptop, please include the output of "dmidecode" plus the value of | 59 | laptop, please include the output of "dmidecode" plus the value of |
52 | /sys/devices/platform/lis3lv02d/position in these four cases. | 60 | /sys/devices/platform/lis3lv02d/position in these four cases. |
53 | 61 | ||
62 | Q&A | ||
63 | --- | ||
64 | |||
65 | Q: How do I safely simulate freefall? I have an HP "portable | ||
66 | workstation" which has about 3.5kg and a plastic case, so letting it | ||
67 | fall to the ground is out of question... | ||
68 | |||
69 | A: The sensor is pretty sensitive, so your hands can do it. Lift it | ||
70 | into free space, follow the fall with your hands for like 10 | ||
71 | centimeters. That should be enough to trigger the detection. | ||
diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90 index 0e8411710238..93d8e3d55150 100644 --- a/Documentation/hwmon/lm90 +++ b/Documentation/hwmon/lm90 | |||
@@ -42,6 +42,11 @@ Supported chips: | |||
42 | Addresses scanned: I2C 0x4e | 42 | Addresses scanned: I2C 0x4e |
43 | Datasheet: Publicly available at the Maxim website | 43 | Datasheet: Publicly available at the Maxim website |
44 | http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3497 | 44 | http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3497 |
45 | * Maxim MAX6648 | ||
46 | Prefix: 'max6646' | ||
47 | Addresses scanned: I2C 0x4c | ||
48 | Datasheet: Publicly available at the Maxim website | ||
49 | http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500 | ||
45 | * Maxim MAX6649 | 50 | * Maxim MAX6649 |
46 | Prefix: 'max6646' | 51 | Prefix: 'max6646' |
47 | Addresses scanned: I2C 0x4c | 52 | Addresses scanned: I2C 0x4c |
@@ -74,6 +79,11 @@ Supported chips: | |||
74 | 0x4c, 0x4d and 0x4e | 79 | 0x4c, 0x4d and 0x4e |
75 | Datasheet: Publicly available at the Maxim website | 80 | Datasheet: Publicly available at the Maxim website |
76 | http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3370 | 81 | http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3370 |
82 | * Maxim MAX6692 | ||
83 | Prefix: 'max6646' | ||
84 | Addresses scanned: I2C 0x4c | ||
85 | Datasheet: Publicly available at the Maxim website | ||
86 | http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500 | ||
77 | 87 | ||
78 | 88 | ||
79 | Author: Jean Delvare <khali@linux-fr.org> | 89 | Author: Jean Delvare <khali@linux-fr.org> |
diff --git a/Documentation/hwmon/ltc4215 b/Documentation/hwmon/ltc4215 new file mode 100644 index 000000000000..2e6a21eb656c --- /dev/null +++ b/Documentation/hwmon/ltc4215 | |||
@@ -0,0 +1,50 @@ | |||
1 | Kernel driver ltc4215 | ||
2 | ===================== | ||
3 | |||
4 | Supported chips: | ||
5 | * Linear Technology LTC4215 | ||
6 | Prefix: 'ltc4215' | ||
7 | Addresses scanned: 0x44 | ||
8 | Datasheet: | ||
9 | http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1006,C1163,P17572,D12697 | ||
10 | |||
11 | Author: Ira W. Snyder <iws@ovro.caltech.edu> | ||
12 | |||
13 | |||
14 | Description | ||
15 | ----------- | ||
16 | |||
17 | The LTC4215 controller allows a board to be safely inserted and removed | ||
18 | from a live backplane. | ||
19 | |||
20 | |||
21 | Usage Notes | ||
22 | ----------- | ||
23 | |||
24 | This driver does not probe for LTC4215 devices, due to the fact that some | ||
25 | of the possible addresses are unfriendly to probing. You will need to use | ||
26 | the "force" parameter to tell the driver where to find the device. | ||
27 | |||
28 | Example: the following will load the driver for an LTC4215 at address 0x44 | ||
29 | on I2C bus #0: | ||
30 | $ modprobe ltc4215 force=0,0x44 | ||
31 | |||
32 | |||
33 | Sysfs entries | ||
34 | ------------- | ||
35 | |||
36 | The LTC4215 has built-in limits for overvoltage, undervoltage, and | ||
37 | undercurrent warnings. This makes it very likely that the reference | ||
38 | circuit will be used. | ||
39 | |||
40 | in1_input input voltage | ||
41 | in2_input output voltage | ||
42 | |||
43 | in1_min_alarm input undervoltage alarm | ||
44 | in1_max_alarm input overvoltage alarm | ||
45 | |||
46 | curr1_input current | ||
47 | curr1_max_alarm overcurrent alarm | ||
48 | |||
49 | power1_input power usage | ||
50 | power1_alarm power bad alarm | ||
diff --git a/Documentation/i2c/chips/pcf8591 b/Documentation/hwmon/pcf8591 index 5628fcf4207f..5628fcf4207f 100644 --- a/Documentation/i2c/chips/pcf8591 +++ b/Documentation/hwmon/pcf8591 | |||
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index 6dbfd5efd991..2f10ce6a879f 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface | |||
@@ -365,6 +365,7 @@ energy[1-*]_input Cumulative energy use | |||
365 | Unit: microJoule | 365 | Unit: microJoule |
366 | RO | 366 | RO |
367 | 367 | ||
368 | |||
368 | ********** | 369 | ********** |
369 | * Alarms * | 370 | * Alarms * |
370 | ********** | 371 | ********** |
@@ -453,6 +454,27 @@ beep_mask Bitmask for beep. | |||
453 | RW | 454 | RW |
454 | 455 | ||
455 | 456 | ||
457 | *********************** | ||
458 | * Intrusion detection * | ||
459 | *********************** | ||
460 | |||
461 | intrusion[0-*]_alarm | ||
462 | Chassis intrusion detection | ||
463 | 0: OK | ||
464 | 1: intrusion detected | ||
465 | RW | ||
466 | Contrary to regular alarm flags which clear themselves | ||
467 | automatically when read, this one sticks until cleared by | ||
468 | the user. This is done by writing 0 to the file. Writing | ||
469 | other values is unsupported. | ||
470 | |||
471 | intrusion[0-*]_beep | ||
472 | Chassis intrusion beep | ||
473 | 0: disable | ||
474 | 1: enable | ||
475 | RW | ||
476 | |||
477 | |||
456 | sysfs attribute writes interpretation | 478 | sysfs attribute writes interpretation |
457 | ------------------------------------- | 479 | ------------------------------------- |
458 | 480 | ||
diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf index d6e1ae30fa6e..b6eb59384bb3 100644 --- a/Documentation/hwmon/w83627ehf +++ b/Documentation/hwmon/w83627ehf | |||
@@ -2,30 +2,40 @@ Kernel driver w83627ehf | |||
2 | ======================= | 2 | ======================= |
3 | 3 | ||
4 | Supported chips: | 4 | Supported chips: |
5 | * Winbond W83627EHF/EHG/DHG (ISA access ONLY) | 5 | * Winbond W83627EHF/EHG (ISA access ONLY) |
6 | Prefix: 'w83627ehf' | 6 | Prefix: 'w83627ehf' |
7 | Addresses scanned: ISA address retrieved from Super I/O registers | 7 | Addresses scanned: ISA address retrieved from Super I/O registers |
8 | Datasheet: | 8 | Datasheet: |
9 | http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83627EHF_%20W83627EHGb.pdf | 9 | http://www.nuvoton.com.tw/NR/rdonlyres/A6A258F0-F0C9-4F97-81C0-C4D29E7E943E/0/W83627EHF.pdf |
10 | DHG datasheet confidential. | 10 | * Winbond W83627DHG |
11 | Prefix: 'w83627dhg' | ||
12 | Addresses scanned: ISA address retrieved from Super I/O registers | ||
13 | Datasheet: | ||
14 | http://www.nuvoton.com.tw/NR/rdonlyres/7885623D-A487-4CF9-A47F-30C5F73D6FE6/0/W83627DHG.pdf | ||
15 | * Winbond W83667HG | ||
16 | Prefix: 'w83667hg' | ||
17 | Addresses scanned: ISA address retrieved from Super I/O registers | ||
18 | Datasheet: not available | ||
11 | 19 | ||
12 | Authors: | 20 | Authors: |
13 | Jean Delvare <khali@linux-fr.org> | 21 | Jean Delvare <khali@linux-fr.org> |
14 | Yuan Mu (Winbond) | 22 | Yuan Mu (Winbond) |
15 | Rudolf Marek <r.marek@assembler.cz> | 23 | Rudolf Marek <r.marek@assembler.cz> |
16 | David Hubbard <david.c.hubbard@gmail.com> | 24 | David Hubbard <david.c.hubbard@gmail.com> |
25 | Gong Jun <JGong@nuvoton.com> | ||
17 | 26 | ||
18 | Description | 27 | Description |
19 | ----------- | 28 | ----------- |
20 | 29 | ||
21 | This driver implements support for the Winbond W83627EHF, W83627EHG, and | 30 | This driver implements support for the Winbond W83627EHF, W83627EHG, |
22 | W83627DHG super I/O chips. We will refer to them collectively as Winbond chips. | 31 | W83627DHG and W83667HG super I/O chips. We will refer to them collectively |
32 | as Winbond chips. | ||
23 | 33 | ||
24 | The chips implement three temperature sensors, five fan rotation | 34 | The chips implement three temperature sensors, five fan rotation |
25 | speed sensors, ten analog voltage sensors (only nine for the 627DHG), one | 35 | speed sensors, ten analog voltage sensors (only nine for the 627DHG), one |
26 | VID (6 pins for the 627EHF/EHG, 8 pins for the 627DHG), alarms with beep | 36 | VID (6 pins for the 627EHF/EHG, 8 pins for the 627DHG and 667HG), alarms |
27 | warnings (control unimplemented), and some automatic fan regulation | 37 | with beep warnings (control unimplemented), and some automatic fan |
28 | strategies (plus manual fan control mode). | 38 | regulation strategies (plus manual fan control mode). |
29 | 39 | ||
30 | Temperatures are measured in degrees Celsius and measurement resolution is 1 | 40 | Temperatures are measured in degrees Celsius and measurement resolution is 1 |
31 | degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when | 41 | degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when |
@@ -54,7 +64,8 @@ follows: | |||
54 | temp1 -> pwm1 | 64 | temp1 -> pwm1 |
55 | temp2 -> pwm2 | 65 | temp2 -> pwm2 |
56 | temp3 -> pwm3 | 66 | temp3 -> pwm3 |
57 | prog -> pwm4 (the programmable setting is not supported by the driver) | 67 | prog -> pwm4 (not on 667HG; the programmable setting is not supported by |
68 | the driver) | ||
58 | 69 | ||
59 | /sys files | 70 | /sys files |
60 | ---------- | 71 | ---------- |
diff --git a/Documentation/i2c/busses/i2c-nforce2 b/Documentation/i2c/busses/i2c-nforce2 index fae3495bcbaf..9698c396b830 100644 --- a/Documentation/i2c/busses/i2c-nforce2 +++ b/Documentation/i2c/busses/i2c-nforce2 | |||
@@ -7,10 +7,14 @@ Supported adapters: | |||
7 | * nForce3 250Gb MCP 10de:00E4 | 7 | * nForce3 250Gb MCP 10de:00E4 |
8 | * nForce4 MCP 10de:0052 | 8 | * nForce4 MCP 10de:0052 |
9 | * nForce4 MCP-04 10de:0034 | 9 | * nForce4 MCP-04 10de:0034 |
10 | * nForce4 MCP51 10de:0264 | 10 | * nForce MCP51 10de:0264 |
11 | * nForce4 MCP55 10de:0368 | 11 | * nForce MCP55 10de:0368 |
12 | * nForce4 MCP61 10de:03EB | 12 | * nForce MCP61 10de:03EB |
13 | * nForce4 MCP65 10de:0446 | 13 | * nForce MCP65 10de:0446 |
14 | * nForce MCP67 10de:0542 | ||
15 | * nForce MCP73 10de:07D8 | ||
16 | * nForce MCP78S 10de:0752 | ||
17 | * nForce MCP79 10de:0AA2 | ||
14 | 18 | ||
15 | Datasheet: not publicly available, but seems to be similar to the | 19 | Datasheet: not publicly available, but seems to be similar to the |
16 | AMD-8111 SMBus 2.0 adapter. | 20 | AMD-8111 SMBus 2.0 adapter. |
diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index ef1efa79b1df..f889481762b5 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 | |||
@@ -4,7 +4,7 @@ Supported adapters: | |||
4 | * Intel 82371AB PIIX4 and PIIX4E | 4 | * Intel 82371AB PIIX4 and PIIX4E |
5 | * Intel 82443MX (440MX) | 5 | * Intel 82443MX (440MX) |
6 | Datasheet: Publicly available at the Intel website | 6 | Datasheet: Publicly available at the Intel website |
7 | * ServerWorks OSB4, CSB5, CSB6 and HT-1000 southbridges | 7 | * ServerWorks OSB4, CSB5, CSB6, HT-1000 and HT-1100 southbridges |
8 | Datasheet: Only available via NDA from ServerWorks | 8 | Datasheet: Only available via NDA from ServerWorks |
9 | * ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges | 9 | * ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges |
10 | Datasheet: Not publicly available | 10 | Datasheet: Not publicly available |
diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices new file mode 100644 index 000000000000..b55ce57a84db --- /dev/null +++ b/Documentation/i2c/instantiating-devices | |||
@@ -0,0 +1,167 @@ | |||
1 | How to instantiate I2C devices | ||
2 | ============================== | ||
3 | |||
4 | Unlike PCI or USB devices, I2C devices are not enumerated at the hardware | ||
5 | level. Instead, the software must know which devices are connected on each | ||
6 | I2C bus segment, and what address these devices are using. For this | ||
7 | reason, the kernel code must instantiate I2C devices explicitly. There are | ||
8 | several ways to achieve this, depending on the context and requirements. | ||
9 | |||
10 | |||
11 | Method 1: Declare the I2C devices by bus number | ||
12 | ----------------------------------------------- | ||
13 | |||
14 | This method is appropriate when the I2C bus is a system bus as is the case | ||
15 | for many embedded systems. On such systems, each I2C bus has a number | ||
16 | which is known in advance. It is thus possible to pre-declare the I2C | ||
17 | devices which live on this bus. This is done with an array of struct | ||
18 | i2c_board_info which is registered by calling i2c_register_board_info(). | ||
19 | |||
20 | Example (from omap2 h4): | ||
21 | |||
22 | static struct i2c_board_info __initdata h4_i2c_board_info[] = { | ||
23 | { | ||
24 | I2C_BOARD_INFO("isp1301_omap", 0x2d), | ||
25 | .irq = OMAP_GPIO_IRQ(125), | ||
26 | }, | ||
27 | { /* EEPROM on mainboard */ | ||
28 | I2C_BOARD_INFO("24c01", 0x52), | ||
29 | .platform_data = &m24c01, | ||
30 | }, | ||
31 | { /* EEPROM on cpu card */ | ||
32 | I2C_BOARD_INFO("24c01", 0x57), | ||
33 | .platform_data = &m24c01, | ||
34 | }, | ||
35 | }; | ||
36 | |||
37 | static void __init omap_h4_init(void) | ||
38 | { | ||
39 | (...) | ||
40 | i2c_register_board_info(1, h4_i2c_board_info, | ||
41 | ARRAY_SIZE(h4_i2c_board_info)); | ||
42 | (...) | ||
43 | } | ||
44 | |||
45 | The above code declares 3 devices on I2C bus 1, including their respective | ||
46 | addresses and custom data needed by their drivers. When the I2C bus in | ||
47 | question is registered, the I2C devices will be instantiated automatically | ||
48 | by i2c-core. | ||
49 | |||
50 | The devices will be automatically unbound and destroyed when the I2C bus | ||
51 | they sit on goes away (if ever.) | ||
52 | |||
53 | |||
54 | Method 2: Instantiate the devices explicitly | ||
55 | -------------------------------------------- | ||
56 | |||
57 | This method is appropriate when a larger device uses an I2C bus for | ||
58 | internal communication. A typical case is TV adapters. These can have a | ||
59 | tuner, a video decoder, an audio decoder, etc. usually connected to the | ||
60 | main chip by the means of an I2C bus. You won't know the number of the I2C | ||
61 | bus in advance, so the method 1 described above can't be used. Instead, | ||
62 | you can instantiate your I2C devices explicitly. This is done by filling | ||
63 | a struct i2c_board_info and calling i2c_new_device(). | ||
64 | |||
65 | Example (from the sfe4001 network driver): | ||
66 | |||
67 | static struct i2c_board_info sfe4001_hwmon_info = { | ||
68 | I2C_BOARD_INFO("max6647", 0x4e), | ||
69 | }; | ||
70 | |||
71 | int sfe4001_init(struct efx_nic *efx) | ||
72 | { | ||
73 | (...) | ||
74 | efx->board_info.hwmon_client = | ||
75 | i2c_new_device(&efx->i2c_adap, &sfe4001_hwmon_info); | ||
76 | |||
77 | (...) | ||
78 | } | ||
79 | |||
80 | The above code instantiates 1 I2C device on the I2C bus which is on the | ||
81 | network adapter in question. | ||
82 | |||
83 | A variant of this is when you don't know for sure if an I2C device is | ||
84 | present or not (for example for an optional feature which is not present | ||
85 | on cheap variants of a board but you have no way to tell them apart), or | ||
86 | it may have different addresses from one board to the next (manufacturer | ||
87 | changing its design without notice). In this case, you can call | ||
88 | i2c_new_probed_device() instead of i2c_new_device(). | ||
89 | |||
90 | Example (from the pnx4008 OHCI driver): | ||
91 | |||
92 | static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END }; | ||
93 | |||
94 | static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev) | ||
95 | { | ||
96 | (...) | ||
97 | struct i2c_adapter *i2c_adap; | ||
98 | struct i2c_board_info i2c_info; | ||
99 | |||
100 | (...) | ||
101 | i2c_adap = i2c_get_adapter(2); | ||
102 | memset(&i2c_info, 0, sizeof(struct i2c_board_info)); | ||
103 | strlcpy(i2c_info.name, "isp1301_pnx", I2C_NAME_SIZE); | ||
104 | isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info, | ||
105 | normal_i2c); | ||
106 | i2c_put_adapter(i2c_adap); | ||
107 | (...) | ||
108 | } | ||
109 | |||
110 | The above code instantiates up to 1 I2C device on the I2C bus which is on | ||
111 | the OHCI adapter in question. It first tries at address 0x2c, if nothing | ||
112 | is found there it tries address 0x2d, and if still nothing is found, it | ||
113 | simply gives up. | ||
114 | |||
115 | The driver which instantiated the I2C device is responsible for destroying | ||
116 | it on cleanup. This is done by calling i2c_unregister_device() on the | ||
117 | pointer that was earlier returned by i2c_new_device() or | ||
118 | i2c_new_probed_device(). | ||
119 | |||
120 | |||
121 | Method 3: Probe an I2C bus for certain devices | ||
122 | ---------------------------------------------- | ||
123 | |||
124 | Sometimes you do not have enough information about an I2C device, not even | ||
125 | to call i2c_new_probed_device(). The typical case is hardware monitoring | ||
126 | chips on PC mainboards. There are several dozen models, which can live | ||
127 | at 25 different addresses. Given the huge number of mainboards out there, | ||
128 | it is next to impossible to build an exhaustive list of the hardware | ||
129 | monitoring chips being used. Fortunately, most of these chips have | ||
130 | manufacturer and device ID registers, so they can be identified by | ||
131 | probing. | ||
132 | |||
133 | In that case, I2C devices are neither declared nor instantiated | ||
134 | explicitly. Instead, i2c-core will probe for such devices as soon as their | ||
135 | drivers are loaded, and if any is found, an I2C device will be | ||
136 | instantiated automatically. In order to prevent any misbehavior of this | ||
137 | mechanism, the following restrictions apply: | ||
138 | * The I2C device driver must implement the detect() method, which | ||
139 | identifies a supported device by reading from arbitrary registers. | ||
140 | * Only buses which are likely to have a supported device and agree to be | ||
141 | probed, will be probed. For example this avoids probing for hardware | ||
142 | monitoring chips on a TV adapter. | ||
143 | |||
144 | Example: | ||
145 | See lm90_driver and lm90_detect() in drivers/hwmon/lm90.c | ||
146 | |||
147 | I2C devices instantiated as a result of such a successful probe will be | ||
148 | destroyed automatically when the driver which detected them is removed, | ||
149 | or when the underlying I2C bus is itself destroyed, whichever happens | ||
150 | first. | ||
151 | |||
152 | Those of you familiar with the i2c subsystem of 2.4 kernels and early 2.6 | ||
153 | kernels will find out that this method 3 is essentially similar to what | ||
154 | was done there. Two significant differences are: | ||
155 | * Probing is only one way to instantiate I2C devices now, while it was the | ||
156 | only way back then. Where possible, methods 1 and 2 should be preferred. | ||
157 | Method 3 should only be used when there is no other way, as it can have | ||
158 | undesirable side effects. | ||
159 | * I2C buses must now explicitly say which I2C driver classes can probe | ||
160 | them (by the means of the class bitfield), while all I2C buses were | ||
161 | probed by default back then. The default is an empty class which means | ||
162 | that no probing happens. The purpose of the class bitfield is to limit | ||
163 | the aforementioned undesirable side effects. | ||
164 | |||
165 | Once again, method 3 should be avoided wherever possible. Explicit device | ||
166 | instantiation (methods 1 and 2) is much preferred for it is safer and | ||
167 | faster. | ||
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 6b9af7d479c2..c1a06f989cf7 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients | |||
@@ -207,15 +207,26 @@ You simply have to define a detect callback which will attempt to | |||
207 | identify supported devices (returning 0 for supported ones and -ENODEV | 207 | identify supported devices (returning 0 for supported ones and -ENODEV |
208 | for unsupported ones), a list of addresses to probe, and a device type | 208 | for unsupported ones), a list of addresses to probe, and a device type |
209 | (or class) so that only I2C buses which may have that type of device | 209 | (or class) so that only I2C buses which may have that type of device |
210 | connected (and not otherwise enumerated) will be probed. The i2c | 210 | connected (and not otherwise enumerated) will be probed. For example, |
211 | core will then call you back as needed and will instantiate a device | 211 | a driver for a hardware monitoring chip for which auto-detection is |
212 | for you for every successful detection. | 212 | needed would set its class to I2C_CLASS_HWMON, and only I2C adapters |
213 | with a class including I2C_CLASS_HWMON would be probed by this driver. | ||
214 | Note that the absence of matching classes does not prevent the use of | ||
215 | a device of that type on the given I2C adapter. All it prevents is | ||
216 | auto-detection; explicit instantiation of devices is still possible. | ||
213 | 217 | ||
214 | Note that this mechanism is purely optional and not suitable for all | 218 | Note that this mechanism is purely optional and not suitable for all |
215 | devices. You need some reliable way to identify the supported devices | 219 | devices. You need some reliable way to identify the supported devices |
216 | (typically using device-specific, dedicated identification registers), | 220 | (typically using device-specific, dedicated identification registers), |
217 | otherwise misdetections are likely to occur and things can get wrong | 221 | otherwise misdetections are likely to occur and things can get wrong |
218 | quickly. | 222 | quickly. Keep in mind that the I2C protocol doesn't include any |
223 | standard way to detect the presence of a chip at a given address, let | ||
224 | alone a standard way to identify devices. Even worse is the lack of | ||
225 | semantics associated to bus transfers, which means that the same | ||
226 | transfer can be seen as a read operation by a chip and as a write | ||
227 | operation by another chip. For these reasons, explicit device | ||
228 | instantiation should always be preferred to auto-detection where | ||
229 | possible. | ||
219 | 230 | ||
220 | 231 | ||
221 | Device Deletion | 232 | Device Deletion |
diff --git a/Documentation/ia64/kvm.txt b/Documentation/ia64/kvm.txt index 84f7cb3d5bec..ffb5c80bec3e 100644 --- a/Documentation/ia64/kvm.txt +++ b/Documentation/ia64/kvm.txt | |||
@@ -42,7 +42,7 @@ Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qe | |||
42 | hg clone http://xenbits.xensource.com/ext/efi-vfirmware.hg | 42 | hg clone http://xenbits.xensource.com/ext/efi-vfirmware.hg |
43 | you can get the firmware's binary in the directory of efi-vfirmware.hg/binaries. | 43 | you can get the firmware's binary in the directory of efi-vfirmware.hg/binaries. |
44 | 44 | ||
45 | (3) Rename the firware you owned to Flash.fd, and copy it to /usr/local/share/qemu | 45 | (3) Rename the firmware you owned to Flash.fd, and copy it to /usr/local/share/qemu |
46 | 46 | ||
47 | 4. Boot up Linux or Windows guests: | 47 | 4. Boot up Linux or Windows guests: |
48 | 4.1 Create or install a image for guest boot. If you have xen experience, it should be easy. | 48 | 4.1 Create or install a image for guest boot. If you have xen experience, it should be easy. |
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index f1d639903325..1f779a25c703 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt | |||
@@ -122,10 +122,8 @@ Code Seq# Include File Comments | |||
122 | 'c' 00-7F linux/coda.h conflict! | 122 | 'c' 00-7F linux/coda.h conflict! |
123 | 'c' 80-9F arch/s390/include/asm/chsc.h | 123 | 'c' 80-9F arch/s390/include/asm/chsc.h |
124 | 'd' 00-FF linux/char/drm/drm/h conflict! | 124 | 'd' 00-FF linux/char/drm/drm/h conflict! |
125 | 'd' 00-DF linux/video_decoder.h conflict! | ||
126 | 'd' F0-FF linux/digi1.h | 125 | 'd' F0-FF linux/digi1.h |
127 | 'e' all linux/digi1.h conflict! | 126 | 'e' all linux/digi1.h conflict! |
128 | 'e' 00-1F linux/video_encoder.h conflict! | ||
129 | 'e' 00-1F net/irda/irtty.h conflict! | 127 | 'e' 00-1F net/irda/irtty.h conflict! |
130 | 'f' 00-1F linux/ext2_fs.h | 128 | 'f' 00-1F linux/ext2_fs.h |
131 | 'h' 00-7F Charon filesystem | 129 | 'h' 00-7F Charon filesystem |
diff --git a/Documentation/isdn/README.gigaset b/Documentation/isdn/README.gigaset index 55b2852904a4..02c0e9341dd8 100644 --- a/Documentation/isdn/README.gigaset +++ b/Documentation/isdn/README.gigaset | |||
@@ -61,24 +61,28 @@ GigaSet 307x Device Driver | |||
61 | --------------------- | 61 | --------------------- |
62 | 2.1. Modules | 62 | 2.1. Modules |
63 | ------- | 63 | ------- |
64 | To get the device working, you have to load the proper kernel module. You | 64 | For the devices to work, the proper kernel modules have to be loaded. |
65 | can do this using | 65 | This normally happens automatically when the system detects the USB |
66 | modprobe modulename | 66 | device (base, M105) or when the line discipline is attached (M101). It |
67 | where modulename is ser_gigaset (M101), usb_gigaset (M105), or | 67 | can also be triggered manually using the modprobe(8) command, for example |
68 | bas_gigaset (direct USB connection to the base). | 68 | for troubleshooting or to pass module parameters. |
69 | 69 | ||
70 | The module ser_gigaset provides a serial line discipline N_GIGASET_M101 | 70 | The module ser_gigaset provides a serial line discipline N_GIGASET_M101 |
71 | which drives the device through the regular serial line driver. To use it, | 71 | which drives the device through the regular serial line driver. It must |
72 | run the Gigaset M101 daemon "gigasetm101d" (also available from | 72 | be attached to the serial line to which the M101 is connected with the |
73 | http://sourceforge.net/projects/gigaset307x/) with the device file of the | 73 | ldattach(8) command (requires util-linux-ng release 2.14 or later), for |
74 | RS232 port to the M101 as an argument, for example: | 74 | example: |
75 | gigasetm101d /dev/ttyS1 | 75 | ldattach GIGASET_M101 /dev/ttyS1 |
76 | This will open the device file, set its line discipline to N_GIGASET_M101, | 76 | This will open the device file, attach the line discipline to it, and |
77 | and then sleep in the background, keeping the device open so that the | 77 | then sleep in the background, keeping the device open so that the line |
78 | line discipline remains active. To deactivate it, kill the daemon, for | 78 | discipline remains active. To deactivate it, kill the daemon, for example |
79 | example with | 79 | with |
80 | killall gigasetm101d | 80 | killall ldattach |
81 | before disconnecting the device. | 81 | before disconnecting the device. To have this happen automatically at |
82 | system startup/shutdown on an LSB compatible system, create and activate | ||
83 | an appropriate LSB startup script /etc/init.d/gigaset. (The init name | ||
84 | 'gigaset' is officially assigned to this project by LANANA.) | ||
85 | Alternatively, just add the 'ldattach' command line to /etc/rc.local. | ||
82 | 86 | ||
83 | 2.2. Device nodes for user space programs | 87 | 2.2. Device nodes for user space programs |
84 | ------------------------------------ | 88 | ------------------------------------ |
@@ -194,10 +198,11 @@ GigaSet 307x Device Driver | |||
194 | operation (for wireless access to the base), but are needed for access | 198 | operation (for wireless access to the base), but are needed for access |
195 | to the M105's own configuration mode (registration to the base, baudrate | 199 | to the M105's own configuration mode (registration to the base, baudrate |
196 | and line format settings, device status queries) via the gigacontr | 200 | and line format settings, device status queries) via the gigacontr |
197 | utility. Their use is disabled in the driver by default for safety | 201 | utility. Their use is controlled by the kernel configuration option |
198 | reasons but can be enabled by setting the kernel configuration option | 202 | "Support for undocumented USB requests" (CONFIG_GIGASET_UNDOCREQ). If you |
199 | "Support for undocumented USB requests" (GIGASET_UNDOCREQ) to "Y" and | 203 | encounter error code -ENOTTY when trying to use some features of the |
200 | recompiling. | 204 | M105, try setting that option to "y" via 'make {x,menu}config' and |
205 | recompiling the driver. | ||
201 | 206 | ||
202 | 207 | ||
203 | 3. Troubleshooting | 208 | 3. Troubleshooting |
@@ -228,6 +233,13 @@ GigaSet 307x Device Driver | |||
228 | Solution: | 233 | Solution: |
229 | Select Unimodem mode for all DECT data adapters. (see section 2.4.) | 234 | Select Unimodem mode for all DECT data adapters. (see section 2.4.) |
230 | 235 | ||
236 | Problem: | ||
237 | You want to configure your USB DECT data adapter (M105) but gigacontr | ||
238 | reports an error: "/dev/ttyGU0: Inappropriate ioctl for device". | ||
239 | Solution: | ||
240 | Recompile the usb_gigaset driver with the kernel configuration option | ||
241 | CONFIG_GIGASET_UNDOCREQ set to 'y'. (see section 2.6.) | ||
242 | |||
231 | 3.2. Telling the driver to provide more information | 243 | 3.2. Telling the driver to provide more information |
232 | ---------------------------------------------- | 244 | ---------------------------------------------- |
233 | Building the driver with the "Gigaset debugging" kernel configuration | 245 | Building the driver with the "Gigaset debugging" kernel configuration |
diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt index d73fbd2b2b45..026ec7d57384 100644 --- a/Documentation/kernel-doc-nano-HOWTO.txt +++ b/Documentation/kernel-doc-nano-HOWTO.txt | |||
@@ -43,7 +43,8 @@ Only comments so marked will be considered by the kernel-doc scripts, | |||
43 | and any comment so marked must be in kernel-doc format. Do not use | 43 | and any comment so marked must be in kernel-doc format. Do not use |
44 | "/**" to be begin a comment block unless the comment block contains | 44 | "/**" to be begin a comment block unless the comment block contains |
45 | kernel-doc formatted comments. The closing comment marker for | 45 | kernel-doc formatted comments. The closing comment marker for |
46 | kernel-doc comments can be either "*/" or "**/". | 46 | kernel-doc comments can be either "*/" or "**/", but "*/" is |
47 | preferred in the Linux kernel tree. | ||
47 | 48 | ||
48 | Kernel-doc comments should be placed just before the function | 49 | Kernel-doc comments should be placed just before the function |
49 | or data structure being described. | 50 | or data structure being described. |
@@ -63,7 +64,7 @@ Example kernel-doc function comment: | |||
63 | * comment lines. | 64 | * comment lines. |
64 | * | 65 | * |
65 | * The longer description can have multiple paragraphs. | 66 | * The longer description can have multiple paragraphs. |
66 | **/ | 67 | */ |
67 | 68 | ||
68 | The first line, with the short description, must be on a single line. | 69 | The first line, with the short description, must be on a single line. |
69 | 70 | ||
@@ -85,7 +86,7 @@ Example kernel-doc data structure comment. | |||
85 | * perhaps with more lines and words. | 86 | * perhaps with more lines and words. |
86 | * | 87 | * |
87 | * Longer description of this structure. | 88 | * Longer description of this structure. |
88 | **/ | 89 | */ |
89 | 90 | ||
90 | The kernel-doc function comments describe each parameter to the | 91 | The kernel-doc function comments describe each parameter to the |
91 | function, in order, with the @name lines. | 92 | function, in order, with the @name lines. |
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d8362cf9909e..6172e4360f60 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -44,11 +44,13 @@ parameter is applicable: | |||
44 | FB The frame buffer device is enabled. | 44 | FB The frame buffer device is enabled. |
45 | HW Appropriate hardware is enabled. | 45 | HW Appropriate hardware is enabled. |
46 | IA-64 IA-64 architecture is enabled. | 46 | IA-64 IA-64 architecture is enabled. |
47 | IMA Integrity measurement architecture is enabled. | ||
47 | IOSCHED More than one I/O scheduler is enabled. | 48 | IOSCHED More than one I/O scheduler is enabled. |
48 | IP_PNP IP DHCP, BOOTP, or RARP is enabled. | 49 | IP_PNP IP DHCP, BOOTP, or RARP is enabled. |
49 | ISAPNP ISA PnP code is enabled. | 50 | ISAPNP ISA PnP code is enabled. |
50 | ISDN Appropriate ISDN support is enabled. | 51 | ISDN Appropriate ISDN support is enabled. |
51 | JOY Appropriate joystick support is enabled. | 52 | JOY Appropriate joystick support is enabled. |
53 | KMEMTRACE kmemtrace is enabled. | ||
52 | LIBATA Libata driver is enabled | 54 | LIBATA Libata driver is enabled |
53 | LP Printer support is enabled. | 55 | LP Printer support is enabled. |
54 | LOOP Loopback device support is enabled. | 56 | LOOP Loopback device support is enabled. |
@@ -114,7 +116,7 @@ In addition, the following text indicates that the option: | |||
114 | Parameters denoted with BOOT are actually interpreted by the boot | 116 | Parameters denoted with BOOT are actually interpreted by the boot |
115 | loader, and have no meaning to the kernel directly. | 117 | loader, and have no meaning to the kernel directly. |
116 | Do not modify the syntax of boot loader parameters without extreme | 118 | Do not modify the syntax of boot loader parameters without extreme |
117 | need or coordination with <Documentation/x86/i386/boot.txt>. | 119 | need or coordination with <Documentation/x86/boot.txt>. |
118 | 120 | ||
119 | There are also arch-specific kernel-parameters not documented here. | 121 | There are also arch-specific kernel-parameters not documented here. |
120 | See for example <Documentation/x86/x86_64/boot-options.txt>. | 122 | See for example <Documentation/x86/x86_64/boot-options.txt>. |
@@ -134,7 +136,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
134 | 136 | ||
135 | acpi= [HW,ACPI,X86-64,i386] | 137 | acpi= [HW,ACPI,X86-64,i386] |
136 | Advanced Configuration and Power Interface | 138 | Advanced Configuration and Power Interface |
137 | Format: { force | off | ht | strict | noirq } | 139 | Format: { force | off | ht | strict | noirq | rsdt } |
138 | force -- enable ACPI if default was off | 140 | force -- enable ACPI if default was off |
139 | off -- disable ACPI if default was on | 141 | off -- disable ACPI if default was on |
140 | noirq -- do not use ACPI for IRQ routing | 142 | noirq -- do not use ACPI for IRQ routing |
@@ -151,60 +153,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
151 | 1,0: use 1st APIC table | 153 | 1,0: use 1st APIC table |
152 | default: 0 | 154 | default: 0 |
153 | 155 | ||
154 | acpi_sleep= [HW,ACPI] Sleep options | ||
155 | Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig, | ||
156 | old_ordering, s4_nonvs } | ||
157 | See Documentation/power/video.txt for information on | ||
158 | s3_bios and s3_mode. | ||
159 | s3_beep is for debugging; it makes the PC's speaker beep | ||
160 | as soon as the kernel's real-mode entry point is called. | ||
161 | s4_nohwsig prevents ACPI hardware signature from being | ||
162 | used during resume from hibernation. | ||
163 | old_ordering causes the ACPI 1.0 ordering of the _PTS | ||
164 | control method, with respect to putting devices into | ||
165 | low power states, to be enforced (the ACPI 2.0 ordering | ||
166 | of _PTS is used by default). | ||
167 | s4_nonvs prevents the kernel from saving/restoring the | ||
168 | ACPI NVS memory during hibernation. | ||
169 | |||
170 | acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode | ||
171 | Format: { level | edge | high | low } | ||
172 | |||
173 | acpi_irq_balance [HW,ACPI] | ||
174 | ACPI will balance active IRQs | ||
175 | default in APIC mode | ||
176 | |||
177 | acpi_irq_nobalance [HW,ACPI] | ||
178 | ACPI will not move active IRQs (default) | ||
179 | default in PIC mode | ||
180 | |||
181 | acpi_irq_pci= [HW,ACPI] If irq_balance, clear listed IRQs for | ||
182 | use by PCI | ||
183 | Format: <irq>,<irq>... | ||
184 | |||
185 | acpi_irq_isa= [HW,ACPI] If irq_balance, mark listed IRQs used by ISA | ||
186 | Format: <irq>,<irq>... | ||
187 | |||
188 | acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT | ||
189 | |||
190 | acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS | ||
191 | Format: To spoof as Windows 98: ="Microsoft Windows" | ||
192 | |||
193 | acpi_osi= [HW,ACPI] Modify list of supported OS interface strings | ||
194 | acpi_osi="string1" # add string1 -- only one string | ||
195 | acpi_osi="!string2" # remove built-in string2 | ||
196 | acpi_osi= # disable all strings | ||
197 | |||
198 | acpi_serialize [HW,ACPI] force serialization of AML methods | ||
199 | |||
200 | acpi_skip_timer_override [HW,ACPI] | ||
201 | Recognize and ignore IRQ0/pin2 Interrupt Override. | ||
202 | For broken nForce2 BIOS resulting in XT-PIC timer. | ||
203 | acpi_use_timer_override [HW,ACPI] | ||
204 | Use timer override. For some broken Nvidia NF5 boards | ||
205 | that require a timer override, but don't have | ||
206 | HPET | ||
207 | |||
208 | acpi_backlight= [HW,ACPI] | 156 | acpi_backlight= [HW,ACPI] |
209 | acpi_backlight=vendor | 157 | acpi_backlight=vendor |
210 | acpi_backlight=video | 158 | acpi_backlight=video |
@@ -212,11 +160,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
212 | (e.g. thinkpad_acpi, sony_acpi, etc.) instead | 160 | (e.g. thinkpad_acpi, sony_acpi, etc.) instead |
213 | of the ACPI video.ko driver. | 161 | of the ACPI video.ko driver. |
214 | 162 | ||
215 | acpi_display_output= [HW,ACPI] | ||
216 | acpi_display_output=vendor | ||
217 | acpi_display_output=video | ||
218 | See above. | ||
219 | |||
220 | acpi.debug_layer= [HW,ACPI,ACPI_DEBUG] | 163 | acpi.debug_layer= [HW,ACPI,ACPI_DEBUG] |
221 | acpi.debug_level= [HW,ACPI,ACPI_DEBUG] | 164 | acpi.debug_level= [HW,ACPI,ACPI_DEBUG] |
222 | Format: <int> | 165 | Format: <int> |
@@ -245,6 +188,41 @@ and is between 256 and 4096 characters. It is defined in the file | |||
245 | unusable. The "log_buf_len" parameter may be useful | 188 | unusable. The "log_buf_len" parameter may be useful |
246 | if you need to capture more output. | 189 | if you need to capture more output. |
247 | 190 | ||
191 | acpi_display_output= [HW,ACPI] | ||
192 | acpi_display_output=vendor | ||
193 | acpi_display_output=video | ||
194 | See above. | ||
195 | |||
196 | acpi_irq_balance [HW,ACPI] | ||
197 | ACPI will balance active IRQs | ||
198 | default in APIC mode | ||
199 | |||
200 | acpi_irq_nobalance [HW,ACPI] | ||
201 | ACPI will not move active IRQs (default) | ||
202 | default in PIC mode | ||
203 | |||
204 | acpi_irq_isa= [HW,ACPI] If irq_balance, mark listed IRQs used by ISA | ||
205 | Format: <irq>,<irq>... | ||
206 | |||
207 | acpi_irq_pci= [HW,ACPI] If irq_balance, clear listed IRQs for | ||
208 | use by PCI | ||
209 | Format: <irq>,<irq>... | ||
210 | |||
211 | acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT | ||
212 | |||
213 | acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS | ||
214 | Format: To spoof as Windows 98: ="Microsoft Windows" | ||
215 | |||
216 | acpi_osi= [HW,ACPI] Modify list of supported OS interface strings | ||
217 | acpi_osi="string1" # add string1 -- only one string | ||
218 | acpi_osi="!string2" # remove built-in string2 | ||
219 | acpi_osi= # disable all strings | ||
220 | |||
221 | acpi_pm_good [X86-32,X86-64] | ||
222 | Override the pmtimer bug detection: force the kernel | ||
223 | to assume that this machine's pmtimer latches its value | ||
224 | and always returns good values. | ||
225 | |||
248 | acpi.power_nocheck= [HW,ACPI] | 226 | acpi.power_nocheck= [HW,ACPI] |
249 | Format: 1/0 enable/disable the check of power state. | 227 | Format: 1/0 enable/disable the check of power state. |
250 | On some bogus BIOS the _PSC object/_STA object of | 228 | On some bogus BIOS the _PSC object/_STA object of |
@@ -253,26 +231,21 @@ and is between 256 and 4096 characters. It is defined in the file | |||
253 | power state again in power transition. | 231 | power state again in power transition. |
254 | 1 : disable the power state check | 232 | 1 : disable the power state check |
255 | 233 | ||
256 | acpi_pm_good [X86-32,X86-64] | 234 | acpi_enforce_resources= [ACPI] |
257 | Override the pmtimer bug detection: force the kernel | 235 | { strict | lax | no } |
258 | to assume that this machine's pmtimer latches its value | 236 | Check for resource conflicts between native drivers |
259 | and always returns good values. | 237 | and ACPI OperationRegions (SystemIO and SystemMemory |
260 | 238 | only). IO ports and memory declared in ACPI might be | |
261 | agp= [AGP] | 239 | used by the ACPI subsystem in arbitrary AML code and |
262 | { off | try_unsupported } | 240 | can interfere with legacy drivers. |
263 | off: disable AGP support | 241 | strict (default): access to resources claimed by ACPI |
264 | try_unsupported: try to drive unsupported chipsets | 242 | is denied; legacy drivers trying to access reserved |
265 | (may crash computer or cause data corruption) | 243 | resources will fail to bind to device using them. |
266 | 244 | lax: access to resources claimed by ACPI is allowed; | |
267 | enable_timer_pin_1 [i386,x86-64] | 245 | legacy drivers trying to access reserved resources |
268 | Enable PIN 1 of APIC timer | 246 | will bind successfully but a warning message is logged. |
269 | Can be useful to work around chipset bugs | 247 | no: ACPI OperationRegions are not marked as reserved, |
270 | (in particular on some ATI chipsets). | 248 | no further checks are performed. |
271 | The kernel tries to set a reasonable default. | ||
272 | |||
273 | disable_timer_pin_1 [i386,x86-64] | ||
274 | Disable PIN 1 of APIC timer | ||
275 | Can be useful to work around chipset bugs. | ||
276 | 249 | ||
277 | ad1848= [HW,OSS] | 250 | ad1848= [HW,OSS] |
278 | Format: <io>,<irq>,<dma>,<dma2>,<type> | 251 | Format: <io>,<irq>,<dma>,<dma2>,<type> |
@@ -287,6 +260,12 @@ and is between 256 and 4096 characters. It is defined in the file | |||
287 | Format: <io>,<irq>,<dma>,<mss_io>,<mpu_io>,<mpu_irq> | 260 | Format: <io>,<irq>,<dma>,<mss_io>,<mpu_io>,<mpu_irq> |
288 | See also header of sound/oss/aedsp16.c. | 261 | See also header of sound/oss/aedsp16.c. |
289 | 262 | ||
263 | agp= [AGP] | ||
264 | { off | try_unsupported } | ||
265 | off: disable AGP support | ||
266 | try_unsupported: try to drive unsupported chipsets | ||
267 | (may crash computer or cause data corruption) | ||
268 | |||
290 | aha152x= [HW,SCSI] | 269 | aha152x= [HW,SCSI] |
291 | See Documentation/scsi/aha152x.txt. | 270 | See Documentation/scsi/aha152x.txt. |
292 | 271 | ||
@@ -414,12 +393,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
414 | possible to determine what the correct size should be. | 393 | possible to determine what the correct size should be. |
415 | This option provides an override for these situations. | 394 | This option provides an override for these situations. |
416 | 395 | ||
417 | security= [SECURITY] Choose a security module to enable at boot. | ||
418 | If this boot parameter is not specified, only the first | ||
419 | security module asking for security registration will be | ||
420 | loaded. An invalid security module name will be treated | ||
421 | as if no module has been chosen. | ||
422 | |||
423 | capability.disable= | 396 | capability.disable= |
424 | [SECURITY] Disable capabilities. This would normally | 397 | [SECURITY] Disable capabilities. This would normally |
425 | be used only if an alternative security model is to be | 398 | be used only if an alternative security model is to be |
@@ -491,12 +464,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
491 | Range: 0 - 8192 | 464 | Range: 0 - 8192 |
492 | Default: 64 | 465 | Default: 64 |
493 | 466 | ||
494 | hpet= [X86-32,HPET] option to control HPET usage | ||
495 | Format: { enable (default) | disable | force } | ||
496 | disable: disable HPET and use PIT instead | ||
497 | force: allow force enabled of undocumented chips (ICH4, | ||
498 | VIA, nVidia) | ||
499 | |||
500 | com20020= [HW,NET] ARCnet - COM20020 chipset | 467 | com20020= [HW,NET] ARCnet - COM20020 chipset |
501 | Format: | 468 | Format: |
502 | <io>[,<irq>[,<nodeID>[,<backplane>[,<ckp>[,<timeout>]]]]] | 469 | <io>[,<irq>[,<nodeID>[,<backplane>[,<ckp>[,<timeout>]]]]] |
@@ -540,23 +507,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
540 | console=brl,ttyS0 | 507 | console=brl,ttyS0 |
541 | For now, only VisioBraille is supported. | 508 | For now, only VisioBraille is supported. |
542 | 509 | ||
543 | earlycon= [KNL] Output early console device and options. | ||
544 | uart[8250],io,<addr>[,options] | ||
545 | uart[8250],mmio,<addr>[,options] | ||
546 | Start an early, polled-mode console on the 8250/16550 | ||
547 | UART at the specified I/O port or MMIO address. | ||
548 | The options are the same as for ttyS, above. | ||
549 | |||
550 | no_console_suspend | ||
551 | [HW] Never suspend the console | ||
552 | Disable suspending of consoles during suspend and | ||
553 | hibernate operations. Once disabled, debugging | ||
554 | messages can reach various consoles while the rest | ||
555 | of the system is being put to sleep (ie, while | ||
556 | debugging driver suspend/resume hooks). This may | ||
557 | not work reliably with all consoles, but is known | ||
558 | to work with serial and VGA consoles. | ||
559 | |||
560 | coredump_filter= | 510 | coredump_filter= |
561 | [KNL] Change the default value for | 511 | [KNL] Change the default value for |
562 | /proc/<pid>/coredump_filter. | 512 | /proc/<pid>/coredump_filter. |
@@ -604,36 +554,22 @@ and is between 256 and 4096 characters. It is defined in the file | |||
604 | 554 | ||
605 | debug_objects [KNL] Enable object debugging | 555 | debug_objects [KNL] Enable object debugging |
606 | 556 | ||
557 | no_debug_objects | ||
558 | [KNL] Disable object debugging | ||
559 | |||
607 | debugpat [X86] Enable PAT debugging | 560 | debugpat [X86] Enable PAT debugging |
608 | 561 | ||
609 | decnet.addr= [HW,NET] | 562 | decnet.addr= [HW,NET] |
610 | Format: <area>[,<node>] | 563 | Format: <area>[,<node>] |
611 | See also Documentation/networking/decnet.txt. | 564 | See also Documentation/networking/decnet.txt. |
612 | 565 | ||
613 | vt.default_blu= [VT] | 566 | default_hugepagesz= |
614 | Format: <blue0>,<blue1>,<blue2>,...,<blue15> | 567 | [same as hugepagesz=] The size of the default |
615 | Change the default blue palette of the console. | 568 | HugeTLB page size. This is the size represented by |
616 | This is a 16-member array composed of values | 569 | the legacy /proc/ hugepages APIs, used for SHM, and |
617 | ranging from 0-255. | 570 | default size when mounting hugetlbfs filesystems. |
618 | 571 | Defaults to the default architecture's huge page size | |
619 | vt.default_grn= [VT] | 572 | if not specified. |
620 | Format: <green0>,<green1>,<green2>,...,<green15> | ||
621 | Change the default green palette of the console. | ||
622 | This is a 16-member array composed of values | ||
623 | ranging from 0-255. | ||
624 | |||
625 | vt.default_red= [VT] | ||
626 | Format: <red0>,<red1>,<red2>,...,<red15> | ||
627 | Change the default red palette of the console. | ||
628 | This is a 16-member array composed of values | ||
629 | ranging from 0-255. | ||
630 | |||
631 | vt.default_utf8= | ||
632 | [VT] | ||
633 | Format=<0|1> | ||
634 | Set system-wide default UTF-8 mode for all tty's. | ||
635 | Default is 1, i.e. UTF-8 mode is enabled for all | ||
636 | newly opened terminals. | ||
637 | 573 | ||
638 | dhash_entries= [KNL] | 574 | dhash_entries= [KNL] |
639 | Set number of hash buckets for dentry cache. | 575 | Set number of hash buckets for dentry cache. |
@@ -646,27 +582,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
646 | Documentation/serial/digiepca.txt. | 582 | Documentation/serial/digiepca.txt. |
647 | 583 | ||
648 | disable_mtrr_cleanup [X86] | 584 | disable_mtrr_cleanup [X86] |
649 | enable_mtrr_cleanup [X86] | ||
650 | The kernel tries to adjust MTRR layout from continuous | 585 | The kernel tries to adjust MTRR layout from continuous |
651 | to discrete, to make X server driver able to add WB | 586 | to discrete, to make X server driver able to add WB |
652 | entry later. This parameter enables/disables that. | 587 | entry later. This parameter disables that. |
653 | |||
654 | mtrr_chunk_size=nn[KMG] [X86] | ||
655 | used for mtrr cleanup. It is largest continous chunk | ||
656 | that could hold holes aka. UC entries. | ||
657 | |||
658 | mtrr_gran_size=nn[KMG] [X86] | ||
659 | Used for mtrr cleanup. It is granularity of mtrr block. | ||
660 | Default is 1. | ||
661 | Large value could prevent small alignment from | ||
662 | using up MTRRs. | ||
663 | |||
664 | mtrr_spare_reg_nr=n [X86] | ||
665 | Format: <integer> | ||
666 | Range: 0,7 : spare reg number | ||
667 | Default : 1 | ||
668 | Used for mtrr cleanup. It is spare mtrr entries number. | ||
669 | Set to 2 or more if your graphical card needs more. | ||
670 | 588 | ||
671 | disable_mtrr_trim [X86, Intel and AMD only] | 589 | disable_mtrr_trim [X86, Intel and AMD only] |
672 | By default the kernel will trim any uncacheable | 590 | By default the kernel will trim any uncacheable |
@@ -674,12 +592,38 @@ and is between 256 and 4096 characters. It is defined in the file | |||
674 | MTRR settings. This parameter disables that behavior, | 592 | MTRR settings. This parameter disables that behavior, |
675 | possibly causing your machine to run very slowly. | 593 | possibly causing your machine to run very slowly. |
676 | 594 | ||
595 | disable_timer_pin_1 [i386,x86-64] | ||
596 | Disable PIN 1 of APIC timer | ||
597 | Can be useful to work around chipset bugs. | ||
598 | |||
677 | dmasound= [HW,OSS] Sound subsystem buffers | 599 | dmasound= [HW,OSS] Sound subsystem buffers |
678 | 600 | ||
601 | dma_debug=off If the kernel is compiled with DMA_API_DEBUG support, | ||
602 | this option disables the debugging code at boot. | ||
603 | |||
604 | dma_debug_entries=<number> | ||
605 | This option allows to tune the number of preallocated | ||
606 | entries for DMA-API debugging code. One entry is | ||
607 | required per DMA-API allocation. Use this if the | ||
608 | DMA-API debugging code disables itself because the | ||
609 | architectural default is too low. | ||
610 | |||
679 | dscc4.setup= [NET] | 611 | dscc4.setup= [NET] |
680 | 612 | ||
681 | dtc3181e= [HW,SCSI] | 613 | dtc3181e= [HW,SCSI] |
682 | 614 | ||
615 | dynamic_printk Enables pr_debug()/dev_dbg() calls if | ||
616 | CONFIG_DYNAMIC_PRINTK_DEBUG has been enabled. | ||
617 | These can also be switched on/off via | ||
618 | <debugfs>/dynamic_printk/modules | ||
619 | |||
620 | earlycon= [KNL] Output early console device and options. | ||
621 | uart[8250],io,<addr>[,options] | ||
622 | uart[8250],mmio,<addr>[,options] | ||
623 | Start an early, polled-mode console on the 8250/16550 | ||
624 | UART at the specified I/O port or MMIO address. | ||
625 | The options are the same as for ttyS, above. | ||
626 | |||
683 | earlyprintk= [X86-32,X86-64,SH,BLACKFIN] | 627 | earlyprintk= [X86-32,X86-64,SH,BLACKFIN] |
684 | earlyprintk=vga | 628 | earlyprintk=vga |
685 | earlyprintk=serial[,ttySn[,baudrate]] | 629 | earlyprintk=serial[,ttySn[,baudrate]] |
@@ -721,6 +665,17 @@ and is between 256 and 4096 characters. It is defined in the file | |||
721 | pass this option to capture kernel. | 665 | pass this option to capture kernel. |
722 | See Documentation/kdump/kdump.txt for details. | 666 | See Documentation/kdump/kdump.txt for details. |
723 | 667 | ||
668 | enable_mtrr_cleanup [X86] | ||
669 | The kernel tries to adjust MTRR layout from continuous | ||
670 | to discrete, to make X server driver able to add WB | ||
671 | entry later. This parameter enables that. | ||
672 | |||
673 | enable_timer_pin_1 [i386,x86-64] | ||
674 | Enable PIN 1 of APIC timer | ||
675 | Can be useful to work around chipset bugs | ||
676 | (in particular on some ATI chipsets). | ||
677 | The kernel tries to set a reasonable default. | ||
678 | |||
724 | enforcing [SELINUX] Set initial enforcing status. | 679 | enforcing [SELINUX] Set initial enforcing status. |
725 | Format: {"0" | "1"} | 680 | Format: {"0" | "1"} |
726 | See security/selinux/Kconfig help text. | 681 | See security/selinux/Kconfig help text. |
@@ -808,6 +763,16 @@ and is between 256 and 4096 characters. It is defined in the file | |||
808 | hisax= [HW,ISDN] | 763 | hisax= [HW,ISDN] |
809 | See Documentation/isdn/README.HiSax. | 764 | See Documentation/isdn/README.HiSax. |
810 | 765 | ||
766 | hlt [BUGS=ARM,SH] | ||
767 | |||
768 | hpet= [X86-32,HPET] option to control HPET usage | ||
769 | Format: { enable (default) | disable | force | | ||
770 | verbose } | ||
771 | disable: disable HPET and use PIT instead | ||
772 | force: allow force enabled of undocumented chips (ICH4, | ||
773 | VIA, nVidia) | ||
774 | verbose: show contents of HPET registers during setup | ||
775 | |||
811 | hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot. | 776 | hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot. |
812 | hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages. | 777 | hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages. |
813 | On x86-64 and powerpc, this option can be specified | 778 | On x86-64 and powerpc, this option can be specified |
@@ -817,18 +782,18 @@ and is between 256 and 4096 characters. It is defined in the file | |||
817 | (when the CPU supports the "pdpe1gb" cpuinfo flag) | 782 | (when the CPU supports the "pdpe1gb" cpuinfo flag) |
818 | Note that 1GB pages can only be allocated at boot time | 783 | Note that 1GB pages can only be allocated at boot time |
819 | using hugepages= and not freed afterwards. | 784 | using hugepages= and not freed afterwards. |
820 | default_hugepagesz= | ||
821 | [same as hugepagesz=] The size of the default | ||
822 | HugeTLB page size. This is the size represented by | ||
823 | the legacy /proc/ hugepages APIs, used for SHM, and | ||
824 | default size when mounting hugetlbfs filesystems. | ||
825 | Defaults to the default architecture's huge page size | ||
826 | if not specified. | ||
827 | |||
828 | hlt [BUGS=ARM,SH] | ||
829 | 785 | ||
830 | hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC) | 786 | hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC) |
831 | terminal devices. Valid values: 0..8 | 787 | terminal devices. Valid values: 0..8 |
788 | hvc_iucv_allow= [S390] Comma-separated list of z/VM user IDs. | ||
789 | If specified, z/VM IUCV HVC accepts connections | ||
790 | from listed z/VM user IDs only. | ||
791 | |||
792 | i2c_bus= [HW] Override the default board specific I2C bus speed | ||
793 | or register an additional I2C bus that is not | ||
794 | registered from board initialization code. | ||
795 | Format: | ||
796 | <bus_id>,<clkrate> | ||
832 | 797 | ||
833 | i8042.debug [HW] Toggle i8042 debug mode | 798 | i8042.debug [HW] Toggle i8042 debug mode |
834 | i8042.direct [HW] Put keyboard port into non-translated mode | 799 | i8042.direct [HW] Put keyboard port into non-translated mode |
@@ -868,13 +833,18 @@ and is between 256 and 4096 characters. It is defined in the file | |||
868 | icn= [HW,ISDN] | 833 | icn= [HW,ISDN] |
869 | Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]] | 834 | Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]] |
870 | 835 | ||
871 | ide= [HW] (E)IDE subsystem | 836 | ide-core.nodma= [HW] (E)IDE subsystem |
872 | Format: ide=nodma or ide=doubler | 837 | Format: =0.0 to prevent dma on hda, =0.1 hdb =1.0 hdc |
838 | .vlb_clock .pci_clock .noflush .noprobe .nowerr .cdrom | ||
839 | .chs .ignore_cable are additional options | ||
873 | See Documentation/ide/ide.txt. | 840 | See Documentation/ide/ide.txt. |
874 | 841 | ||
875 | idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed | 842 | idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed |
876 | See Documentation/ide/ide.txt. | 843 | See Documentation/ide/ide.txt. |
877 | 844 | ||
845 | ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem | ||
846 | Claim all unknown PCI IDE storage controllers. | ||
847 | |||
878 | idle= [X86] | 848 | idle= [X86] |
879 | Format: idle=poll, idle=mwait, idle=halt, idle=nomwait | 849 | Format: idle=poll, idle=mwait, idle=halt, idle=nomwait |
880 | Poll forces a polling idle loop that can slightly | 850 | Poll forces a polling idle loop that can slightly |
@@ -890,9 +860,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
890 | In such case C2/C3 won't be used again. | 860 | In such case C2/C3 won't be used again. |
891 | idle=nomwait: Disable mwait for CPU C-states | 861 | idle=nomwait: Disable mwait for CPU C-states |
892 | 862 | ||
893 | ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem | ||
894 | Claim all unknown PCI IDE storage controllers. | ||
895 | |||
896 | ignore_loglevel [KNL] | 863 | ignore_loglevel [KNL] |
897 | Ignore loglevel setting - this will print /all/ | 864 | Ignore loglevel setting - this will print /all/ |
898 | kernel messages to the console. Useful for debugging. | 865 | kernel messages to the console. Useful for debugging. |
@@ -900,6 +867,15 @@ and is between 256 and 4096 characters. It is defined in the file | |||
900 | ihash_entries= [KNL] | 867 | ihash_entries= [KNL] |
901 | Set number of hash buckets for inode cache. | 868 | Set number of hash buckets for inode cache. |
902 | 869 | ||
870 | ima_audit= [IMA] | ||
871 | Format: { "0" | "1" } | ||
872 | 0 -- integrity auditing messages. (Default) | ||
873 | 1 -- enable informational integrity auditing messages. | ||
874 | |||
875 | ima_hash= [IMA] | ||
876 | Formt: { "sha1" | "md5" } | ||
877 | default: "sha1" | ||
878 | |||
903 | in2000= [HW,SCSI] | 879 | in2000= [HW,SCSI] |
904 | See header of drivers/scsi/in2000.c. | 880 | See header of drivers/scsi/in2000.c. |
905 | 881 | ||
@@ -917,26 +893,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
917 | inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver | 893 | inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver |
918 | Format: <irq> | 894 | Format: <irq> |
919 | 895 | ||
920 | inttest= [IA64] | ||
921 | |||
922 | iomem= Disable strict checking of access to MMIO memory | ||
923 | strict regions from userspace. | ||
924 | relaxed | ||
925 | |||
926 | iommu= [x86] | ||
927 | off | ||
928 | force | ||
929 | noforce | ||
930 | biomerge | ||
931 | panic | ||
932 | nopanic | ||
933 | merge | ||
934 | nomerge | ||
935 | forcesac | ||
936 | soft | ||
937 | |||
938 | |||
939 | intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option | 896 | intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option |
897 | on | ||
898 | Enable intel iommu driver. | ||
940 | off | 899 | off |
941 | Disable intel iommu driver. | 900 | Disable intel iommu driver. |
942 | igfx_off [Default Off] | 901 | igfx_off [Default Off] |
@@ -957,6 +916,28 @@ and is between 256 and 4096 characters. It is defined in the file | |||
957 | result in a hardware IOTLB flush operation as opposed | 916 | result in a hardware IOTLB flush operation as opposed |
958 | to batching them for performance. | 917 | to batching them for performance. |
959 | 918 | ||
919 | inttest= [IA64] | ||
920 | |||
921 | iomem= Disable strict checking of access to MMIO memory | ||
922 | strict regions from userspace. | ||
923 | relaxed | ||
924 | |||
925 | iommu= [x86] | ||
926 | off | ||
927 | force | ||
928 | noforce | ||
929 | biomerge | ||
930 | panic | ||
931 | nopanic | ||
932 | merge | ||
933 | nomerge | ||
934 | forcesac | ||
935 | soft | ||
936 | |||
937 | io7= [HW] IO7 for Marvel based alpha systems | ||
938 | See comment before marvel_specify_io7 in | ||
939 | arch/alpha/kernel/core_marvel.c. | ||
940 | |||
960 | io_delay= [X86-32,X86-64] I/O delay method | 941 | io_delay= [X86-32,X86-64] I/O delay method |
961 | 0x80 | 942 | 0x80 |
962 | Standard port 0x80 based delay | 943 | Standard port 0x80 based delay |
@@ -967,10 +948,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
967 | none | 948 | none |
968 | No delay | 949 | No delay |
969 | 950 | ||
970 | io7= [HW] IO7 for Marvel based alpha systems | ||
971 | See comment before marvel_specify_io7 in | ||
972 | arch/alpha/kernel/core_marvel.c. | ||
973 | |||
974 | ip= [IP_PNP] | 951 | ip= [IP_PNP] |
975 | See Documentation/filesystems/nfsroot.txt. | 952 | See Documentation/filesystems/nfsroot.txt. |
976 | 953 | ||
@@ -981,12 +958,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
981 | ips= [HW,SCSI] Adaptec / IBM ServeRAID controller | 958 | ips= [HW,SCSI] Adaptec / IBM ServeRAID controller |
982 | See header of drivers/scsi/ips.c. | 959 | See header of drivers/scsi/ips.c. |
983 | 960 | ||
984 | ports= [IP_VS_FTP] IPVS ftp helper module | ||
985 | Default is 21. | ||
986 | Up to 8 (IP_VS_APP_MAX_PORTS) ports | ||
987 | may be specified. | ||
988 | Format: <port>,<port>.... | ||
989 | |||
990 | irqfixup [HW] | 961 | irqfixup [HW] |
991 | When an interrupt is not handled search all handlers | 962 | When an interrupt is not handled search all handlers |
992 | for it. Intended to get systems with badly broken | 963 | for it. Intended to get systems with badly broken |
@@ -1027,6 +998,8 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1027 | js= [HW,JOY] Analog joystick | 998 | js= [HW,JOY] Analog joystick |
1028 | See Documentation/input/joystick.txt. | 999 | See Documentation/input/joystick.txt. |
1029 | 1000 | ||
1001 | keepinitrd [HW,ARM] | ||
1002 | |||
1030 | kernelcore=nn[KMG] [KNL,X86-32,IA-64,PPC,X86-64] This parameter | 1003 | kernelcore=nn[KMG] [KNL,X86-32,IA-64,PPC,X86-64] This parameter |
1031 | specifies the amount of memory usable by the kernel | 1004 | specifies the amount of memory usable by the kernel |
1032 | for non-movable allocations. The requested amount is | 1005 | for non-movable allocations. The requested amount is |
@@ -1043,20 +1016,14 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1043 | use the HighMem zone if it exists, and the Normal | 1016 | use the HighMem zone if it exists, and the Normal |
1044 | zone if it does not. | 1017 | zone if it does not. |
1045 | 1018 | ||
1046 | movablecore=nn[KMG] [KNL,X86-32,IA-64,PPC,X86-64] This parameter | 1019 | kmemtrace.enable= [KNL,KMEMTRACE] Format: { yes | no } |
1047 | is similar to kernelcore except it specifies the | 1020 | Controls whether kmemtrace is enabled |
1048 | amount of memory used for migratable allocations. | 1021 | at boot-time. |
1049 | If both kernelcore and movablecore is specified, | ||
1050 | then kernelcore will be at *least* the specified | ||
1051 | value but may be more. If movablecore on its own | ||
1052 | is specified, the administrator must be careful | ||
1053 | that the amount of memory usable for all allocations | ||
1054 | is not too small. | ||
1055 | 1022 | ||
1056 | keepinitrd [HW,ARM] | 1023 | kmemtrace.subbufs=n [KNL,KMEMTRACE] Overrides the number of |
1057 | 1024 | subbufs kmemtrace's relay channel has. Set this | |
1058 | kstack=N [X86-32,X86-64] Print N words from the kernel stack | 1025 | higher than default (KMEMTRACE_N_SUBBUFS in code) if |
1059 | in oops dumps. | 1026 | you experience buffer overruns. |
1060 | 1027 | ||
1061 | kgdboc= [HW] kgdb over consoles. | 1028 | kgdboc= [HW] kgdb over consoles. |
1062 | Requires a tty driver that supports console polling. | 1029 | Requires a tty driver that supports console polling. |
@@ -1067,6 +1034,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1067 | Configure the RouterBoard 532 series on-chip | 1034 | Configure the RouterBoard 532 series on-chip |
1068 | Ethernet adapter MAC address. | 1035 | Ethernet adapter MAC address. |
1069 | 1036 | ||
1037 | kstack=N [X86-32,X86-64] Print N words from the kernel stack | ||
1038 | in oops dumps. | ||
1039 | |||
1070 | l2cr= [PPC] | 1040 | l2cr= [PPC] |
1071 | 1041 | ||
1072 | l3cr= [PPC] | 1042 | l3cr= [PPC] |
@@ -1212,9 +1182,8 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1212 | (machvec) in a generic kernel. | 1182 | (machvec) in a generic kernel. |
1213 | Example: machvec=hpzx1_swiotlb | 1183 | Example: machvec=hpzx1_swiotlb |
1214 | 1184 | ||
1215 | max_loop= [LOOP] Maximum number of loopback devices that can | 1185 | max_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory greater |
1216 | be mounted | 1186 | than or equal to this physical address is ignored. |
1217 | Format: <1-256> | ||
1218 | 1187 | ||
1219 | maxcpus= [SMP] Maximum number of processors that an SMP kernel | 1188 | maxcpus= [SMP] Maximum number of processors that an SMP kernel |
1220 | should make use of. maxcpus=n : n >= 0 limits the | 1189 | should make use of. maxcpus=n : n >= 0 limits the |
@@ -1222,8 +1191,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1222 | it is equivalent to "nosmp", which also disables | 1191 | it is equivalent to "nosmp", which also disables |
1223 | the IO APIC. | 1192 | the IO APIC. |
1224 | 1193 | ||
1225 | max_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory greater than | 1194 | max_loop= [LOOP] Maximum number of loopback devices that can |
1226 | or equal to this physical address is ignored. | 1195 | be mounted |
1196 | Format: <1-256> | ||
1227 | 1197 | ||
1228 | max_luns= [SCSI] Maximum number of LUNs to probe. | 1198 | max_luns= [SCSI] Maximum number of LUNs to probe. |
1229 | Should be between 1 and 2^32-1. | 1199 | Should be between 1 and 2^32-1. |
@@ -1306,8 +1276,13 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1306 | 1276 | ||
1307 | memtest= [KNL,X86] Enable memtest | 1277 | memtest= [KNL,X86] Enable memtest |
1308 | Format: <integer> | 1278 | Format: <integer> |
1309 | range: 0,4 : pattern number | ||
1310 | default : 0 <disable> | 1279 | default : 0 <disable> |
1280 | Specifies the number of memtest passes to be | ||
1281 | performed. Each pass selects another test | ||
1282 | pattern from a given set of patterns. Memtest | ||
1283 | fills the memory with this pattern, validates | ||
1284 | memory contents and reserves bad memory | ||
1285 | regions that are detected. | ||
1311 | 1286 | ||
1312 | meye.*= [HW] Set MotionEye Camera parameters | 1287 | meye.*= [HW] Set MotionEye Camera parameters |
1313 | See Documentation/video4linux/meye.txt. | 1288 | See Documentation/video4linux/meye.txt. |
@@ -1345,6 +1320,16 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1345 | mousedev.yres= [MOUSE] Vertical screen resolution, used for devices | 1320 | mousedev.yres= [MOUSE] Vertical screen resolution, used for devices |
1346 | reporting absolute coordinates, such as tablets | 1321 | reporting absolute coordinates, such as tablets |
1347 | 1322 | ||
1323 | movablecore=nn[KMG] [KNL,X86-32,IA-64,PPC,X86-64] This parameter | ||
1324 | is similar to kernelcore except it specifies the | ||
1325 | amount of memory used for migratable allocations. | ||
1326 | If both kernelcore and movablecore is specified, | ||
1327 | then kernelcore will be at *least* the specified | ||
1328 | value but may be more. If movablecore on its own | ||
1329 | is specified, the administrator must be careful | ||
1330 | that the amount of memory usable for all allocations | ||
1331 | is not too small. | ||
1332 | |||
1348 | mpu401= [HW,OSS] | 1333 | mpu401= [HW,OSS] |
1349 | Format: <io>,<irq> | 1334 | Format: <io>,<irq> |
1350 | 1335 | ||
@@ -1366,6 +1351,23 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1366 | [HW] Make the MicroTouch USB driver use raw coordinates | 1351 | [HW] Make the MicroTouch USB driver use raw coordinates |
1367 | ('y', default) or cooked coordinates ('n') | 1352 | ('y', default) or cooked coordinates ('n') |
1368 | 1353 | ||
1354 | mtrr_chunk_size=nn[KMG] [X86] | ||
1355 | used for mtrr cleanup. It is largest continous chunk | ||
1356 | that could hold holes aka. UC entries. | ||
1357 | |||
1358 | mtrr_gran_size=nn[KMG] [X86] | ||
1359 | Used for mtrr cleanup. It is granularity of mtrr block. | ||
1360 | Default is 1. | ||
1361 | Large value could prevent small alignment from | ||
1362 | using up MTRRs. | ||
1363 | |||
1364 | mtrr_spare_reg_nr=n [X86] | ||
1365 | Format: <integer> | ||
1366 | Range: 0,7 : spare reg number | ||
1367 | Default : 1 | ||
1368 | Used for mtrr cleanup. It is spare mtrr entries number. | ||
1369 | Set to 2 or more if your graphical card needs more. | ||
1370 | |||
1369 | n2= [NET] SDL Inc. RISCom/N2 synchronous serial card | 1371 | n2= [NET] SDL Inc. RISCom/N2 synchronous serial card |
1370 | 1372 | ||
1371 | NCR_D700= [HW,SCSI] | 1373 | NCR_D700= [HW,SCSI] |
@@ -1426,11 +1428,13 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1426 | 0 - turn nmi_watchdog off | 1428 | 0 - turn nmi_watchdog off |
1427 | 1 - use the IO-APIC timer for the NMI watchdog | 1429 | 1 - use the IO-APIC timer for the NMI watchdog |
1428 | 2 - use the local APIC for the NMI watchdog using | 1430 | 2 - use the local APIC for the NMI watchdog using |
1429 | a performance counter. Note: This will use one performance | 1431 | a performance counter. Note: This will use one |
1430 | counter and the local APIC's performance vector. | 1432 | performance counter and the local APIC's performance |
1431 | When panic is specified panic when an NMI watchdog timeout occurs. | 1433 | vector. |
1432 | This is useful when you use a panic=... timeout and need the box | 1434 | When panic is specified, panic when an NMI watchdog |
1433 | quickly up again. | 1435 | timeout occurs. |
1436 | This is useful when you use a panic=... timeout and | ||
1437 | need the box quickly up again. | ||
1434 | Instead of 1 and 2 it is possible to use the following | 1438 | Instead of 1 and 2 it is possible to use the following |
1435 | symbolic names: lapic and ioapic | 1439 | symbolic names: lapic and ioapic |
1436 | Example: nmi_watchdog=2 or nmi_watchdog=panic,lapic | 1440 | Example: nmi_watchdog=2 or nmi_watchdog=panic,lapic |
@@ -1439,6 +1443,16 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1439 | emulation library even if a 387 maths coprocessor | 1443 | emulation library even if a 387 maths coprocessor |
1440 | is present. | 1444 | is present. |
1441 | 1445 | ||
1446 | no_console_suspend | ||
1447 | [HW] Never suspend the console | ||
1448 | Disable suspending of consoles during suspend and | ||
1449 | hibernate operations. Once disabled, debugging | ||
1450 | messages can reach various consoles while the rest | ||
1451 | of the system is being put to sleep (ie, while | ||
1452 | debugging driver suspend/resume hooks). This may | ||
1453 | not work reliably with all consoles, but is known | ||
1454 | to work with serial and VGA consoles. | ||
1455 | |||
1442 | noaliencache [MM, NUMA, SLAB] Disables the allocation of alien | 1456 | noaliencache [MM, NUMA, SLAB] Disables the allocation of alien |
1443 | caches in the slab allocator. Saves per-node memory, | 1457 | caches in the slab allocator. Saves per-node memory, |
1444 | but will impact performance. | 1458 | but will impact performance. |
@@ -1453,6 +1467,8 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1453 | 1467 | ||
1454 | nocache [ARM] | 1468 | nocache [ARM] |
1455 | 1469 | ||
1470 | noclflush [BUGS=X86] Don't use the CLFLUSH instruction | ||
1471 | |||
1456 | nodelayacct [KNL] Disable per-task delay accounting | 1472 | nodelayacct [KNL] Disable per-task delay accounting |
1457 | 1473 | ||
1458 | nodisconnect [HW,SCSI,M68K] Disables SCSI disconnects. | 1474 | nodisconnect [HW,SCSI,M68K] Disables SCSI disconnects. |
@@ -1481,9 +1497,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1481 | register save and restore. The kernel will only save | 1497 | register save and restore. The kernel will only save |
1482 | legacy floating-point registers on task switch. | 1498 | legacy floating-point registers on task switch. |
1483 | 1499 | ||
1484 | noclflush [BUGS=X86] Don't use the CLFLUSH instruction | 1500 | nohlt [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or |
1485 | 1501 | wfi(ARM) instruction doesn't work correctly and not to | |
1486 | nohlt [BUGS=ARM,SH] | 1502 | use it. This is also useful when using JTAG debugger. |
1487 | 1503 | ||
1488 | no-hlt [BUGS=X86-32] Tells the kernel that the hlt | 1504 | no-hlt [BUGS=X86-32] Tells the kernel that the hlt |
1489 | instruction doesn't work correctly and not to | 1505 | instruction doesn't work correctly and not to |
@@ -1504,6 +1520,8 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1504 | Valid arguments: on, off | 1520 | Valid arguments: on, off |
1505 | Default: on | 1521 | Default: on |
1506 | 1522 | ||
1523 | noiotrap [SH] Disables trapped I/O port accesses. | ||
1524 | |||
1507 | noirqdebug [X86-32] Disables the code which attempts to detect and | 1525 | noirqdebug [X86-32] Disables the code which attempts to detect and |
1508 | disable unhandled interrupt sources. | 1526 | disable unhandled interrupt sources. |
1509 | 1527 | ||
@@ -1523,12 +1541,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1523 | 1541 | ||
1524 | nolapic_timer [X86-32,APIC] Do not use the local APIC timer. | 1542 | nolapic_timer [X86-32,APIC] Do not use the local APIC timer. |
1525 | 1543 | ||
1526 | nox2apic [X86-64,APIC] Do not enable x2APIC mode. | ||
1527 | |||
1528 | x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of | ||
1529 | default x2apic cluster mode on platforms | ||
1530 | supporting x2apic. | ||
1531 | |||
1532 | noltlbs [PPC] Do not use large page/tlb entries for kernel | 1544 | noltlbs [PPC] Do not use large page/tlb entries for kernel |
1533 | lowmem mapping on PPC40x. | 1545 | lowmem mapping on PPC40x. |
1534 | 1546 | ||
@@ -1539,6 +1551,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1539 | nomfgpt [X86-32] Disable Multi-Function General Purpose | 1551 | nomfgpt [X86-32] Disable Multi-Function General Purpose |
1540 | Timer usage (for AMD Geode machines). | 1552 | Timer usage (for AMD Geode machines). |
1541 | 1553 | ||
1554 | norandmaps Don't use address space randomization. Equivalent to | ||
1555 | echo 0 > /proc/sys/kernel/randomize_va_space | ||
1556 | |||
1542 | noreplace-paravirt [X86-32,PV_OPS] Don't patch paravirt_ops | 1557 | noreplace-paravirt [X86-32,PV_OPS] Don't patch paravirt_ops |
1543 | 1558 | ||
1544 | noreplace-smp [X86-32,SMP] Don't replace SMP instructions | 1559 | noreplace-smp [X86-32,SMP] Don't replace SMP instructions |
@@ -1563,7 +1578,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1563 | nosoftlockup [KNL] Disable the soft-lockup detector. | 1578 | nosoftlockup [KNL] Disable the soft-lockup detector. |
1564 | 1579 | ||
1565 | noswapaccount [KNL] Disable accounting of swap in memory resource | 1580 | noswapaccount [KNL] Disable accounting of swap in memory resource |
1566 | controller. (See Documentation/controllers/memory.txt) | 1581 | controller. (See Documentation/cgroups/memory.txt) |
1567 | 1582 | ||
1568 | nosync [HW,M68K] Disables sync negotiation for all devices. | 1583 | nosync [HW,M68K] Disables sync negotiation for all devices. |
1569 | 1584 | ||
@@ -1577,13 +1592,13 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1577 | purges which is reported from either PAL_VM_SUMMARY or | 1592 | purges which is reported from either PAL_VM_SUMMARY or |
1578 | SAL PALO. | 1593 | SAL PALO. |
1579 | 1594 | ||
1595 | nr_uarts= [SERIAL] maximum number of UARTs to be registered. | ||
1596 | |||
1580 | numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA. | 1597 | numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA. |
1581 | one of ['zone', 'node', 'default'] can be specified | 1598 | one of ['zone', 'node', 'default'] can be specified |
1582 | This can be set from sysctl after boot. | 1599 | This can be set from sysctl after boot. |
1583 | See Documentation/sysctl/vm.txt for details. | 1600 | See Documentation/sysctl/vm.txt for details. |
1584 | 1601 | ||
1585 | nr_uarts= [SERIAL] maximum number of UARTs to be registered. | ||
1586 | |||
1587 | ohci1394_dma=early [HW] enable debugging via the ohci1394 driver. | 1602 | ohci1394_dma=early [HW] enable debugging via the ohci1394 driver. |
1588 | See Documentation/debugging-via-ohci1394.txt for more | 1603 | See Documentation/debugging-via-ohci1394.txt for more |
1589 | info. | 1604 | info. |
@@ -1655,6 +1670,8 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1655 | See also Documentation/blockdev/paride.txt. | 1670 | See also Documentation/blockdev/paride.txt. |
1656 | 1671 | ||
1657 | pci=option[,option...] [PCI] various PCI subsystem options: | 1672 | pci=option[,option...] [PCI] various PCI subsystem options: |
1673 | earlydump [X86] dump PCI config space before the kernel | ||
1674 | changes anything | ||
1658 | off [X86] don't probe for the PCI bus | 1675 | off [X86] don't probe for the PCI bus |
1659 | bios [X86-32] force use of PCI BIOS, don't access | 1676 | bios [X86-32] force use of PCI BIOS, don't access |
1660 | the hardware directly. Use this if your machine | 1677 | the hardware directly. Use this if your machine |
@@ -1754,6 +1771,15 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1754 | cbmemsize=nn[KMG] The fixed amount of bus space which is | 1771 | cbmemsize=nn[KMG] The fixed amount of bus space which is |
1755 | reserved for the CardBus bridge's memory | 1772 | reserved for the CardBus bridge's memory |
1756 | window. The default value is 64 megabytes. | 1773 | window. The default value is 64 megabytes. |
1774 | resource_alignment= | ||
1775 | Format: | ||
1776 | [<order of align>@][<domain>:]<bus>:<slot>.<func>[; ...] | ||
1777 | Specifies alignment and device to reassign | ||
1778 | aligned memory resources. | ||
1779 | If <order of align> is not specified, | ||
1780 | PAGE_SIZE is used as alignment. | ||
1781 | PCI-PCI bridge can be specified, if resource | ||
1782 | windows need to be expanded. | ||
1757 | 1783 | ||
1758 | pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power | 1784 | pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power |
1759 | Management. | 1785 | Management. |
@@ -1812,11 +1838,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1812 | autoconfiguration. | 1838 | autoconfiguration. |
1813 | Ranges are in pairs (memory base and size). | 1839 | Ranges are in pairs (memory base and size). |
1814 | 1840 | ||
1815 | dynamic_printk Enables pr_debug()/dev_dbg() calls if | ||
1816 | CONFIG_DYNAMIC_PRINTK_DEBUG has been enabled. | ||
1817 | These can also be switched on/off via | ||
1818 | <debugfs>/dynamic_printk/modules | ||
1819 | |||
1820 | print-fatal-signals= | 1841 | print-fatal-signals= |
1821 | [KNL] debug: print fatal signals | 1842 | [KNL] debug: print fatal signals |
1822 | print-fatal-signals=1: print segfault info to | 1843 | print-fatal-signals=1: print segfault info to |
@@ -1826,6 +1847,14 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1826 | printk.time= Show timing data prefixed to each printk message line | 1847 | printk.time= Show timing data prefixed to each printk message line |
1827 | Format: <bool> (1/Y/y=enable, 0/N/n=disable) | 1848 | Format: <bool> (1/Y/y=enable, 0/N/n=disable) |
1828 | 1849 | ||
1850 | processor.max_cstate= [HW,ACPI] | ||
1851 | Limit processor to maximum C-state | ||
1852 | max_cstate=9 overrides any DMI blacklist limit. | ||
1853 | |||
1854 | processor.nocst [HW,ACPI] | ||
1855 | Ignore the _CST method to determine C-states, | ||
1856 | instead using the legacy FADT method | ||
1857 | |||
1829 | profile= [KNL] Enable kernel profiling via /proc/profile | 1858 | profile= [KNL] Enable kernel profiling via /proc/profile |
1830 | Format: [schedule,]<number> | 1859 | Format: [schedule,]<number> |
1831 | Param: "schedule" - profile schedule points. | 1860 | Param: "schedule" - profile schedule points. |
@@ -1835,14 +1864,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1835 | Requires CONFIG_SCHEDSTATS | 1864 | Requires CONFIG_SCHEDSTATS |
1836 | Param: "kvm" - profile VM exits. | 1865 | Param: "kvm" - profile VM exits. |
1837 | 1866 | ||
1838 | processor.max_cstate= [HW,ACPI] | ||
1839 | Limit processor to maximum C-state | ||
1840 | max_cstate=9 overrides any DMI blacklist limit. | ||
1841 | |||
1842 | processor.nocst [HW,ACPI] | ||
1843 | Ignore the _CST method to determine C-states, | ||
1844 | instead using the legacy FADT method | ||
1845 | |||
1846 | prompt_ramdisk= [RAM] List of RAM disks to prompt for floppy disk | 1867 | prompt_ramdisk= [RAM] List of RAM disks to prompt for floppy disk |
1847 | before loading. | 1868 | before loading. |
1848 | See Documentation/blockdev/ramdisk.txt. | 1869 | See Documentation/blockdev/ramdisk.txt. |
@@ -1907,7 +1928,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1907 | 1928 | ||
1908 | relax_domain_level= | 1929 | relax_domain_level= |
1909 | [KNL, SMP] Set scheduler's default relax_domain_level. | 1930 | [KNL, SMP] Set scheduler's default relax_domain_level. |
1910 | See Documentation/cpusets.txt. | 1931 | See Documentation/cgroups/cpusets.txt. |
1911 | 1932 | ||
1912 | reserve= [KNL,BUGS] Force the kernel to ignore some iomem area | 1933 | reserve= [KNL,BUGS] Force the kernel to ignore some iomem area |
1913 | 1934 | ||
@@ -1996,7 +2017,13 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1996 | allowing boot to proceed. none ignores them, expecting | 2017 | allowing boot to proceed. none ignores them, expecting |
1997 | user space to do the scan. | 2018 | user space to do the scan. |
1998 | 2019 | ||
1999 | selinux [SELINUX] Disable or enable SELinux at boot time. | 2020 | security= [SECURITY] Choose a security module to enable at boot. |
2021 | If this boot parameter is not specified, only the first | ||
2022 | security module asking for security registration will be | ||
2023 | loaded. An invalid security module name will be treated | ||
2024 | as if no module has been chosen. | ||
2025 | |||
2026 | selinux= [SELINUX] Disable or enable SELinux at boot time. | ||
2000 | Format: { "0" | "1" } | 2027 | Format: { "0" | "1" } |
2001 | See security/selinux/Kconfig help text. | 2028 | See security/selinux/Kconfig help text. |
2002 | 0 -- disable. | 2029 | 0 -- disable. |
@@ -2005,15 +2032,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2005 | If enabled at boot time, /selinux/disable can be used | 2032 | If enabled at boot time, /selinux/disable can be used |
2006 | later to disable prior to initial policy load. | 2033 | later to disable prior to initial policy load. |
2007 | 2034 | ||
2008 | selinux_compat_net = | ||
2009 | [SELINUX] Set initial selinux_compat_net flag value. | ||
2010 | Format: { "0" | "1" } | ||
2011 | 0 -- use new secmark-based packet controls | ||
2012 | 1 -- use legacy packet controls | ||
2013 | Default value is 0 (preferred). | ||
2014 | Value can be changed at runtime via | ||
2015 | /selinux/compat_net. | ||
2016 | |||
2017 | serialnumber [BUGS=X86-32] | 2035 | serialnumber [BUGS=X86-32] |
2018 | 2036 | ||
2019 | shapers= [NET] | 2037 | shapers= [NET] |
@@ -2325,6 +2343,8 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2325 | 2343 | ||
2326 | tp720= [HW,PS2] | 2344 | tp720= [HW,PS2] |
2327 | 2345 | ||
2346 | trace_buf_size=nn[KMG] [ftrace] will set tracing buffer size. | ||
2347 | |||
2328 | trix= [HW,OSS] MediaTrix AudioTrix Pro | 2348 | trix= [HW,OSS] MediaTrix AudioTrix Pro |
2329 | Format: | 2349 | Format: |
2330 | <io>,<irq>,<dma>,<dma2>,<sb_io>,<sb_irq>,<sb_dma>,<mpu_io>,<mpu_irq> | 2350 | <io>,<irq>,<dma>,<dma2>,<sb_io>,<sb_irq>,<sb_dma>,<mpu_io>,<mpu_irq> |
@@ -2427,9 +2447,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2427 | medium is write-protected). | 2447 | medium is write-protected). |
2428 | Example: quirks=0419:aaf5:rl,0421:0433:rc | 2448 | Example: quirks=0419:aaf5:rl,0421:0433:rc |
2429 | 2449 | ||
2430 | add_efi_memmap [EFI; x86-32,X86-64] Include EFI memory map in | ||
2431 | kernel's map of available physical RAM. | ||
2432 | |||
2433 | vdso= [X86-32,SH,x86-64] | 2450 | vdso= [X86-32,SH,x86-64] |
2434 | vdso=2: enable compat VDSO (default with COMPAT_VDSO) | 2451 | vdso=2: enable compat VDSO (default with COMPAT_VDSO) |
2435 | vdso=1: enable VDSO (default) | 2452 | vdso=1: enable VDSO (default) |
@@ -2447,7 +2464,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2447 | See Documentation/fb/modedb.txt. | 2464 | See Documentation/fb/modedb.txt. |
2448 | 2465 | ||
2449 | vga= [BOOT,X86-32] Select a particular video mode | 2466 | vga= [BOOT,X86-32] Select a particular video mode |
2450 | See Documentation/x86/i386/boot.txt and | 2467 | See Documentation/x86/boot.txt and |
2451 | Documentation/svga.txt. | 2468 | Documentation/svga.txt. |
2452 | Use vga=ask for menu. | 2469 | Use vga=ask for menu. |
2453 | This is actually a boot loader parameter; the value is | 2470 | This is actually a boot loader parameter; the value is |
@@ -2468,6 +2485,31 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2468 | vmpoff= [KNL,S390] Perform z/VM CP command after power off. | 2485 | vmpoff= [KNL,S390] Perform z/VM CP command after power off. |
2469 | Format: <command> | 2486 | Format: <command> |
2470 | 2487 | ||
2488 | vt.default_blu= [VT] | ||
2489 | Format: <blue0>,<blue1>,<blue2>,...,<blue15> | ||
2490 | Change the default blue palette of the console. | ||
2491 | This is a 16-member array composed of values | ||
2492 | ranging from 0-255. | ||
2493 | |||
2494 | vt.default_grn= [VT] | ||
2495 | Format: <green0>,<green1>,<green2>,...,<green15> | ||
2496 | Change the default green palette of the console. | ||
2497 | This is a 16-member array composed of values | ||
2498 | ranging from 0-255. | ||
2499 | |||
2500 | vt.default_red= [VT] | ||
2501 | Format: <red0>,<red1>,<red2>,...,<red15> | ||
2502 | Change the default red palette of the console. | ||
2503 | This is a 16-member array composed of values | ||
2504 | ranging from 0-255. | ||
2505 | |||
2506 | vt.default_utf8= | ||
2507 | [VT] | ||
2508 | Format=<0|1> | ||
2509 | Set system-wide default UTF-8 mode for all tty's. | ||
2510 | Default is 1, i.e. UTF-8 mode is enabled for all | ||
2511 | newly opened terminals. | ||
2512 | |||
2471 | waveartist= [HW,OSS] | 2513 | waveartist= [HW,OSS] |
2472 | Format: <io>,<irq>,<dma>,<dma2> | 2514 | Format: <io>,<irq>,<dma>,<dma2> |
2473 | 2515 | ||
@@ -2480,6 +2522,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2480 | wdt= [WDT] Watchdog | 2522 | wdt= [WDT] Watchdog |
2481 | See Documentation/watchdog/wdt.txt. | 2523 | See Documentation/watchdog/wdt.txt. |
2482 | 2524 | ||
2525 | x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of | ||
2526 | default x2apic cluster mode on platforms | ||
2527 | supporting x2apic. | ||
2528 | |||
2483 | xd= [HW,XT] Original XT pre-IDE (RLL encoded) disks. | 2529 | xd= [HW,XT] Original XT pre-IDE (RLL encoded) disks. |
2484 | xd_geo= See header of drivers/block/xd.c. | 2530 | xd_geo= See header of drivers/block/xd.c. |
2485 | 2531 | ||
@@ -2487,9 +2533,6 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2487 | Format: | 2533 | Format: |
2488 | <irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]] | 2534 | <irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]] |
2489 | 2535 | ||
2490 | norandmaps Don't use address space randomization. Equivalent to | ||
2491 | echo 0 > /proc/sys/kernel/randomize_va_space | ||
2492 | |||
2493 | ______________________________________________________________________ | 2536 | ______________________________________________________________________ |
2494 | 2537 | ||
2495 | TODO: | 2538 | TODO: |
diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index 48b3de90eb1e..1e7a769a10f9 100644 --- a/Documentation/kprobes.txt +++ b/Documentation/kprobes.txt | |||
@@ -212,7 +212,9 @@ hit, Kprobes calls kp->pre_handler. After the probed instruction | |||
212 | is single-stepped, Kprobe calls kp->post_handler. If a fault | 212 | is single-stepped, Kprobe calls kp->post_handler. If a fault |
213 | occurs during execution of kp->pre_handler or kp->post_handler, | 213 | occurs during execution of kp->pre_handler or kp->post_handler, |
214 | or during single-stepping of the probed instruction, Kprobes calls | 214 | or during single-stepping of the probed instruction, Kprobes calls |
215 | kp->fault_handler. Any or all handlers can be NULL. | 215 | kp->fault_handler. Any or all handlers can be NULL. If kp->flags |
216 | is set KPROBE_FLAG_DISABLED, that kp will be registered but disabled, | ||
217 | so, it's handlers aren't hit until calling enable_kprobe(kp). | ||
216 | 218 | ||
217 | NOTE: | 219 | NOTE: |
218 | 1. With the introduction of the "symbol_name" field to struct kprobe, | 220 | 1. With the introduction of the "symbol_name" field to struct kprobe, |
@@ -363,6 +365,26 @@ probes) in the specified array, they clear the addr field of those | |||
363 | incorrect probes. However, other probes in the array are | 365 | incorrect probes. However, other probes in the array are |
364 | unregistered correctly. | 366 | unregistered correctly. |
365 | 367 | ||
368 | 4.7 disable_*probe | ||
369 | |||
370 | #include <linux/kprobes.h> | ||
371 | int disable_kprobe(struct kprobe *kp); | ||
372 | int disable_kretprobe(struct kretprobe *rp); | ||
373 | int disable_jprobe(struct jprobe *jp); | ||
374 | |||
375 | Temporarily disables the specified *probe. You can enable it again by using | ||
376 | enable_*probe(). You must specify the probe which has been registered. | ||
377 | |||
378 | 4.8 enable_*probe | ||
379 | |||
380 | #include <linux/kprobes.h> | ||
381 | int enable_kprobe(struct kprobe *kp); | ||
382 | int enable_kretprobe(struct kretprobe *rp); | ||
383 | int enable_jprobe(struct jprobe *jp); | ||
384 | |||
385 | Enables *probe which has been disabled by disable_*probe(). You must specify | ||
386 | the probe which has been registered. | ||
387 | |||
366 | 5. Kprobes Features and Limitations | 388 | 5. Kprobes Features and Limitations |
367 | 389 | ||
368 | Kprobes allows multiple probes at the same address. Currently, | 390 | Kprobes allows multiple probes at the same address. Currently, |
@@ -500,10 +522,14 @@ the probe. If the probed function belongs to a module, the module name | |||
500 | is also specified. Following columns show probe status. If the probe is on | 522 | is also specified. Following columns show probe status. If the probe is on |
501 | a virtual address that is no longer valid (module init sections, module | 523 | a virtual address that is no longer valid (module init sections, module |
502 | virtual addresses that correspond to modules that've been unloaded), | 524 | virtual addresses that correspond to modules that've been unloaded), |
503 | such probes are marked with [GONE]. | 525 | such probes are marked with [GONE]. If the probe is temporarily disabled, |
526 | such probes are marked with [DISABLED]. | ||
504 | 527 | ||
505 | /debug/kprobes/enabled: Turn kprobes ON/OFF | 528 | /debug/kprobes/enabled: Turn kprobes ON/OFF forcibly. |
506 | 529 | ||
507 | Provides a knob to globally turn registered kprobes ON or OFF. By default, | 530 | Provides a knob to globally and forcibly turn registered kprobes ON or OFF. |
508 | all kprobes are enabled. By echoing "0" to this file, all registered probes | 531 | By default, all kprobes are enabled. By echoing "0" to this file, all |
509 | will be disarmed, till such time a "1" is echoed to this file. | 532 | registered probes will be disarmed, till such time a "1" is echoed to this |
533 | file. Note that this knob just disarms and arms all kprobes and doesn't | ||
534 | change each probe's disabling state. This means that disabled kprobes (marked | ||
535 | [DISABLED]) will be not enabled if you turn ON all kprobes by this knob. | ||
diff --git a/Documentation/laptops/acer-wmi.txt b/Documentation/laptops/acer-wmi.txt index 2b3a6b5260bf..5ee2a02b3b40 100644 --- a/Documentation/laptops/acer-wmi.txt +++ b/Documentation/laptops/acer-wmi.txt | |||
@@ -1,9 +1,9 @@ | |||
1 | Acer Laptop WMI Extras Driver | 1 | Acer Laptop WMI Extras Driver |
2 | http://code.google.com/p/aceracpi | 2 | http://code.google.com/p/aceracpi |
3 | Version 0.2 | 3 | Version 0.3 |
4 | 18th August 2008 | 4 | 4th April 2009 |
5 | 5 | ||
6 | Copyright 2007-2008 Carlos Corbacho <carlos@strangeworlds.co.uk> | 6 | Copyright 2007-2009 Carlos Corbacho <carlos@strangeworlds.co.uk> |
7 | 7 | ||
8 | acer-wmi is a driver to allow you to control various parts of your Acer laptop | 8 | acer-wmi is a driver to allow you to control various parts of your Acer laptop |
9 | hardware under Linux which are exposed via ACPI-WMI. | 9 | hardware under Linux which are exposed via ACPI-WMI. |
@@ -36,6 +36,10 @@ not possible in kernel space from a 64 bit OS. | |||
36 | Supported Hardware | 36 | Supported Hardware |
37 | ****************** | 37 | ****************** |
38 | 38 | ||
39 | NOTE: The Acer Aspire One is not supported hardware. It cannot work with | ||
40 | acer-wmi until Acer fix their ACPI-WMI implementation on them, so has been | ||
41 | blacklisted until that happens. | ||
42 | |||
39 | Please see the website for the current list of known working hardare: | 43 | Please see the website for the current list of known working hardare: |
40 | 44 | ||
41 | http://code.google.com/p/aceracpi/wiki/SupportedHardware | 45 | http://code.google.com/p/aceracpi/wiki/SupportedHardware |
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 41bc99fa1884..3d7650768bb5 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt | |||
@@ -20,7 +20,8 @@ moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel | |||
20 | kernel 2.6.29 and release 0.22. | 20 | kernel 2.6.29 and release 0.22. |
21 | 21 | ||
22 | The driver is named "thinkpad-acpi". In some places, like module | 22 | The driver is named "thinkpad-acpi". In some places, like module |
23 | names, "thinkpad_acpi" is used because of userspace issues. | 23 | names and log messages, "thinkpad_acpi" is used because of userspace |
24 | issues. | ||
24 | 25 | ||
25 | "tpacpi" is used as a shorthand where "thinkpad-acpi" would be too | 26 | "tpacpi" is used as a shorthand where "thinkpad-acpi" would be too |
26 | long due to length limitations on some Linux kernel versions. | 27 | long due to length limitations on some Linux kernel versions. |
@@ -37,7 +38,7 @@ detailed description): | |||
37 | - ThinkLight on and off | 38 | - ThinkLight on and off |
38 | - limited docking and undocking | 39 | - limited docking and undocking |
39 | - UltraBay eject | 40 | - UltraBay eject |
40 | - CMOS control | 41 | - CMOS/UCMS control |
41 | - LED control | 42 | - LED control |
42 | - ACPI sounds | 43 | - ACPI sounds |
43 | - temperature sensors | 44 | - temperature sensors |
@@ -46,6 +47,7 @@ detailed description): | |||
46 | - Volume control | 47 | - Volume control |
47 | - Fan control and monitoring: fan speed, fan enable/disable | 48 | - Fan control and monitoring: fan speed, fan enable/disable |
48 | - WAN enable and disable | 49 | - WAN enable and disable |
50 | - UWB enable and disable | ||
49 | 51 | ||
50 | A compatibility table by model and feature is maintained on the web | 52 | A compatibility table by model and feature is maintained on the web |
51 | site, http://ibm-acpi.sf.net/. I appreciate any success or failure | 53 | site, http://ibm-acpi.sf.net/. I appreciate any success or failure |
@@ -53,7 +55,7 @@ reports, especially if they add to or correct the compatibility table. | |||
53 | Please include the following information in your report: | 55 | Please include the following information in your report: |
54 | 56 | ||
55 | - ThinkPad model name | 57 | - ThinkPad model name |
56 | - a copy of your DSDT, from /proc/acpi/dsdt | 58 | - a copy of your ACPI tables, using the "acpidump" utility |
57 | - a copy of the output of dmidecode, with serial numbers | 59 | - a copy of the output of dmidecode, with serial numbers |
58 | and UUIDs masked off | 60 | and UUIDs masked off |
59 | - which driver features work and which don't | 61 | - which driver features work and which don't |
@@ -66,17 +68,18 @@ Installation | |||
66 | ------------ | 68 | ------------ |
67 | 69 | ||
68 | If you are compiling this driver as included in the Linux kernel | 70 | If you are compiling this driver as included in the Linux kernel |
69 | sources, simply enable the CONFIG_THINKPAD_ACPI option, and optionally | 71 | sources, look for the CONFIG_THINKPAD_ACPI Kconfig option. |
70 | enable the CONFIG_THINKPAD_ACPI_BAY option if you want the | 72 | It is located on the menu path: "Device Drivers" -> "X86 Platform |
71 | thinkpad-specific bay functionality. | 73 | Specific Device Drivers" -> "ThinkPad ACPI Laptop Extras". |
74 | |||
72 | 75 | ||
73 | Features | 76 | Features |
74 | -------- | 77 | -------- |
75 | 78 | ||
76 | The driver exports two different interfaces to userspace, which can be | 79 | The driver exports two different interfaces to userspace, which can be |
77 | used to access the features it provides. One is a legacy procfs-based | 80 | used to access the features it provides. One is a legacy procfs-based |
78 | interface, which will be removed at some time in the distant future. | 81 | interface, which will be removed at some time in the future. The other |
79 | The other is a new sysfs-based interface which is not complete yet. | 82 | is a new sysfs-based interface which is not complete yet. |
80 | 83 | ||
81 | The procfs interface creates the /proc/acpi/ibm directory. There is a | 84 | The procfs interface creates the /proc/acpi/ibm directory. There is a |
82 | file under that directory for each feature it supports. The procfs | 85 | file under that directory for each feature it supports. The procfs |
@@ -111,15 +114,17 @@ The version of thinkpad-acpi's sysfs interface is exported by the driver | |||
111 | as a driver attribute (see below). | 114 | as a driver attribute (see below). |
112 | 115 | ||
113 | Sysfs driver attributes are on the driver's sysfs attribute space, | 116 | Sysfs driver attributes are on the driver's sysfs attribute space, |
114 | for 2.6.23 this is /sys/bus/platform/drivers/thinkpad_acpi/ and | 117 | for 2.6.23+ this is /sys/bus/platform/drivers/thinkpad_acpi/ and |
115 | /sys/bus/platform/drivers/thinkpad_hwmon/ | 118 | /sys/bus/platform/drivers/thinkpad_hwmon/ |
116 | 119 | ||
117 | Sysfs device attributes are on the thinkpad_acpi device sysfs attribute | 120 | Sysfs device attributes are on the thinkpad_acpi device sysfs attribute |
118 | space, for 2.6.23 this is /sys/devices/platform/thinkpad_acpi/. | 121 | space, for 2.6.23+ this is /sys/devices/platform/thinkpad_acpi/. |
119 | 122 | ||
120 | Sysfs device attributes for the sensors and fan are on the | 123 | Sysfs device attributes for the sensors and fan are on the |
121 | thinkpad_hwmon device's sysfs attribute space, but you should locate it | 124 | thinkpad_hwmon device's sysfs attribute space, but you should locate it |
122 | looking for a hwmon device with the name attribute of "thinkpad". | 125 | looking for a hwmon device with the name attribute of "thinkpad", or |
126 | better yet, through libsensors. | ||
127 | |||
123 | 128 | ||
124 | Driver version | 129 | Driver version |
125 | -------------- | 130 | -------------- |
@@ -129,6 +134,7 @@ sysfs driver attribute: version | |||
129 | 134 | ||
130 | The driver name and version. No commands can be written to this file. | 135 | The driver name and version. No commands can be written to this file. |
131 | 136 | ||
137 | |||
132 | Sysfs interface version | 138 | Sysfs interface version |
133 | ----------------------- | 139 | ----------------------- |
134 | 140 | ||
@@ -160,6 +166,7 @@ expect that an attribute might not be there, and deal with it properly | |||
160 | (an attribute not being there *is* a valid way to make it clear that a | 166 | (an attribute not being there *is* a valid way to make it clear that a |
161 | feature is not available in sysfs). | 167 | feature is not available in sysfs). |
162 | 168 | ||
169 | |||
163 | Hot keys | 170 | Hot keys |
164 | -------- | 171 | -------- |
165 | 172 | ||
@@ -172,17 +179,14 @@ system. Enabling the hotkey functionality of thinkpad-acpi signals the | |||
172 | firmware that such a driver is present, and modifies how the ThinkPad | 179 | firmware that such a driver is present, and modifies how the ThinkPad |
173 | firmware will behave in many situations. | 180 | firmware will behave in many situations. |
174 | 181 | ||
175 | The driver enables the hot key feature automatically when loaded. The | 182 | The driver enables the HKEY ("hot key") event reporting automatically |
176 | feature can later be disabled and enabled back at runtime. The driver | 183 | when loaded, and disables it when it is removed. |
177 | will also restore the hot key feature to its previous state and mask | ||
178 | when it is unloaded. | ||
179 | 184 | ||
180 | When the hotkey feature is enabled and the hot key mask is set (see | 185 | The driver will report HKEY events in the following format: |
181 | below), the driver will report HKEY events in the following format: | ||
182 | 186 | ||
183 | ibm/hotkey HKEY 00000080 0000xxxx | 187 | ibm/hotkey HKEY 00000080 0000xxxx |
184 | 188 | ||
185 | Some of these events refer to hot key presses, but not all. | 189 | Some of these events refer to hot key presses, but not all of them. |
186 | 190 | ||
187 | The driver will generate events over the input layer for hot keys and | 191 | The driver will generate events over the input layer for hot keys and |
188 | radio switches, and over the ACPI netlink layer for other events. The | 192 | radio switches, and over the ACPI netlink layer for other events. The |
@@ -214,13 +218,17 @@ procfs notes: | |||
214 | 218 | ||
215 | The following commands can be written to the /proc/acpi/ibm/hotkey file: | 219 | The following commands can be written to the /proc/acpi/ibm/hotkey file: |
216 | 220 | ||
217 | echo enable > /proc/acpi/ibm/hotkey -- enable the hot keys feature | ||
218 | echo disable > /proc/acpi/ibm/hotkey -- disable the hot keys feature | ||
219 | echo 0xffffffff > /proc/acpi/ibm/hotkey -- enable all hot keys | 221 | echo 0xffffffff > /proc/acpi/ibm/hotkey -- enable all hot keys |
220 | echo 0 > /proc/acpi/ibm/hotkey -- disable all possible hot keys | 222 | echo 0 > /proc/acpi/ibm/hotkey -- disable all possible hot keys |
221 | ... any other 8-hex-digit mask ... | 223 | ... any other 8-hex-digit mask ... |
222 | echo reset > /proc/acpi/ibm/hotkey -- restore the original mask | 224 | echo reset > /proc/acpi/ibm/hotkey -- restore the original mask |
223 | 225 | ||
226 | The following commands have been deprecated and will cause the kernel | ||
227 | to log a warning: | ||
228 | |||
229 | echo enable > /proc/acpi/ibm/hotkey -- does nothing | ||
230 | echo disable > /proc/acpi/ibm/hotkey -- returns an error | ||
231 | |||
224 | The procfs interface does not support NVRAM polling control. So as to | 232 | The procfs interface does not support NVRAM polling control. So as to |
225 | maintain maximum bug-to-bug compatibility, it does not report any masks, | 233 | maintain maximum bug-to-bug compatibility, it does not report any masks, |
226 | nor does it allow one to manipulate the hot key mask when the firmware | 234 | nor does it allow one to manipulate the hot key mask when the firmware |
@@ -229,12 +237,9 @@ does not support masks at all, even if NVRAM polling is in use. | |||
229 | sysfs notes: | 237 | sysfs notes: |
230 | 238 | ||
231 | hotkey_bios_enabled: | 239 | hotkey_bios_enabled: |
232 | Returns the status of the hot keys feature when | 240 | DEPRECATED, WILL BE REMOVED SOON. |
233 | thinkpad-acpi was loaded. Upon module unload, the hot | ||
234 | key feature status will be restored to this value. | ||
235 | 241 | ||
236 | 0: hot keys were disabled | 242 | Returns 0. |
237 | 1: hot keys were enabled (unusual) | ||
238 | 243 | ||
239 | hotkey_bios_mask: | 244 | hotkey_bios_mask: |
240 | Returns the hot keys mask when thinkpad-acpi was loaded. | 245 | Returns the hot keys mask when thinkpad-acpi was loaded. |
@@ -242,13 +247,10 @@ sysfs notes: | |||
242 | to this value. | 247 | to this value. |
243 | 248 | ||
244 | hotkey_enable: | 249 | hotkey_enable: |
245 | Enables/disables the hot keys feature in the ACPI | 250 | DEPRECATED, WILL BE REMOVED SOON. |
246 | firmware, and reports current status of the hot keys | ||
247 | feature. Has no effect on the NVRAM hot key polling | ||
248 | functionality. | ||
249 | 251 | ||
250 | 0: disables the hot keys feature / feature disabled | 252 | 0: returns -EPERM |
251 | 1: enables the hot keys feature / feature enabled | 253 | 1: does nothing |
252 | 254 | ||
253 | hotkey_mask: | 255 | hotkey_mask: |
254 | bit mask to enable driver-handling (and depending on | 256 | bit mask to enable driver-handling (and depending on |
@@ -618,6 +620,7 @@ For Lenovo models *with* ACPI backlight control: | |||
618 | and map them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN. Process | 620 | and map them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN. Process |
619 | these keys on userspace somehow (e.g. by calling xbacklight). | 621 | these keys on userspace somehow (e.g. by calling xbacklight). |
620 | 622 | ||
623 | |||
621 | Bluetooth | 624 | Bluetooth |
622 | --------- | 625 | --------- |
623 | 626 | ||
@@ -628,6 +631,9 @@ sysfs rfkill class: switch "tpacpi_bluetooth_sw" | |||
628 | This feature shows the presence and current state of a ThinkPad | 631 | This feature shows the presence and current state of a ThinkPad |
629 | Bluetooth device in the internal ThinkPad CDC slot. | 632 | Bluetooth device in the internal ThinkPad CDC slot. |
630 | 633 | ||
634 | If the ThinkPad supports it, the Bluetooth state is stored in NVRAM, | ||
635 | so it is kept across reboots and power-off. | ||
636 | |||
631 | Procfs notes: | 637 | Procfs notes: |
632 | 638 | ||
633 | If Bluetooth is installed, the following commands can be used: | 639 | If Bluetooth is installed, the following commands can be used: |
@@ -652,6 +658,7 @@ Sysfs notes: | |||
652 | rfkill controller switch "tpacpi_bluetooth_sw": refer to | 658 | rfkill controller switch "tpacpi_bluetooth_sw": refer to |
653 | Documentation/rfkill.txt for details. | 659 | Documentation/rfkill.txt for details. |
654 | 660 | ||
661 | |||
655 | Video output control -- /proc/acpi/ibm/video | 662 | Video output control -- /proc/acpi/ibm/video |
656 | -------------------------------------------- | 663 | -------------------------------------------- |
657 | 664 | ||
@@ -693,11 +700,8 @@ Fn-F7 from working. This also disables the video output switching | |||
693 | features of this driver, as it uses the same ACPI methods as | 700 | features of this driver, as it uses the same ACPI methods as |
694 | Fn-F7. Video switching on the console should still work. | 701 | Fn-F7. Video switching on the console should still work. |
695 | 702 | ||
696 | UPDATE: There's now a patch for the X.org Radeon driver which | 703 | UPDATE: refer to https://bugs.freedesktop.org/show_bug.cgi?id=2000 |
697 | addresses this issue. Some people are reporting success with the patch | ||
698 | while others are still having problems. For more information: | ||
699 | 704 | ||
700 | https://bugs.freedesktop.org/show_bug.cgi?id=2000 | ||
701 | 705 | ||
702 | ThinkLight control | 706 | ThinkLight control |
703 | ------------------ | 707 | ------------------ |
@@ -720,10 +724,11 @@ The ThinkLight sysfs interface is documented by the LED class | |||
720 | documentation, in Documentation/leds-class.txt. The ThinkLight LED name | 724 | documentation, in Documentation/leds-class.txt. The ThinkLight LED name |
721 | is "tpacpi::thinklight". | 725 | is "tpacpi::thinklight". |
722 | 726 | ||
723 | Due to limitations in the sysfs LED class, if the status of the thinklight | 727 | Due to limitations in the sysfs LED class, if the status of the ThinkLight |
724 | cannot be read or if it is unknown, thinkpad-acpi will report it as "off". | 728 | cannot be read or if it is unknown, thinkpad-acpi will report it as "off". |
725 | It is impossible to know if the status returned through sysfs is valid. | 729 | It is impossible to know if the status returned through sysfs is valid. |
726 | 730 | ||
731 | |||
727 | Docking / undocking -- /proc/acpi/ibm/dock | 732 | Docking / undocking -- /proc/acpi/ibm/dock |
728 | ------------------------------------------ | 733 | ------------------------------------------ |
729 | 734 | ||
@@ -784,6 +789,7 @@ the only docking stations currently supported are the X-series | |||
784 | UltraBase docks and "dumb" port replicators like the Mini Dock (the | 789 | UltraBase docks and "dumb" port replicators like the Mini Dock (the |
785 | latter don't need any ACPI support, actually). | 790 | latter don't need any ACPI support, actually). |
786 | 791 | ||
792 | |||
787 | UltraBay eject -- /proc/acpi/ibm/bay | 793 | UltraBay eject -- /proc/acpi/ibm/bay |
788 | ------------------------------------ | 794 | ------------------------------------ |
789 | 795 | ||
@@ -847,8 +853,9 @@ supported. Use "eject2" instead of "eject" for the second bay. | |||
847 | Note: the UltraBay eject support on the 600e/x, A22p and A3x is | 853 | Note: the UltraBay eject support on the 600e/x, A22p and A3x is |
848 | EXPERIMENTAL and may not work as expected. USE WITH CAUTION! | 854 | EXPERIMENTAL and may not work as expected. USE WITH CAUTION! |
849 | 855 | ||
850 | CMOS control | 856 | |
851 | ------------ | 857 | CMOS/UCMS control |
858 | ----------------- | ||
852 | 859 | ||
853 | procfs: /proc/acpi/ibm/cmos | 860 | procfs: /proc/acpi/ibm/cmos |
854 | sysfs device attribute: cmos_command | 861 | sysfs device attribute: cmos_command |
@@ -882,6 +889,7 @@ The cmos command interface is prone to firmware split-brain problems, as | |||
882 | in newer ThinkPads it is just a compatibility layer. Do not use it, it is | 889 | in newer ThinkPads it is just a compatibility layer. Do not use it, it is |
883 | exported just as a debug tool. | 890 | exported just as a debug tool. |
884 | 891 | ||
892 | |||
885 | LED control | 893 | LED control |
886 | ----------- | 894 | ----------- |
887 | 895 | ||
@@ -893,6 +901,17 @@ some older ThinkPad models, it is possible to query the status of the | |||
893 | LED indicators as well. Newer ThinkPads cannot query the real status | 901 | LED indicators as well. Newer ThinkPads cannot query the real status |
894 | of the LED indicators. | 902 | of the LED indicators. |
895 | 903 | ||
904 | Because misuse of the LEDs could induce an unaware user to perform | ||
905 | dangerous actions (like undocking or ejecting a bay device while the | ||
906 | buses are still active), or mask an important alarm (such as a nearly | ||
907 | empty battery, or a broken battery), access to most LEDs is | ||
908 | restricted. | ||
909 | |||
910 | Unrestricted access to all LEDs requires that thinkpad-acpi be | ||
911 | compiled with the CONFIG_THINKPAD_ACPI_UNSAFE_LEDS option enabled. | ||
912 | Distributions must never enable this option. Individual users that | ||
913 | are aware of the consequences are welcome to enabling it. | ||
914 | |||
896 | procfs notes: | 915 | procfs notes: |
897 | 916 | ||
898 | The available commands are: | 917 | The available commands are: |
@@ -939,6 +958,7 @@ ThinkPad indicator LED should blink in hardware accelerated mode, use the | |||
939 | "timer" trigger, and leave the delay_on and delay_off parameters set to | 958 | "timer" trigger, and leave the delay_on and delay_off parameters set to |
940 | zero (to request hardware acceleration autodetection). | 959 | zero (to request hardware acceleration autodetection). |
941 | 960 | ||
961 | |||
942 | ACPI sounds -- /proc/acpi/ibm/beep | 962 | ACPI sounds -- /proc/acpi/ibm/beep |
943 | ---------------------------------- | 963 | ---------------------------------- |
944 | 964 | ||
@@ -968,6 +988,7 @@ X40: | |||
968 | 16 - one medium-pitched beep repeating constantly, stop with 17 | 988 | 16 - one medium-pitched beep repeating constantly, stop with 17 |
969 | 17 - stop 16 | 989 | 17 - stop 16 |
970 | 990 | ||
991 | |||
971 | Temperature sensors | 992 | Temperature sensors |
972 | ------------------- | 993 | ------------------- |
973 | 994 | ||
@@ -1115,6 +1136,7 @@ registers contain the current battery capacity, etc. If you experiment | |||
1115 | with this, do send me your results (including some complete dumps with | 1136 | with this, do send me your results (including some complete dumps with |
1116 | a description of the conditions when they were taken.) | 1137 | a description of the conditions when they were taken.) |
1117 | 1138 | ||
1139 | |||
1118 | LCD brightness control | 1140 | LCD brightness control |
1119 | ---------------------- | 1141 | ---------------------- |
1120 | 1142 | ||
@@ -1124,10 +1146,9 @@ sysfs backlight device "thinkpad_screen" | |||
1124 | This feature allows software control of the LCD brightness on ThinkPad | 1146 | This feature allows software control of the LCD brightness on ThinkPad |
1125 | models which don't have a hardware brightness slider. | 1147 | models which don't have a hardware brightness slider. |
1126 | 1148 | ||
1127 | It has some limitations: the LCD backlight cannot be actually turned on or | 1149 | It has some limitations: the LCD backlight cannot be actually turned |
1128 | off by this interface, and in many ThinkPad models, the "dim while on | 1150 | on or off by this interface, it just controls the backlight brightness |
1129 | battery" functionality will be enabled by the BIOS when this interface is | 1151 | level. |
1130 | used, and cannot be controlled. | ||
1131 | 1152 | ||
1132 | On IBM (and some of the earlier Lenovo) ThinkPads, the backlight control | 1153 | On IBM (and some of the earlier Lenovo) ThinkPads, the backlight control |
1133 | has eight brightness levels, ranging from 0 to 7. Some of the levels | 1154 | has eight brightness levels, ranging from 0 to 7. Some of the levels |
@@ -1136,10 +1157,15 @@ display backlight brightness control methods have 16 levels, ranging | |||
1136 | from 0 to 15. | 1157 | from 0 to 15. |
1137 | 1158 | ||
1138 | There are two interfaces to the firmware for direct brightness control, | 1159 | There are two interfaces to the firmware for direct brightness control, |
1139 | EC and CMOS. To select which one should be used, use the | 1160 | EC and UCMS (or CMOS). To select which one should be used, use the |
1140 | brightness_mode module parameter: brightness_mode=1 selects EC mode, | 1161 | brightness_mode module parameter: brightness_mode=1 selects EC mode, |
1141 | brightness_mode=2 selects CMOS mode, brightness_mode=3 selects both EC | 1162 | brightness_mode=2 selects UCMS mode, brightness_mode=3 selects EC |
1142 | and CMOS. The driver tries to auto-detect which interface to use. | 1163 | mode with NVRAM backing (so that brightness changes are remembered |
1164 | across shutdown/reboot). | ||
1165 | |||
1166 | The driver tries to select which interface to use from a table of | ||
1167 | defaults for each ThinkPad model. If it makes a wrong choice, please | ||
1168 | report this as a bug, so that we can fix it. | ||
1143 | 1169 | ||
1144 | When display backlight brightness controls are available through the | 1170 | When display backlight brightness controls are available through the |
1145 | standard ACPI interface, it is best to use it instead of this direct | 1171 | standard ACPI interface, it is best to use it instead of this direct |
@@ -1201,6 +1227,7 @@ WARNING: | |||
1201 | and maybe reduce the life of the backlight lamps by needlessly kicking | 1227 | and maybe reduce the life of the backlight lamps by needlessly kicking |
1202 | its level up and down at every change. | 1228 | its level up and down at every change. |
1203 | 1229 | ||
1230 | |||
1204 | Volume control -- /proc/acpi/ibm/volume | 1231 | Volume control -- /proc/acpi/ibm/volume |
1205 | --------------------------------------- | 1232 | --------------------------------------- |
1206 | 1233 | ||
@@ -1217,6 +1244,11 @@ distinct. The unmute the volume after the mute command, use either the | |||
1217 | up or down command (the level command will not unmute the volume). | 1244 | up or down command (the level command will not unmute the volume). |
1218 | The current volume level and mute state is shown in the file. | 1245 | The current volume level and mute state is shown in the file. |
1219 | 1246 | ||
1247 | The ALSA mixer interface to this feature is still missing, but patches | ||
1248 | to add it exist. That problem should be addressed in the not so | ||
1249 | distant future. | ||
1250 | |||
1251 | |||
1220 | Fan control and monitoring: fan speed, fan enable/disable | 1252 | Fan control and monitoring: fan speed, fan enable/disable |
1221 | --------------------------------------------------------- | 1253 | --------------------------------------------------------- |
1222 | 1254 | ||
@@ -1383,8 +1415,11 @@ procfs: /proc/acpi/ibm/wan | |||
1383 | sysfs device attribute: wwan_enable (deprecated) | 1415 | sysfs device attribute: wwan_enable (deprecated) |
1384 | sysfs rfkill class: switch "tpacpi_wwan_sw" | 1416 | sysfs rfkill class: switch "tpacpi_wwan_sw" |
1385 | 1417 | ||
1386 | This feature shows the presence and current state of a W-WAN (Sierra | 1418 | This feature shows the presence and current state of the built-in |
1387 | Wireless EV-DO) device. | 1419 | Wireless WAN device. |
1420 | |||
1421 | If the ThinkPad supports it, the WWAN state is stored in NVRAM, | ||
1422 | so it is kept across reboots and power-off. | ||
1388 | 1423 | ||
1389 | It was tested on a Lenovo ThinkPad X60. It should probably work on other | 1424 | It was tested on a Lenovo ThinkPad X60. It should probably work on other |
1390 | ThinkPad models which come with this module installed. | 1425 | ThinkPad models which come with this module installed. |
@@ -1413,6 +1448,7 @@ Sysfs notes: | |||
1413 | rfkill controller switch "tpacpi_wwan_sw": refer to | 1448 | rfkill controller switch "tpacpi_wwan_sw": refer to |
1414 | Documentation/rfkill.txt for details. | 1449 | Documentation/rfkill.txt for details. |
1415 | 1450 | ||
1451 | |||
1416 | EXPERIMENTAL: UWB | 1452 | EXPERIMENTAL: UWB |
1417 | ----------------- | 1453 | ----------------- |
1418 | 1454 | ||
@@ -1431,6 +1467,7 @@ Sysfs notes: | |||
1431 | rfkill controller switch "tpacpi_uwb_sw": refer to | 1467 | rfkill controller switch "tpacpi_uwb_sw": refer to |
1432 | Documentation/rfkill.txt for details. | 1468 | Documentation/rfkill.txt for details. |
1433 | 1469 | ||
1470 | |||
1434 | Multiple Commands, Module Parameters | 1471 | Multiple Commands, Module Parameters |
1435 | ------------------------------------ | 1472 | ------------------------------------ |
1436 | 1473 | ||
@@ -1445,6 +1482,7 @@ for example: | |||
1445 | 1482 | ||
1446 | modprobe thinkpad_acpi hotkey=enable,0xffff video=auto_disable | 1483 | modprobe thinkpad_acpi hotkey=enable,0xffff video=auto_disable |
1447 | 1484 | ||
1485 | |||
1448 | Enabling debugging output | 1486 | Enabling debugging output |
1449 | ------------------------- | 1487 | ------------------------- |
1450 | 1488 | ||
@@ -1457,8 +1495,15 @@ will enable all debugging output classes. It takes a bitmask, so | |||
1457 | to enable more than one output class, just add their values. | 1495 | to enable more than one output class, just add their values. |
1458 | 1496 | ||
1459 | Debug bitmask Description | 1497 | Debug bitmask Description |
1498 | 0x8000 Disclose PID of userspace programs | ||
1499 | accessing some functions of the driver | ||
1460 | 0x0001 Initialization and probing | 1500 | 0x0001 Initialization and probing |
1461 | 0x0002 Removal | 1501 | 0x0002 Removal |
1502 | 0x0004 RF Transmitter control (RFKILL) | ||
1503 | (bluetooth, WWAN, UWB...) | ||
1504 | 0x0008 HKEY event interface, hotkeys | ||
1505 | 0x0010 Fan control | ||
1506 | 0x0020 Backlight brightness | ||
1462 | 1507 | ||
1463 | There is also a kernel build option to enable more debugging | 1508 | There is also a kernel build option to enable more debugging |
1464 | information, which may be necessary to debug driver problems. | 1509 | information, which may be necessary to debug driver problems. |
@@ -1467,6 +1512,7 @@ The level of debugging information output by the driver can be changed | |||
1467 | at runtime through sysfs, using the driver attribute debug_level. The | 1512 | at runtime through sysfs, using the driver attribute debug_level. The |
1468 | attribute takes the same bitmask as the debug module parameter above. | 1513 | attribute takes the same bitmask as the debug module parameter above. |
1469 | 1514 | ||
1515 | |||
1470 | Force loading of module | 1516 | Force loading of module |
1471 | ----------------------- | 1517 | ----------------------- |
1472 | 1518 | ||
@@ -1505,3 +1551,7 @@ Sysfs interface changelog: | |||
1505 | 1551 | ||
1506 | 0x020200: Add poll()/select() support to the following attributes: | 1552 | 0x020200: Add poll()/select() support to the following attributes: |
1507 | hotkey_radio_sw, wakeup_hotunplug_complete, wakeup_reason | 1553 | hotkey_radio_sw, wakeup_hotunplug_complete, wakeup_reason |
1554 | |||
1555 | 0x020300: hotkey enable/disable support removed, attributes | ||
1556 | hotkey_bios_enabled and hotkey_enable deprecated and | ||
1557 | marked for removal. | ||
diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c index f2dbbf3bdeab..d36fcc0f2715 100644 --- a/Documentation/lguest/lguest.c +++ b/Documentation/lguest/lguest.c | |||
@@ -1630,6 +1630,13 @@ static bool service_io(struct device *dev) | |||
1630 | } | 1630 | } |
1631 | } | 1631 | } |
1632 | 1632 | ||
1633 | /* OK, so we noted that it was pretty poor to use an fdatasync as a | ||
1634 | * barrier. But Christoph Hellwig points out that we need a sync | ||
1635 | * *afterwards* as well: "Barriers specify no reordering to the front | ||
1636 | * or the back." And Jens Axboe confirmed it, so here we are: */ | ||
1637 | if (out->type & VIRTIO_BLK_T_BARRIER) | ||
1638 | fdatasync(vblk->fd); | ||
1639 | |||
1633 | /* We can't trigger an IRQ, because we're not the Launcher. It does | 1640 | /* We can't trigger an IRQ, because we're not the Launcher. It does |
1634 | * that when we tell it we're done. */ | 1641 | * that when we tell it we're done. */ |
1635 | add_used(dev->vq, head, wlen); | 1642 | add_used(dev->vq, head, wlen); |
diff --git a/Documentation/logo.gif b/Documentation/logo.gif deleted file mode 100644 index 2eae75fecfb9..000000000000 --- a/Documentation/logo.gif +++ /dev/null | |||
Binary files differ | |||
diff --git a/Documentation/logo.svg b/Documentation/logo.svg new file mode 100644 index 000000000000..cb9e4851d8c3 --- /dev/null +++ b/Documentation/logo.svg | |||
@@ -0,0 +1,2911 @@ | |||
1 | <?xml version="1.0" encoding="UTF-8" standalone="no"?> | ||
2 | <!-- Created with Inkscape (http://www.inkscape.org/) --> | ||
3 | <svg | ||
4 | xmlns:dc="http://purl.org/dc/elements/1.1/" | ||
5 | xmlns:cc="http://creativecommons.org/ns#" | ||
6 | xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" | ||
7 | xmlns:svg="http://www.w3.org/2000/svg" | ||
8 | xmlns="http://www.w3.org/2000/svg" | ||
9 | xmlns:xlink="http://www.w3.org/1999/xlink" | ||
10 | xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" | ||
11 | xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" | ||
12 | width="1771.6534" | ||
13 | height="1417.3228" | ||
14 | id="svg2" | ||
15 | sodipodi:version="0.32" | ||
16 | inkscape:version="0.46" | ||
17 | sodipodi:docname="tuz.svg" | ||
18 | inkscape:output_extension="org.inkscape.output.svg.inkscape" | ||
19 | version="1.0" | ||
20 | style="display:inline;enable-background:new" | ||
21 | inkscape:export-filename="/home/cheeseness/Documents/LCA09/mascot/tuz_final.png" | ||
22 | inkscape:export-xdpi="100.03588" | ||
23 | inkscape:export-ydpi="100.03588"> | ||
24 | <sodipodi:namedview | ||
25 | id="base" | ||
26 | pagecolor="#ffffff" | ||
27 | bordercolor="#666666" | ||
28 | borderopacity="1.0" | ||
29 | gridtolerance="10000" | ||
30 | guidetolerance="10" | ||
31 | objecttolerance="10" | ||
32 | inkscape:pageopacity="0.0" | ||
33 | inkscape:pageshadow="2" | ||
34 | inkscape:zoom="0.25" | ||
35 | inkscape:cx="-174.7931" | ||
36 | inkscape:cy="784.26325" | ||
37 | inkscape:document-units="px" | ||
38 | inkscape:current-layer="svg2" | ||
39 | showgrid="false" | ||
40 | inkscape:window-width="1280" | ||
41 | inkscape:window-height="823" | ||
42 | inkscape:window-x="-4" | ||
43 | inkscape:window-y="25" | ||
44 | showguides="true" | ||
45 | inkscape:guide-bbox="true" | ||
46 | units="mm" /> | ||
47 | <defs | ||
48 | id="defs4"> | ||
49 | <filter | ||
50 | inkscape:collect="always" | ||
51 | x="-0.084654994" | ||
52 | width="1.16931" | ||
53 | y="-0.36592469" | ||
54 | height="1.7318494" | ||
55 | id="filter11361"> | ||
56 | <feGaussianBlur | ||
57 | inkscape:collect="always" | ||
58 | stdDeviation="4.5740586" | ||
59 | id="feGaussianBlur11363" /> | ||
60 | </filter> | ||
61 | <inkscape:perspective | ||
62 | sodipodi:type="inkscape:persp3d" | ||
63 | inkscape:vp_x="0 : 564.0976 : 1" | ||
64 | inkscape:vp_y="0 : 1000 : 0" | ||
65 | inkscape:vp_z="1445.8591 : 564.0976 : 1" | ||
66 | inkscape:persp3d-origin="722.92957 : 376.06506 : 1" | ||
67 | id="perspective8145" /> | ||
68 | <linearGradient | ||
69 | id="linearGradient7622"> | ||
70 | <stop | ||
71 | style="stop-color:#ffffff;stop-opacity:1;" | ||
72 | offset="0" | ||
73 | id="stop7624" /> | ||
74 | <stop | ||
75 | style="stop-color:#ffffff;stop-opacity:0;" | ||
76 | offset="1" | ||
77 | id="stop7626" /> | ||
78 | </linearGradient> | ||
79 | <linearGradient | ||
80 | id="linearGradient4113"> | ||
81 | <stop | ||
82 | style="stop-color:#000000;stop-opacity:0;" | ||
83 | offset="0" | ||
84 | id="stop4115" /> | ||
85 | <stop | ||
86 | style="stop-color:#000000;stop-opacity:1;" | ||
87 | offset="1" | ||
88 | id="stop4117" /> | ||
89 | </linearGradient> | ||
90 | <linearGradient | ||
91 | inkscape:collect="always" | ||
92 | id="linearGradient3660"> | ||
93 | <stop | ||
94 | style="stop-color:#ffffff;stop-opacity:1;" | ||
95 | offset="0" | ||
96 | id="stop3662" /> | ||
97 | <stop | ||
98 | style="stop-color:#ffffff;stop-opacity:0;" | ||
99 | offset="1" | ||
100 | id="stop3664" /> | ||
101 | </linearGradient> | ||
102 | <linearGradient | ||
103 | id="linearGradient3627"> | ||
104 | <stop | ||
105 | style="stop-color:#ffffff;stop-opacity:1;" | ||
106 | offset="0" | ||
107 | id="stop3629" /> | ||
108 | <stop | ||
109 | style="stop-color:#000000;stop-opacity:1;" | ||
110 | offset="1" | ||
111 | id="stop3631" /> | ||
112 | </linearGradient> | ||
113 | <linearGradient | ||
114 | id="linearGradient2843"> | ||
115 | <stop | ||
116 | id="stop2845" | ||
117 | offset="0" | ||
118 | style="stop-color:#000000;stop-opacity:1;" /> | ||
119 | <stop | ||
120 | style="stop-color:#000000;stop-opacity:1;" | ||
121 | offset="0.02188784" | ||
122 | id="stop2847" /> | ||
123 | <stop | ||
124 | style="stop-color:#000000;stop-opacity:1;" | ||
125 | offset="0.75866222" | ||
126 | id="stop2849" /> | ||
127 | <stop | ||
128 | id="stop2851" | ||
129 | offset="0.88508981" | ||
130 | style="stop-color:#232323;stop-opacity:1;" /> | ||
131 | <stop | ||
132 | id="stop2853" | ||
133 | offset="1" | ||
134 | style="stop-color:#595959;stop-opacity:1;" /> | ||
135 | </linearGradient> | ||
136 | <linearGradient | ||
137 | inkscape:collect="always" | ||
138 | id="linearGradient8964"> | ||
139 | <stop | ||
140 | style="stop-color:#1a1a1a;stop-opacity:1;" | ||
141 | offset="0" | ||
142 | id="stop8966" /> | ||
143 | <stop | ||
144 | style="stop-color:#1a1a1a;stop-opacity:0;" | ||
145 | offset="1" | ||
146 | id="stop8968" /> | ||
147 | </linearGradient> | ||
148 | <linearGradient | ||
149 | id="linearGradient8952"> | ||
150 | <stop | ||
151 | style="stop-color:#0a0c0c;stop-opacity:1;" | ||
152 | offset="0" | ||
153 | id="stop8954" /> | ||
154 | <stop | ||
155 | style="stop-color:#1f2727;stop-opacity:0;" | ||
156 | offset="1" | ||
157 | id="stop8956" /> | ||
158 | </linearGradient> | ||
159 | <linearGradient | ||
160 | id="linearGradient8430"> | ||
161 | <stop | ||
162 | style="stop-color:#1e2323;stop-opacity:1;" | ||
163 | offset="0" | ||
164 | id="stop8432" /> | ||
165 | <stop | ||
166 | id="stop8438" | ||
167 | offset="0.55992389" | ||
168 | style="stop-color:#181d1d;stop-opacity:1;" /> | ||
169 | <stop | ||
170 | style="stop-color:#000000;stop-opacity:1;" | ||
171 | offset="1" | ||
172 | id="stop8434" /> | ||
173 | </linearGradient> | ||
174 | <linearGradient | ||
175 | id="linearGradient8398"> | ||
176 | <stop | ||
177 | style="stop-color:#283131;stop-opacity:0;" | ||
178 | offset="0" | ||
179 | id="stop8400" /> | ||
180 | <stop | ||
181 | id="stop8402" | ||
182 | offset="0.5125587" | ||
183 | style="stop-color:#1e2424;stop-opacity:0;" /> | ||
184 | <stop | ||
185 | style="stop-color:#000000;stop-opacity:1;" | ||
186 | offset="1" | ||
187 | id="stop8404" /> | ||
188 | </linearGradient> | ||
189 | <linearGradient | ||
190 | inkscape:collect="always" | ||
191 | id="linearGradient4870"> | ||
192 | <stop | ||
193 | style="stop-color:#c7bd80;stop-opacity:1;" | ||
194 | offset="0" | ||
195 | id="stop4872" /> | ||
196 | <stop | ||
197 | style="stop-color:#c7bd80;stop-opacity:0;" | ||
198 | offset="1" | ||
199 | id="stop4874" /> | ||
200 | </linearGradient> | ||
201 | <linearGradient | ||
202 | inkscape:collect="always" | ||
203 | id="linearGradient4862"> | ||
204 | <stop | ||
205 | style="stop-color:#e2e2e2;stop-opacity:1;" | ||
206 | offset="0" | ||
207 | id="stop4864" /> | ||
208 | <stop | ||
209 | style="stop-color:#e2e2e2;stop-opacity:0;" | ||
210 | offset="1" | ||
211 | id="stop4866" /> | ||
212 | </linearGradient> | ||
213 | <linearGradient | ||
214 | id="linearGradient4478"> | ||
215 | <stop | ||
216 | style="stop-color:#f9eed3;stop-opacity:1;" | ||
217 | offset="0" | ||
218 | id="stop4480" /> | ||
219 | <stop | ||
220 | style="stop-color:#000000;stop-opacity:0;" | ||
221 | offset="1" | ||
222 | id="stop4482" /> | ||
223 | </linearGradient> | ||
224 | <linearGradient | ||
225 | id="linearGradient4106"> | ||
226 | <stop | ||
227 | style="stop-color:#d9e002;stop-opacity:1;" | ||
228 | offset="0" | ||
229 | id="stop4108" /> | ||
230 | <stop | ||
231 | id="stop4114" | ||
232 | offset="0.5" | ||
233 | style="stop-color:#a9ae01;stop-opacity:1;" /> | ||
234 | <stop | ||
235 | style="stop-color:#717501;stop-opacity:1;" | ||
236 | offset="1" | ||
237 | id="stop4110" /> | ||
238 | </linearGradient> | ||
239 | <linearGradient | ||
240 | id="linearGradient4084"> | ||
241 | <stop | ||
242 | style="stop-color:#7d7d00;stop-opacity:1;" | ||
243 | offset="0" | ||
244 | id="stop4086" /> | ||
245 | <stop | ||
246 | id="stop4088" | ||
247 | offset="0.3636601" | ||
248 | style="stop-color:#c6c700;stop-opacity:1;" /> | ||
249 | <stop | ||
250 | style="stop-color:#f6f800;stop-opacity:1;" | ||
251 | offset="1" | ||
252 | id="stop4090" /> | ||
253 | </linearGradient> | ||
254 | <linearGradient | ||
255 | id="linearGradient4041"> | ||
256 | <stop | ||
257 | id="stop4043" | ||
258 | offset="0" | ||
259 | style="stop-color:#ffff00;stop-opacity:1;" /> | ||
260 | <stop | ||
261 | id="stop4045" | ||
262 | offset="1" | ||
263 | style="stop-color:#ffff00;stop-opacity:0;" /> | ||
264 | </linearGradient> | ||
265 | <linearGradient | ||
266 | id="linearGradient4025"> | ||
267 | <stop | ||
268 | style="stop-color:#ffffff;stop-opacity:1;" | ||
269 | offset="0" | ||
270 | id="stop4027" /> | ||
271 | <stop | ||
272 | style="stop-color:#ffffff;stop-opacity:0;" | ||
273 | offset="1" | ||
274 | id="stop4031" /> | ||
275 | </linearGradient> | ||
276 | <linearGradient | ||
277 | id="linearGradient4013"> | ||
278 | <stop | ||
279 | style="stop-color:#ffff00;stop-opacity:1;" | ||
280 | offset="0" | ||
281 | id="stop4015" /> | ||
282 | <stop | ||
283 | style="stop-color:#b2b200;stop-opacity:1;" | ||
284 | offset="1" | ||
285 | id="stop4017" /> | ||
286 | </linearGradient> | ||
287 | <linearGradient | ||
288 | id="linearGradient3985"> | ||
289 | <stop | ||
290 | style="stop-color:#000000;stop-opacity:1;" | ||
291 | offset="0" | ||
292 | id="stop3987" /> | ||
293 | <stop | ||
294 | style="stop-color:#1d1d1d;stop-opacity:1;" | ||
295 | offset="1" | ||
296 | id="stop3989" /> | ||
297 | </linearGradient> | ||
298 | <linearGradient | ||
299 | id="linearGradient3961"> | ||
300 | <stop | ||
301 | style="stop-color:#283131;stop-opacity:0;" | ||
302 | offset="0" | ||
303 | id="stop3963" /> | ||
304 | <stop | ||
305 | id="stop3965" | ||
306 | offset="0.5" | ||
307 | style="stop-color:#1e2424;stop-opacity:1;" /> | ||
308 | <stop | ||
309 | style="stop-color:#000000;stop-opacity:1;" | ||
310 | offset="1" | ||
311 | id="stop3967" /> | ||
312 | </linearGradient> | ||
313 | <linearGradient | ||
314 | id="linearGradient3951"> | ||
315 | <stop | ||
316 | id="stop3953" | ||
317 | offset="0" | ||
318 | style="stop-color:#344040;stop-opacity:1;" /> | ||
319 | <stop | ||
320 | style="stop-color:#222929;stop-opacity:1;" | ||
321 | offset="0.5" | ||
322 | id="stop3955" /> | ||
323 | <stop | ||
324 | id="stop3957" | ||
325 | offset="1" | ||
326 | style="stop-color:#000000;stop-opacity:1;" /> | ||
327 | </linearGradient> | ||
328 | <linearGradient | ||
329 | id="linearGradient3909"> | ||
330 | <stop | ||
331 | style="stop-color:#283131;stop-opacity:1;" | ||
332 | offset="0" | ||
333 | id="stop3911" /> | ||
334 | <stop | ||
335 | id="stop3917" | ||
336 | offset="0.5" | ||
337 | style="stop-color:#1e2424;stop-opacity:1;" /> | ||
338 | <stop | ||
339 | style="stop-color:#000000;stop-opacity:1;" | ||
340 | offset="1" | ||
341 | id="stop3913" /> | ||
342 | </linearGradient> | ||
343 | <linearGradient | ||
344 | id="linearGradient3537"> | ||
345 | <stop | ||
346 | style="stop-color:#ada469;stop-opacity:1;" | ||
347 | offset="0" | ||
348 | id="stop3539" /> | ||
349 | <stop | ||
350 | id="stop3545" | ||
351 | offset="0.81132078" | ||
352 | style="stop-color:#ada469;stop-opacity:1;" /> | ||
353 | <stop | ||
354 | style="stop-color:#ffffff;stop-opacity:1;" | ||
355 | offset="1" | ||
356 | id="stop3541" /> | ||
357 | </linearGradient> | ||
358 | <linearGradient | ||
359 | id="linearGradient3317"> | ||
360 | <stop | ||
361 | style="stop-color:#cfc690;stop-opacity:1" | ||
362 | offset="0" | ||
363 | id="stop3319" /> | ||
364 | <stop | ||
365 | id="stop3321" | ||
366 | offset="0.21161865" | ||
367 | style="stop-color:#afa775;stop-opacity:1;" /> | ||
368 | <stop | ||
369 | id="stop3323" | ||
370 | offset="0.53408515" | ||
371 | style="stop-color:#615c3a;stop-opacity:1;" /> | ||
372 | <stop | ||
373 | style="stop-color:#000000;stop-opacity:1;" | ||
374 | offset="0.76504093" | ||
375 | id="stop3325" /> | ||
376 | <stop | ||
377 | id="stop3327" | ||
378 | offset="1" | ||
379 | style="stop-color:#403518;stop-opacity:1;" /> | ||
380 | </linearGradient> | ||
381 | <linearGradient | ||
382 | id="linearGradient3239"> | ||
383 | <stop | ||
384 | id="stop3251" | ||
385 | offset="0" | ||
386 | style="stop-color:#cfc690;stop-opacity:1;" /> | ||
387 | <stop | ||
388 | style="stop-color:#afa775;stop-opacity:1;" | ||
389 | offset="0.21161865" | ||
390 | id="stop3267" /> | ||
391 | <stop | ||
392 | style="stop-color:#615c3a;stop-opacity:1;" | ||
393 | offset="0.53408515" | ||
394 | id="stop3261" /> | ||
395 | <stop | ||
396 | id="stop3265" | ||
397 | offset="0.76504093" | ||
398 | style="stop-color:#000000;stop-opacity:1;" /> | ||
399 | <stop | ||
400 | style="stop-color:#403518;stop-opacity:1;" | ||
401 | offset="1" | ||
402 | id="stop3243" /> | ||
403 | </linearGradient> | ||
404 | <radialGradient | ||
405 | inkscape:collect="always" | ||
406 | xlink:href="#linearGradient3239" | ||
407 | id="radialGradient3281" | ||
408 | gradientUnits="userSpaceOnUse" | ||
409 | gradientTransform="matrix(1.5480423,1.7414304,-1.9683515,1.7497638,-1130.5586,-1872.5121)" | ||
410 | spreadMethod="pad" | ||
411 | cx="806.52582" | ||
412 | cy="212.68117" | ||
413 | fx="806.52582" | ||
414 | fy="212.68117" | ||
415 | r="48.363216" /> | ||
416 | <radialGradient | ||
417 | inkscape:collect="always" | ||
418 | xlink:href="#linearGradient3317" | ||
419 | id="radialGradient3315" | ||
420 | cx="543.6698" | ||
421 | cy="147.3131" | ||
422 | fx="543.6698" | ||
423 | fy="147.3131" | ||
424 | r="47.863216" | ||
425 | gradientTransform="matrix(2.1382256,0,0,2.3382884,-77.03847,-101.68704)" | ||
426 | gradientUnits="userSpaceOnUse" /> | ||
427 | <radialGradient | ||
428 | inkscape:collect="always" | ||
429 | xlink:href="#linearGradient3537" | ||
430 | id="radialGradient3543" | ||
431 | cx="385" | ||
432 | cy="237.00504" | ||
433 | fx="385" | ||
434 | fy="237.00504" | ||
435 | r="86.928574" | ||
436 | gradientTransform="matrix(1,0,0,0.8562038,0,34.080427)" | ||
437 | gradientUnits="userSpaceOnUse" /> | ||
438 | <radialGradient | ||
439 | inkscape:collect="always" | ||
440 | xlink:href="#linearGradient3909" | ||
441 | id="radialGradient3915" | ||
442 | cx="418.30365" | ||
443 | cy="342.47794" | ||
444 | fx="418.30365" | ||
445 | fy="342.47794" | ||
446 | r="131.4509" | ||
447 | gradientTransform="matrix(1.3957347,0.6211056,-0.4244067,0.9537174,-15.061913,-227.96711)" | ||
448 | gradientUnits="userSpaceOnUse" /> | ||
449 | <radialGradient | ||
450 | inkscape:collect="always" | ||
451 | xlink:href="#linearGradient3951" | ||
452 | id="radialGradient3933" | ||
453 | cx="397.16388" | ||
454 | cy="336.95245" | ||
455 | fx="397.16388" | ||
456 | fy="336.95245" | ||
457 | r="36.75" | ||
458 | gradientUnits="userSpaceOnUse" | ||
459 | gradientTransform="matrix(1.9449972,2.4894837e-7,-2.4894833e-7,1.9449969,-375.31868,-318.41912)" /> | ||
460 | <linearGradient | ||
461 | inkscape:collect="always" | ||
462 | xlink:href="#linearGradient3961" | ||
463 | id="linearGradient3959" | ||
464 | x1="398.21429" | ||
465 | y1="343.52289" | ||
466 | x2="379.28571" | ||
467 | y2="265.30862" | ||
468 | gradientUnits="userSpaceOnUse" | ||
469 | gradientTransform="translate(450.03125,73.843964)" /> | ||
470 | <filter | ||
471 | inkscape:collect="always" | ||
472 | id="filter3981" | ||
473 | x="-0.30000001" | ||
474 | width="1.6" | ||
475 | y="-0.30000001" | ||
476 | height="1.6"> | ||
477 | <feGaussianBlur | ||
478 | inkscape:collect="always" | ||
479 | stdDeviation="2" | ||
480 | id="feGaussianBlur3983" /> | ||
481 | </filter> | ||
482 | <radialGradient | ||
483 | inkscape:collect="always" | ||
484 | xlink:href="#linearGradient3985" | ||
485 | id="radialGradient3991" | ||
486 | cx="402.48898" | ||
487 | cy="317.23578" | ||
488 | fx="402.48898" | ||
489 | fy="317.23578" | ||
490 | r="23.714285" | ||
491 | gradientUnits="userSpaceOnUse" | ||
492 | gradientTransform="matrix(4.3776616,0,0,4.3776616,-1358.3025,-1070.7357)" /> | ||
493 | <clipPath | ||
494 | clipPathUnits="userSpaceOnUse" | ||
495 | id="clipPath3999"> | ||
496 | <path | ||
497 | style="opacity:1;fill:#f5ff04;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:20.79999924;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline" | ||
498 | d="M 179.64286,267.36218 C 157.23242,307.0651 119.02676,383.14247 110.35715,417.00504 C 101.70994,450.78014 101.58516,483.42158 110,503.43362 C 118.3602,523.31575 136.16398,539.06642 150.71428,544.86218 C 150.1179,530.48631 165.08723,501.57635 223.57143,472.36218 C 282.1977,443.07704 301.95306,445.23132 327.14285,425.21932 C 352.77291,404.85756 339.75316,358.17469 330.35714,331.29075 C 320.9229,304.29747 295.38973,272.16627 263.92857,261.6479 C 232.8953,251.27258 198.91081,256.79953 179.64286,267.36218 z" | ||
499 | id="path4001" | ||
500 | sodipodi:nodetypes="czzczzzzc" /> | ||
501 | </clipPath> | ||
502 | <radialGradient | ||
503 | inkscape:collect="always" | ||
504 | xlink:href="#linearGradient4013" | ||
505 | id="radialGradient4056" | ||
506 | gradientUnits="userSpaceOnUse" | ||
507 | gradientTransform="matrix(1.1323239,0.7659488,-1.4550286,2.1510098,588.75376,-711.79716)" | ||
508 | cx="228.81355" | ||
509 | cy="440.26971" | ||
510 | fx="228.81355" | ||
511 | fy="440.26971" | ||
512 | r="119.17509" /> | ||
513 | <radialGradient | ||
514 | inkscape:collect="always" | ||
515 | xlink:href="#linearGradient4041" | ||
516 | id="radialGradient4060" | ||
517 | gradientUnits="userSpaceOnUse" | ||
518 | gradientTransform="matrix(5.911206e-2,2.6869855,-0.7234268,1.5914947e-2,408.72779,-424.56452)" | ||
519 | cx="275.4422" | ||
520 | cy="335.34866" | ||
521 | fx="275.4422" | ||
522 | fy="335.34866" | ||
523 | r="36.75" /> | ||
524 | <radialGradient | ||
525 | inkscape:collect="always" | ||
526 | xlink:href="#linearGradient4025" | ||
527 | id="radialGradient4062" | ||
528 | gradientUnits="userSpaceOnUse" | ||
529 | gradientTransform="matrix(5.911206e-2,2.6869855,-0.7234268,1.5914947e-2,408.72779,-424.56452)" | ||
530 | cx="275.4422" | ||
531 | cy="335.34866" | ||
532 | fx="275.4422" | ||
533 | fy="335.34866" | ||
534 | r="36.75" /> | ||
535 | <linearGradient | ||
536 | inkscape:collect="always" | ||
537 | xlink:href="#linearGradient4084" | ||
538 | id="linearGradient4082" | ||
539 | gradientUnits="userSpaceOnUse" | ||
540 | x1="182.35046" | ||
541 | y1="256.11136" | ||
542 | x2="145.53348" | ||
543 | y2="542.20502" /> | ||
544 | <clipPath | ||
545 | clipPathUnits="userSpaceOnUse" | ||
546 | id="clipPath4100"> | ||
547 | <path | ||
548 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.9000755px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" | ||
549 | d="M 265.93541,126.68393 L 247.1682,295.54701 L 421.27363,222.42633 L 483.22803,311.08516 L 541.11243,279.09486 L 503.57801,99.035183 L 265.93541,126.68393 z" | ||
550 | id="path4102" | ||
551 | sodipodi:nodetypes="ccccccc" /> | ||
552 | </clipPath> | ||
553 | <radialGradient | ||
554 | inkscape:collect="always" | ||
555 | xlink:href="#linearGradient4106" | ||
556 | id="radialGradient4112" | ||
557 | cx="250.22678" | ||
558 | cy="475.09763" | ||
559 | fx="250.22678" | ||
560 | fy="475.09763" | ||
561 | r="95.98877" | ||
562 | gradientTransform="matrix(1.2259004,-0.7077739,0.1413989,0.2449102,322.22326,608.91815)" | ||
563 | gradientUnits="userSpaceOnUse" /> | ||
564 | <linearGradient | ||
565 | inkscape:collect="always" | ||
566 | xlink:href="#linearGradient4478" | ||
567 | id="linearGradient4484" | ||
568 | x1="412.08926" | ||
569 | y1="404.91574" | ||
570 | x2="417.375" | ||
571 | y2="401.82648" | ||
572 | gradientUnits="userSpaceOnUse" /> | ||
573 | <linearGradient | ||
574 | inkscape:collect="always" | ||
575 | xlink:href="#linearGradient4478" | ||
576 | id="linearGradient4486" | ||
577 | x1="411.91071" | ||
578 | y1="404.91577" | ||
579 | x2="417.375" | ||
580 | y2="401.82648" | ||
581 | gradientUnits="userSpaceOnUse" /> | ||
582 | <linearGradient | ||
583 | inkscape:collect="always" | ||
584 | xlink:href="#linearGradient4478" | ||
585 | id="linearGradient4488" | ||
586 | x1="411.91071" | ||
587 | y1="405.54077" | ||
588 | x2="417.375" | ||
589 | y2="401.82648" | ||
590 | gradientUnits="userSpaceOnUse" /> | ||
591 | <linearGradient | ||
592 | inkscape:collect="always" | ||
593 | xlink:href="#linearGradient4478" | ||
594 | id="linearGradient4490" | ||
595 | x1="412.08926" | ||
596 | y1="405.54077" | ||
597 | x2="417.375" | ||
598 | y2="401.82648" | ||
599 | gradientUnits="userSpaceOnUse" /> | ||
600 | <linearGradient | ||
601 | inkscape:collect="always" | ||
602 | xlink:href="#linearGradient4478" | ||
603 | id="linearGradient4492" | ||
604 | x1="411.73212" | ||
605 | y1="405.54077" | ||
606 | x2="417.375" | ||
607 | y2="401.82648" | ||
608 | gradientUnits="userSpaceOnUse" /> | ||
609 | <radialGradient | ||
610 | inkscape:collect="always" | ||
611 | xlink:href="#linearGradient4862" | ||
612 | id="radialGradient4868" | ||
613 | cx="429.56738" | ||
614 | cy="377.42877" | ||
615 | fx="429.56738" | ||
616 | fy="377.42877" | ||
617 | r="72.079735" | ||
618 | gradientTransform="matrix(1,0,0,0.618034,0,144.16496)" | ||
619 | gradientUnits="userSpaceOnUse" /> | ||
620 | <radialGradient | ||
621 | inkscape:collect="always" | ||
622 | xlink:href="#linearGradient4870" | ||
623 | id="radialGradient4876" | ||
624 | cx="437.6991" | ||
625 | cy="391.21735" | ||
626 | fx="437.6991" | ||
627 | fy="391.21735" | ||
628 | r="36.611931" | ||
629 | gradientTransform="matrix(1,0,0,0.618034,0,149.43174)" | ||
630 | gradientUnits="userSpaceOnUse" /> | ||
631 | <radialGradient | ||
632 | inkscape:collect="always" | ||
633 | xlink:href="#linearGradient4013" | ||
634 | id="radialGradient3585" | ||
635 | gradientUnits="userSpaceOnUse" | ||
636 | gradientTransform="matrix(1.1323239,0.7659488,-1.4550286,2.1510098,588.75376,-711.79716)" | ||
637 | cx="228.81355" | ||
638 | cy="440.26971" | ||
639 | fx="228.81355" | ||
640 | fy="440.26971" | ||
641 | r="119.17509" /> | ||
642 | <linearGradient | ||
643 | inkscape:collect="always" | ||
644 | xlink:href="#linearGradient4084" | ||
645 | id="linearGradient3587" | ||
646 | gradientUnits="userSpaceOnUse" | ||
647 | x1="182.35046" | ||
648 | y1="256.11136" | ||
649 | x2="145.53348" | ||
650 | y2="542.20502" /> | ||
651 | <radialGradient | ||
652 | inkscape:collect="always" | ||
653 | xlink:href="#linearGradient3317" | ||
654 | id="radialGradient8410" | ||
655 | gradientUnits="userSpaceOnUse" | ||
656 | gradientTransform="matrix(1.0036478,-1.0345492e-7,1.7124628e-7,1.6613125,-753.99632,-302.76972)" | ||
657 | cx="317.78754" | ||
658 | cy="129.65378" | ||
659 | fx="317.78754" | ||
660 | fy="129.65378" | ||
661 | r="47.863216" /> | ||
662 | <radialGradient | ||
663 | inkscape:collect="always" | ||
664 | xlink:href="#linearGradient8398" | ||
665 | id="radialGradient8412" | ||
666 | gradientUnits="userSpaceOnUse" | ||
667 | gradientTransform="matrix(2.0747661,-0.1577957,0.2382425,3.1325183,-1144.2358,-272.29325)" | ||
668 | cx="325.30847" | ||
669 | cy="80.909554" | ||
670 | fx="325.30847" | ||
671 | fy="80.909554" | ||
672 | r="26.937988" /> | ||
673 | <clipPath | ||
674 | clipPathUnits="userSpaceOnUse" | ||
675 | id="clipPath8514"> | ||
676 | <path | ||
677 | style="opacity:1;fill:#262f2f;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
678 | d="M 352.24553,211.99185 C 348.4411,186.72762 335.43581,161.35383 335.08873,136.46662 C 334.90247,123.1111 338.36158,109.89571 348.84426,96.912574 C 385.19128,31.616739 465.78517,12.217889 534.77892,5.447147 C 621.70131,-5.569654 719.69159,23.387219 768.15026,100.84843 C 822.27428,176.58173 824.82502,273.38755 848.7623,360.37638 C 878.20009,487.50398 903.54144,616.59052 909.15454,747.22673 C 906.09106,825.40858 900.7282,912.41088 848.65133,975.36086 C 800.62479,1025.7183 725.86486,1025.4139 661.58145,1034.3632 C 571.02606,1039.0182 477.22992,1018.2174 399.79755,970.16496 C 335.02191,932.22495 304.06736,856.68633 302.51815,784.14538 C 294.12898,704.27022 328.90967,630.33687 354.13855,556.98577 C 361.60916,474.2247 363.55141,390.73802 363.79189,307.60093 C 362.95507,275.40549 356.70236,243.7836 352.24553,211.99185 z" | ||
679 | id="path8516" | ||
680 | sodipodi:nodetypes="cscccccccccccc" /> | ||
681 | </clipPath> | ||
682 | <clipPath | ||
683 | clipPathUnits="userSpaceOnUse" | ||
684 | id="clipPath8604"> | ||
685 | <path | ||
686 | style="opacity:1;fill:#262f2f;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
687 | d="M 352.24553,211.99185 C 348.4411,186.72762 335.43581,161.35383 335.08873,136.46662 C 334.90247,123.1111 338.36158,109.89571 348.84426,96.912574 C 385.19128,31.616739 465.78517,12.217889 534.77892,5.447147 C 621.70131,-5.569654 719.69159,23.387219 768.15026,100.84843 C 822.27428,176.58173 824.82502,273.38755 848.7623,360.37638 C 878.20009,487.50398 903.54144,616.59052 909.15454,747.22673 C 906.09106,825.40858 900.7282,912.41088 848.65133,975.36086 C 800.62479,1025.7183 725.86486,1025.4139 661.58145,1034.3632 C 571.02606,1039.0182 477.22992,1018.2174 399.79755,970.16496 C 335.02191,932.22495 304.06736,856.68633 302.51815,784.14538 C 294.12898,704.27022 328.90967,630.33687 354.13855,556.98577 C 361.60916,474.2247 363.55141,390.73802 363.79189,307.60093 C 362.95507,275.40549 356.70236,243.7836 352.24553,211.99185 z" | ||
688 | id="path8606" | ||
689 | sodipodi:nodetypes="cscccccccccccc" /> | ||
690 | </clipPath> | ||
691 | <clipPath | ||
692 | clipPathUnits="userSpaceOnUse" | ||
693 | id="clipPath8610"> | ||
694 | <path | ||
695 | style="opacity:1;fill:#262f2f;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
696 | d="M 352.24553,211.99185 C 348.4411,186.72762 335.43581,161.35383 335.08873,136.46662 C 334.90247,123.1111 338.36158,109.89571 348.84426,96.912574 C 385.19128,31.616739 465.78517,12.217889 534.77892,5.447147 C 621.70131,-5.569654 719.69159,23.387219 768.15026,100.84843 C 822.27428,176.58173 824.82502,273.38755 848.7623,360.37638 C 878.20009,487.50398 903.54144,616.59052 909.15454,747.22673 C 906.09106,825.40858 900.7282,912.41088 848.65133,975.36086 C 800.62479,1025.7183 725.86486,1025.4139 661.58145,1034.3632 C 571.02606,1039.0182 477.22992,1018.2174 399.79755,970.16496 C 335.02191,932.22495 304.06736,856.68633 302.51815,784.14538 C 294.12898,704.27022 328.90967,630.33687 354.13855,556.98577 C 361.60916,474.2247 363.55141,390.73802 363.79189,307.60093 C 362.95507,275.40549 356.70236,243.7836 352.24553,211.99185 z" | ||
697 | id="path8612" | ||
698 | sodipodi:nodetypes="cscccccccccccc" /> | ||
699 | </clipPath> | ||
700 | <clipPath | ||
701 | clipPathUnits="userSpaceOnUse" | ||
702 | id="clipPath8616"> | ||
703 | <path | ||
704 | style="opacity:1;fill:#262f2f;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
705 | d="M 352.24553,211.99185 C 348.4411,186.72762 335.43581,161.35383 335.08873,136.46662 C 334.90247,123.1111 338.36158,109.89571 348.84426,96.912574 C 385.19128,31.616739 465.78517,12.217889 534.77892,5.447147 C 621.70131,-5.569654 719.69159,23.387219 768.15026,100.84843 C 822.27428,176.58173 824.82502,273.38755 848.7623,360.37638 C 878.20009,487.50398 903.54144,616.59052 909.15454,747.22673 C 906.09106,825.40858 900.7282,912.41088 848.65133,975.36086 C 800.62479,1025.7183 725.86486,1025.4139 661.58145,1034.3632 C 571.02606,1039.0182 477.22992,1018.2174 399.79755,970.16496 C 335.02191,932.22495 304.06736,856.68633 302.51815,784.14538 C 294.12898,704.27022 328.90967,630.33687 354.13855,556.98577 C 361.60916,474.2247 363.55141,390.73802 363.79189,307.60093 C 362.95507,275.40549 356.70236,243.7836 352.24553,211.99185 z" | ||
706 | id="path8618" | ||
707 | sodipodi:nodetypes="cscccccccccccc" /> | ||
708 | </clipPath> | ||
709 | <clipPath | ||
710 | clipPathUnits="userSpaceOnUse" | ||
711 | id="clipPath8622"> | ||
712 | <path | ||
713 | style="opacity:1;fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
714 | d="M 821.64329,477.88997 C 821.64329,477.88997 844.26276,471.38316 857.38604,472.01724 C 870.50932,472.65133 888.02762,473.95586 901.09489,484.20343 C 914.16216,494.45099 926.16263,511.3435 935.20728,542.57308 C 944.25193,573.80266 936.9056,641.82509 929.03125,685.92043 C 921.1569,730.01577 900.76615,792.03341 884.03125,825.92043 C 867.29635,859.80745 834.23354,903.41563 823.46182,915.79659 C 812.0976,928.85856 767.25593,952.22276 744.03125,958.06326 C 749.33455,947.45666 792.93101,907.47442 779.03125,897.349 C 765.01228,887.13674 733.27116,943.33136 694.7381,926.38217 C 716.12041,913.25005 736.5175,875.19611 728.77871,859.78772 C 720.93846,844.17733 698.07378,908.54529 635.24317,896.8006 C 665.29521,869.27394 690.65023,825.89659 676.50587,813.8209 C 662.09071,801.51403 616.04412,868.11405 616.04412,868.11405 C 616.04412,868.11405 613.22222,826.41287 629.81732,799.50673 C 646.45667,772.52886 709.47029,717.89146 729.37045,687.80331 C 749.2706,657.71517 762.98301,621.79429 771.50587,595.28537 C 780.02873,568.77645 787.30681,518.18583 787.30681,518.18583" | ||
715 | id="path8624" | ||
716 | sodipodi:nodetypes="czzzzzzczczczczzzc" /> | ||
717 | </clipPath> | ||
718 | <clipPath | ||
719 | clipPathUnits="userSpaceOnUse" | ||
720 | id="clipPath8642"> | ||
721 | <path | ||
722 | style="opacity:1;fill:#0f0f0f;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
723 | d="M 366.88839,504.13471 C 366.88839,504.13471 337.33433,544.70776 319.03125,578.42042 C 300.72816,612.13309 260.41016,704.77736 248.67411,749.49185 C 236.91471,794.29529 186.17411,873.06329 186.17411,873.06329 L 262.24554,891.27757 C 262.24554,891.27757 274.05266,878.45422 293.31696,845.20614 C 312.58126,811.95806 353.67411,706.63471 353.67411,706.63471 L 366.88839,504.13471 z" | ||
724 | id="path8644" | ||
725 | sodipodi:nodetypes="czzcczcc" /> | ||
726 | </clipPath> | ||
727 | <clipPath | ||
728 | clipPathUnits="userSpaceOnUse" | ||
729 | id="clipPath8658"> | ||
730 | <path | ||
731 | style="opacity:1;fill:#0b0b0b;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
732 | d="M 569.03125,1018.7776 C 564.74554,1019.4919 541.4031,1022.3957 511.17411,1028.7776 C 480.94512,1035.1595 411.39918,1054.7395 368.31696,1064.4919 C 325.23474,1074.2443 251.05253,1099.3079 211.40434,1091.7573 C 171.75616,1084.2067 121.88839,1027.349 121.88839,1027.349 L 126.17411,933.06329 C 126.17411,933.06329 212.05962,916.86235 238.31696,899.49186 C 264.57431,882.12137 283.89934,849.82588 297.60268,828.06329 C 311.30602,806.3007 330.45982,756.63471 330.45982,756.63471 L 569.03125,1018.7776 z" | ||
733 | id="path8660" | ||
734 | sodipodi:nodetypes="czzzcczzcc" /> | ||
735 | </clipPath> | ||
736 | <filter | ||
737 | inkscape:collect="always" | ||
738 | id="filter8802" | ||
739 | x="-0.35311759" | ||
740 | width="1.7062352" | ||
741 | y="-0.1817714" | ||
742 | height="1.3635428"> | ||
743 | <feGaussianBlur | ||
744 | inkscape:collect="always" | ||
745 | stdDeviation="48.038491" | ||
746 | id="feGaussianBlur8804" /> | ||
747 | </filter> | ||
748 | <filter | ||
749 | inkscape:collect="always" | ||
750 | id="filter8806" | ||
751 | x="-0.61142862" | ||
752 | width="2.2228572" | ||
753 | y="-0.14930232" | ||
754 | height="1.2986046"> | ||
755 | <feGaussianBlur | ||
756 | inkscape:collect="always" | ||
757 | stdDeviation="37.830213" | ||
758 | id="feGaussianBlur8808" /> | ||
759 | </filter> | ||
760 | <filter | ||
761 | inkscape:collect="always" | ||
762 | id="filter8810" | ||
763 | x="-0.23519406" | ||
764 | width="1.4703881" | ||
765 | y="-0.24500646" | ||
766 | height="1.4900129"> | ||
767 | <feGaussianBlur | ||
768 | inkscape:collect="always" | ||
769 | stdDeviation="58.328041" | ||
770 | id="feGaussianBlur8812" /> | ||
771 | </filter> | ||
772 | <filter | ||
773 | inkscape:collect="always" | ||
774 | id="filter8814" | ||
775 | x="-0.20466694" | ||
776 | width="1.4093339" | ||
777 | y="-0.29007819" | ||
778 | height="1.5801564"> | ||
779 | <feGaussianBlur | ||
780 | inkscape:collect="always" | ||
781 | stdDeviation="22.300169" | ||
782 | id="feGaussianBlur8816" /> | ||
783 | </filter> | ||
784 | <filter | ||
785 | inkscape:collect="always" | ||
786 | id="filter8818" | ||
787 | x="-0.34381232" | ||
788 | width="1.6876246" | ||
789 | y="-0.18433961" | ||
790 | height="1.3686792"> | ||
791 | <feGaussianBlur | ||
792 | inkscape:collect="always" | ||
793 | stdDeviation="34.542167" | ||
794 | id="feGaussianBlur8820" /> | ||
795 | </filter> | ||
796 | <filter | ||
797 | inkscape:collect="always" | ||
798 | id="filter8822" | ||
799 | x="-0.2742857" | ||
800 | width="1.5485713" | ||
801 | y="-0.21333334" | ||
802 | height="1.4266667"> | ||
803 | <feGaussianBlur | ||
804 | inkscape:collect="always" | ||
805 | stdDeviation="11.313708" | ||
806 | id="feGaussianBlur8824" /> | ||
807 | </filter> | ||
808 | <filter | ||
809 | inkscape:collect="always" | ||
810 | id="filter8826" | ||
811 | x="-0.25894088" | ||
812 | width="1.5178818" | ||
813 | y="-0.2236412" | ||
814 | height="1.4472824"> | ||
815 | <feGaussianBlur | ||
816 | inkscape:collect="always" | ||
817 | stdDeviation="19.631544" | ||
818 | id="feGaussianBlur8828" /> | ||
819 | </filter> | ||
820 | <filter | ||
821 | inkscape:collect="always" | ||
822 | id="filter8856" | ||
823 | x="-0.3253231" | ||
824 | width="1.6506462" | ||
825 | y="-0.19013336" | ||
826 | height="1.3802667"> | ||
827 | <feGaussianBlur | ||
828 | inkscape:collect="always" | ||
829 | stdDeviation="28.712591" | ||
830 | id="feGaussianBlur8858" /> | ||
831 | </filter> | ||
832 | <filter | ||
833 | inkscape:collect="always" | ||
834 | id="filter8860" | ||
835 | x="-0.38093024" | ||
836 | width="1.7618605" | ||
837 | y="-0.17518716" | ||
838 | height="1.3503743"> | ||
839 | <feGaussianBlur | ||
840 | inkscape:collect="always" | ||
841 | stdDeviation="19.304015" | ||
842 | id="feGaussianBlur8862" /> | ||
843 | </filter> | ||
844 | <filter | ||
845 | inkscape:collect="always" | ||
846 | id="filter8888" | ||
847 | x="-0.2112188" | ||
848 | width="1.4224375" | ||
849 | y="-0.16808605" | ||
850 | height="1.3361721"> | ||
851 | <feGaussianBlur | ||
852 | inkscape:collect="always" | ||
853 | stdDeviation="8.3693583" | ||
854 | id="feGaussianBlur8890" /> | ||
855 | </filter> | ||
856 | <filter | ||
857 | inkscape:collect="always" | ||
858 | id="filter8892" | ||
859 | x="-0.18692794" | ||
860 | width="1.3738559" | ||
861 | y="-0.23646873" | ||
862 | height="1.4729375"> | ||
863 | <feGaussianBlur | ||
864 | inkscape:collect="always" | ||
865 | stdDeviation="31.21228" | ||
866 | id="feGaussianBlur8894" /> | ||
867 | </filter> | ||
868 | <clipPath | ||
869 | clipPathUnits="userSpaceOnUse" | ||
870 | id="clipPath8906"> | ||
871 | <path | ||
872 | style="opacity:1;fill:#262f2f;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
873 | d="M 352.24553,211.99185 C 348.4411,186.72762 335.43581,161.35383 335.08873,136.46662 C 334.90247,123.1111 338.36158,109.89571 348.84426,96.912574 C 385.19128,31.616739 465.78517,12.217889 534.77892,5.447147 C 621.70131,-5.569654 719.69159,23.387219 768.15026,100.84843 C 822.27428,176.58173 824.82502,273.38755 848.7623,360.37638 C 878.20009,487.50398 903.54144,616.59052 909.15454,747.22673 C 906.09106,825.40858 900.7282,912.41088 848.65133,975.36086 C 800.62479,1025.7183 725.86486,1025.4139 661.58145,1034.3632 C 571.02606,1039.0182 477.22992,1018.2174 399.79755,970.16496 C 335.02191,932.22495 304.06736,856.68633 302.51815,784.14538 C 294.12898,704.27022 328.90967,630.33687 354.13855,556.98577 C 361.60916,474.2247 363.55141,390.73802 363.79189,307.60093 C 362.95507,275.40549 356.70236,243.7836 352.24553,211.99185 z" | ||
874 | id="path8908" | ||
875 | sodipodi:nodetypes="cscccccccccccc" /> | ||
876 | </clipPath> | ||
877 | <filter | ||
878 | inkscape:collect="always" | ||
879 | id="filter8940" | ||
880 | x="-0.25152978" | ||
881 | width="1.5030596" | ||
882 | y="-0.053035267" | ||
883 | height="1.1060705"> | ||
884 | <feGaussianBlur | ||
885 | inkscape:collect="always" | ||
886 | stdDeviation="13.024603" | ||
887 | id="feGaussianBlur8942" /> | ||
888 | </filter> | ||
889 | <linearGradient | ||
890 | inkscape:collect="always" | ||
891 | xlink:href="#linearGradient8952" | ||
892 | id="linearGradient8958" | ||
893 | x1="609.31244" | ||
894 | y1="239.46866" | ||
895 | x2="560.83142" | ||
896 | y2="262.86206" | ||
897 | gradientUnits="userSpaceOnUse" | ||
898 | gradientTransform="translate(450.03125,73.843964)" /> | ||
899 | <linearGradient | ||
900 | inkscape:collect="always" | ||
901 | xlink:href="#linearGradient8964" | ||
902 | id="linearGradient8970" | ||
903 | x1="603.84064" | ||
904 | y1="627.85303" | ||
905 | x2="616.24396" | ||
906 | y2="585.42664" | ||
907 | gradientUnits="userSpaceOnUse" | ||
908 | gradientTransform="translate(450.03125,73.843964)" /> | ||
909 | <filter | ||
910 | inkscape:collect="always" | ||
911 | id="filter9020" | ||
912 | x="-0.32861114" | ||
913 | width="1.6572223" | ||
914 | y="-0.182" | ||
915 | height="1.364"> | ||
916 | <feGaussianBlur | ||
917 | inkscape:collect="always" | ||
918 | stdDeviation="20.912684" | ||
919 | id="feGaussianBlur9022" /> | ||
920 | </filter> | ||
921 | <filter | ||
922 | inkscape:collect="always" | ||
923 | id="filter9024" | ||
924 | x="-0.55453134" | ||
925 | width="2.1090627" | ||
926 | y="-0.51434779" | ||
927 | height="2.0286956"> | ||
928 | <feGaussianBlur | ||
929 | inkscape:collect="always" | ||
930 | stdDeviation="20.912684" | ||
931 | id="feGaussianBlur9026" /> | ||
932 | </filter> | ||
933 | <filter | ||
934 | inkscape:collect="always" | ||
935 | id="filter9044" | ||
936 | x="-0.32631579" | ||
937 | width="1.6526316" | ||
938 | y="-0.84545463" | ||
939 | height="2.6909094"> | ||
940 | <feGaussianBlur | ||
941 | inkscape:collect="always" | ||
942 | stdDeviation="21.92031" | ||
943 | id="feGaussianBlur9046" /> | ||
944 | </filter> | ||
945 | <filter | ||
946 | inkscape:collect="always" | ||
947 | id="filter9048" | ||
948 | x="-0.40879121" | ||
949 | width="1.8175824" | ||
950 | y="-0.71538466" | ||
951 | height="2.4307692"> | ||
952 | <feGaussianBlur | ||
953 | inkscape:collect="always" | ||
954 | stdDeviation="21.92031" | ||
955 | id="feGaussianBlur9050" /> | ||
956 | </filter> | ||
957 | <filter | ||
958 | inkscape:collect="always" | ||
959 | id="filter3587" | ||
960 | x="-0.1"> | ||
961 | <feGaussianBlur | ||
962 | inkscape:collect="always" | ||
963 | stdDeviation="8.881432" | ||
964 | id="feGaussianBlur3589" /> | ||
965 | </filter> | ||
966 | <clipPath | ||
967 | clipPathUnits="userSpaceOnUse" | ||
968 | id="clipPath3602"> | ||
969 | <path | ||
970 | sodipodi:nodetypes="czzzzzzczczczczzzc" | ||
971 | id="path3604" | ||
972 | d="M 647.61204,540.04601 C 647.61204,540.04601 670.23151,533.5392 683.35479,534.17328 C 696.47807,534.80737 713.99637,536.1119 727.06364,546.35947 C 740.13091,556.60703 752.13138,573.49954 761.17603,604.72912 C 770.22068,635.9587 762.87435,703.98113 755,748.07647 C 747.12565,792.17181 726.7349,854.18945 710,888.07647 C 693.2651,921.96349 660.20229,965.57167 649.43057,977.95263 C 638.06635,991.0146 593.22468,1014.3788 570,1020.2193 C 575.3033,1009.6127 618.89976,969.63046 605,959.50504 C 590.98103,949.29278 559.23991,1005.4874 520.70685,988.53821 C 542.08916,975.40609 562.48625,937.35215 554.74746,921.94376 C 546.90721,906.33337 524.04253,970.70133 461.21192,958.95664 C 491.26396,931.42998 516.61898,888.05263 502.47462,875.97694 C 488.05946,863.67007 442.01287,930.27009 442.01287,930.27009 C 442.01287,930.27009 439.19097,888.56891 455.78607,861.66277 C 472.42542,834.6849 535.43904,780.0475 555.3392,749.95935 C 575.23935,719.87121 588.95176,683.95033 597.47462,657.44141 C 605.99748,630.93249 613.27556,580.34187 613.27556,580.34187" | ||
973 | style="opacity:1;fill:#202020;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
974 | </clipPath> | ||
975 | <filter | ||
976 | inkscape:collect="always" | ||
977 | id="filter4120" | ||
978 | x="-0.2770822" | ||
979 | width="1.5541644" | ||
980 | y="-0.32482043" | ||
981 | height="1.6496409"> | ||
982 | <feGaussianBlur | ||
983 | inkscape:collect="always" | ||
984 | stdDeviation="19.956289" | ||
985 | id="feGaussianBlur4122" /> | ||
986 | </filter> | ||
987 | <clipPath | ||
988 | clipPathUnits="userSpaceOnUse" | ||
989 | id="clipPath3631"> | ||
990 | <path | ||
991 | style="opacity:1;fill:#ada469;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
992 | d="M 760.16396,935.83377 C 766.95806,954.73656 770.65765,969.13346 772.05426,987.04566 C 773.45088,1004.958 768.27158,1038.8465 769.1538,1057.7018 C 770.03555,1076.547 777.28749,1097.8008 796.49843,1106.6707 C 815.9173,1115.6365 845.81767,1116.882 870.61827,1103.5251 C 895.41887,1090.1681 928.01929,1033.1996 941.59253,1006.2164 C 955.21638,979.13246 980.3536,891.71903 986.25333,856.44781 C 992.15306,821.1766 988.80387,815.14704 981.63585,807.39232 C 984.27615,779.55217 980.13613,752.45689 994.74554,720.20614 C 964.49653,732.03184 957.36325,760.36684 946.42665,785.71122 C 938.42574,734.77829 946.63581,714.43803 949.74554,684.49186 C 920.68078,699.26977 906.88403,731.60588 904.74554,777.349 C 893.82159,776.0448 883.3541,772.91477 871.17411,776.63471 C 870.91007,730.61137 869.71055,699.7453 880.08474,662.42822 C 826.82927,683.45508 817.13746,769.02232 824.03125,775.20614 C 813.14843,775.74114 802.66017,773.90884 791.17411,778.06329 C 791.81303,735.49194 790.91365,693.15468 761.17411,655.20614 C 761.17411,655.20614 730.21605,736.12848 729.74554,758.77757 C 729.27503,781.42666 739.19713,798.94345 739.19713,798.94345 C 739.19713,798.94345 730.62906,835.68396 732.89854,857.17568 C 735.19439,878.91714 753.34144,916.85185 760.16396,935.83377 z" | ||
993 | id="path3633" | ||
994 | sodipodi:nodetypes="czzzzzzcccccccccczczz" /> | ||
995 | </clipPath> | ||
996 | <clipPath | ||
997 | clipPathUnits="userSpaceOnUse" | ||
998 | id="clipPath3665"> | ||
999 | <path | ||
1000 | sodipodi:nodetypes="czzcczcc" | ||
1001 | id="path3667" | ||
1002 | d="M 366.88839,504.13471 C 366.88839,504.13471 337.33433,544.70776 319.03125,578.42042 C 300.72816,612.13309 260.41016,704.77736 248.67411,749.49185 C 236.91471,794.29529 186.17411,873.06329 186.17411,873.06329 L 262.24554,891.27757 C 262.24554,891.27757 274.05266,878.45422 293.31696,845.20614 C 312.58126,811.95806 353.67411,706.63471 353.67411,706.63471 L 366.88839,504.13471 z" | ||
1003 | style="opacity:1;fill:#0f0f0f;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
1004 | </clipPath> | ||
1005 | <clipPath | ||
1006 | clipPathUnits="userSpaceOnUse" | ||
1007 | id="clipPath3677"> | ||
1008 | <path | ||
1009 | style="opacity:1;fill:#ada469;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
1010 | d="M 586.13271,997.98981 C 592.92681,1016.8926 596.6264,1031.2895 598.02301,1049.2017 C 599.41963,1067.114 594.24033,1101.0025 595.12255,1119.8578 C 596.0043,1138.703 603.25624,1159.9568 622.46718,1168.8267 C 641.88605,1177.7925 671.78642,1179.038 696.58702,1165.6811 C 721.38762,1152.3241 753.98804,1095.3556 767.56128,1068.3724 C 781.18513,1041.2885 806.32235,953.87507 812.22208,918.60385 C 818.12181,883.33264 814.77262,877.30308 807.6046,869.54836 C 810.2449,841.70821 806.10488,814.61293 820.71429,782.36218 C 790.46528,794.18788 783.332,822.52288 772.3954,847.86726 C 764.39449,796.93433 772.60456,776.59407 775.71429,746.6479 C 746.64953,761.42581 732.85278,793.76192 730.71429,839.50504 C 719.79034,838.20084 709.32285,835.07081 697.14286,838.79075 C 696.87882,792.76741 695.6793,761.90134 706.05349,724.58426 C 652.79802,745.61112 643.10621,831.17836 650,837.36218 C 639.11718,837.89718 628.62892,836.06488 617.14286,840.21933 C 617.78178,797.64798 616.8824,755.31072 587.14286,717.36218 C 587.14286,717.36218 556.1848,798.28452 555.71429,820.93361 C 555.24378,843.5827 565.16588,861.09949 565.16588,861.09949 C 565.16588,861.09949 556.59781,897.84 558.86729,919.33172 C 561.16314,941.07318 579.31019,979.00789 586.13271,997.98981 z" | ||
1011 | id="path3679" | ||
1012 | sodipodi:nodetypes="czzzzzzcccccccccczczz" /> | ||
1013 | </clipPath> | ||
1014 | <filter | ||
1015 | inkscape:collect="always" | ||
1016 | id="filter3898"> | ||
1017 | <feGaussianBlur | ||
1018 | inkscape:collect="always" | ||
1019 | stdDeviation="10.892985" | ||
1020 | id="feGaussianBlur3900" /> | ||
1021 | </filter> | ||
1022 | <filter | ||
1023 | inkscape:collect="always" | ||
1024 | id="filter4130" | ||
1025 | x="-0.49509686" | ||
1026 | width="1.9901937" | ||
1027 | y="-0.26708817" | ||
1028 | height="1.5341763"> | ||
1029 | <feGaussianBlur | ||
1030 | inkscape:collect="always" | ||
1031 | stdDeviation="10.730622" | ||
1032 | id="feGaussianBlur4132" /> | ||
1033 | </filter> | ||
1034 | <filter | ||
1035 | inkscape:collect="always" | ||
1036 | id="filter4141" | ||
1037 | x="-0.40611032" | ||
1038 | width="1.8122206" | ||
1039 | y="-0.30260596" | ||
1040 | height="1.6052119"> | ||
1041 | <feGaussianBlur | ||
1042 | inkscape:collect="always" | ||
1043 | stdDeviation="9.8586086" | ||
1044 | id="feGaussianBlur4143" /> | ||
1045 | </filter> | ||
1046 | <clipPath | ||
1047 | clipPathUnits="userSpaceOnUse" | ||
1048 | id="clipPath4177"> | ||
1049 | <path | ||
1050 | sodipodi:nodetypes="czzzzzzcccccccccczczz" | ||
1051 | id="path4179" | ||
1052 | d="M 586.13271,997.98981 C 592.92681,1016.8926 596.6264,1031.2895 598.02301,1049.2017 C 599.41963,1067.114 594.24033,1101.0025 595.12255,1119.8578 C 596.0043,1138.703 603.25624,1159.9568 622.46718,1168.8267 C 641.88605,1177.7925 671.78642,1179.038 696.58702,1165.6811 C 721.38762,1152.3241 753.98804,1095.3556 767.56128,1068.3724 C 781.18513,1041.2885 806.32235,953.87507 812.22208,918.60385 C 818.12181,883.33264 814.77262,877.30308 807.6046,869.54836 C 810.2449,841.70821 806.10488,814.61293 820.71429,782.36218 C 790.46528,794.18788 783.332,822.52288 772.3954,847.86726 C 764.39449,796.93433 772.60456,776.59407 775.71429,746.6479 C 746.64953,761.42581 732.85278,793.76192 730.71429,839.50504 C 719.79034,838.20084 709.32285,835.07081 697.14286,838.79075 C 696.87882,792.76741 695.6793,761.90134 706.05349,724.58426 C 652.79802,745.61112 643.10621,831.17836 650,837.36218 C 639.11718,837.89718 628.62892,836.06488 617.14286,840.21933 C 617.78178,797.64798 616.8824,755.31072 587.14286,717.36218 C 587.14286,717.36218 556.1848,798.28452 555.71429,820.93361 C 555.24378,843.5827 565.16588,861.09949 565.16588,861.09949 C 565.16588,861.09949 556.59781,897.84 558.86729,919.33172 C 561.16314,941.07318 579.31019,979.00789 586.13271,997.98981 z" | ||
1053 | style="opacity:1;fill:#ada469;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
1054 | </clipPath> | ||
1055 | <filter | ||
1056 | inkscape:collect="always" | ||
1057 | id="filter4185"> | ||
1058 | <feGaussianBlur | ||
1059 | inkscape:collect="always" | ||
1060 | stdDeviation="3.6164709" | ||
1061 | id="feGaussianBlur4187" /> | ||
1062 | </filter> | ||
1063 | <filter | ||
1064 | inkscape:collect="always" | ||
1065 | id="filter4105"> | ||
1066 | <feGaussianBlur | ||
1067 | inkscape:collect="always" | ||
1068 | stdDeviation="3.8640966" | ||
1069 | id="feGaussianBlur4107" /> | ||
1070 | </filter> | ||
1071 | <clipPath | ||
1072 | clipPathUnits="userSpaceOnUse" | ||
1073 | id="clipPath2833"> | ||
1074 | <path | ||
1075 | style="opacity:1;fill:#292929;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
1076 | d="M 569.03125,1018.7776 C 564.74554,1019.4919 541.4031,1022.3957 511.17411,1028.7776 C 480.94512,1035.1595 453.86016,1033.7437 375.38803,1046.1072 C 295.53625,1058.688 281.32367,1088.6495 267.26578,1093.1715 C 252.56564,1097.9001 121.88839,1027.349 121.88839,1027.349 L 126.17411,933.06329 C 126.17411,933.06329 212.05962,916.86235 238.31696,899.49186 C 264.57431,882.12137 283.89934,849.82588 297.60268,828.06329 C 311.30602,806.3007 330.45982,756.63471 330.45982,756.63471 L 569.03125,1018.7776 z" | ||
1077 | id="path2835" | ||
1078 | sodipodi:nodetypes="czzzcczzcc" /> | ||
1079 | </clipPath> | ||
1080 | <linearGradient | ||
1081 | inkscape:collect="always" | ||
1082 | xlink:href="#linearGradient2843" | ||
1083 | id="linearGradient2841" | ||
1084 | gradientUnits="userSpaceOnUse" | ||
1085 | x1="347.89655" | ||
1086 | y1="1070.2124" | ||
1087 | x2="275.58191" | ||
1088 | y2="867.97992" /> | ||
1089 | <linearGradient | ||
1090 | inkscape:collect="always" | ||
1091 | xlink:href="#linearGradient3627" | ||
1092 | id="linearGradient3688" | ||
1093 | gradientUnits="userSpaceOnUse" | ||
1094 | x1="699.32867" | ||
1095 | y1="269.76755" | ||
1096 | x2="698.97504" | ||
1097 | y2="346.1351" /> | ||
1098 | <mask | ||
1099 | maskUnits="userSpaceOnUse" | ||
1100 | id="mask3684"> | ||
1101 | <path | ||
1102 | sodipodi:type="arc" | ||
1103 | style="opacity:1;fill:url(#linearGradient3688);fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:0.43724918px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
1104 | id="path3686" | ||
1105 | sodipodi:cx="579.474" | ||
1106 | sodipodi:cy="260.57516" | ||
1107 | sodipodi:rx="192.6866" | ||
1108 | sodipodi:ry="164.04877" | ||
1109 | d="M 772.1606,260.57516 A 192.6866,164.04877 0 1 1 386.7874,260.57516 A 192.6866,164.04877 0 1 1 772.1606,260.57516 z" | ||
1110 | transform="translate(-174.03125,62.156036)" /> | ||
1111 | </mask> | ||
1112 | <clipPath | ||
1113 | clipPathUnits="userSpaceOnUse" | ||
1114 | id="clipPath3622"> | ||
1115 | <path | ||
1116 | style="opacity:1;fill:#ada469;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
1117 | d="M 266.27183,924.57186 C 264.86456,943.37307 265.12693,957.32289 268.35357,973.87514 C 271.58022,990.42748 284.75965,1019.7825 288.68797,1037.0589 C 292.61419,1054.326 291.3821,1075.3685 276.22853,1088.2071 C 260.91092,1101.1845 234.17726,1109.806 208.39623,1103.9409 C 182.61517,1098.0756 138.84716,1054.7175 119.80604,1033.7126 C 100.6939,1012.6293 56.045183,939.86194 41.867508,909.43681 C 27.689836,879.01169 29.207903,872.71824 33.747793,863.90708 C 24.381071,839.38658 21.334081,813.84027 0.035335518,788.33044 C 30.360815,791.44488 43.915625,815.28677 60.161025,835.47019 C 54.631129,787.39416 42.10631,771.05369 31.787073,744.74589 C 61.781368,750.82755 82.366433,776.61829 95.766856,817.45839 C 105.32101,813.54048 114.00462,808.08545 125.95427,808.39719 C 114.65677,766.70139 108.00481,738.48135 89.267015,707.32725 C 142.70898,712.99758 172.92404,787.96657 168.23844,795.28805 C 178.21641,793.04406 187.24409,788.75767 198.67497,789.63638 C 187.42601,751.28936 177.62716,712.76848 195.01526,670.9882 C 195.01526,670.9882 243.30204,736.42507 249.40492,756.79397 C 255.50779,777.16288 250.92373,795.49449 250.92373,795.49449 C 250.92373,795.49449 267.8833,826.57978 271.21765,846.58862 C 274.59075,866.82997 267.68496,905.69194 266.27183,924.57186 z" | ||
1118 | id="path3624" | ||
1119 | sodipodi:nodetypes="czzzzzzcccccccccczczz" /> | ||
1120 | </clipPath> | ||
1121 | <clipPath | ||
1122 | clipPathUnits="userSpaceOnUse" | ||
1123 | id="clipPath3636"> | ||
1124 | <path | ||
1125 | style="opacity:1;fill:#ada469;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
1126 | d="M 760.16396,935.83377 C 766.95806,954.73656 770.65765,969.13346 772.05426,987.04566 C 773.45088,1004.958 768.27158,1038.8465 769.1538,1057.7018 C 770.03555,1076.547 777.28749,1097.8008 796.49843,1106.6707 C 815.9173,1115.6365 845.81767,1116.882 870.61827,1103.5251 C 895.41887,1090.1681 928.01929,1033.1996 941.59253,1006.2164 C 955.21638,979.13246 980.3536,891.71903 986.25333,856.44781 C 992.15306,821.1766 988.80387,815.14704 981.63585,807.39232 C 984.27615,779.55217 980.13613,752.45689 994.74554,720.20614 C 964.49653,732.03184 957.36325,760.36684 946.42665,785.71122 C 938.42574,734.77829 946.63581,714.43803 949.74554,684.49186 C 920.68078,699.26977 906.88403,731.60588 904.74554,777.349 C 893.82159,776.0448 883.3541,772.91477 871.17411,776.63471 C 870.91007,730.61137 869.71055,699.7453 880.08474,662.42822 C 826.82927,683.45508 817.13746,769.02232 824.03125,775.20614 C 813.14843,775.74114 802.66017,773.90884 791.17411,778.06329 C 791.81303,735.49194 790.91365,693.15468 761.17411,655.20614 C 761.17411,655.20614 730.21605,736.12848 729.74554,758.77757 C 729.27503,781.42666 739.19713,798.94345 739.19713,798.94345 C 739.19713,798.94345 730.62906,835.68396 732.89854,857.17568 C 735.19439,878.91714 753.34144,916.85185 760.16396,935.83377 z" | ||
1127 | id="path3638" | ||
1128 | sodipodi:nodetypes="czzzzzzcccccccccczczz" /> | ||
1129 | </clipPath> | ||
1130 | <linearGradient | ||
1131 | inkscape:collect="always" | ||
1132 | xlink:href="#linearGradient3660" | ||
1133 | id="linearGradient3666" | ||
1134 | x1="1255.7386" | ||
1135 | y1="667.09216" | ||
1136 | x2="893.69995" | ||
1137 | y2="858.01099" | ||
1138 | gradientUnits="userSpaceOnUse" /> | ||
1139 | <filter | ||
1140 | inkscape:collect="always" | ||
1141 | id="filter3779" | ||
1142 | x="-0.087980822" | ||
1143 | width="1.1759616" | ||
1144 | y="-0.17728332" | ||
1145 | height="1.3545666"> | ||
1146 | <feGaussianBlur | ||
1147 | inkscape:collect="always" | ||
1148 | stdDeviation="16.340344" | ||
1149 | id="feGaussianBlur3781" /> | ||
1150 | </filter> | ||
1151 | <filter | ||
1152 | id="filter3785" | ||
1153 | inkscape:label="White Fur"> | ||
1154 | <feTurbulence | ||
1155 | id="feTurbulence3787" | ||
1156 | in="SourceAlpha" | ||
1157 | type="fractalNoise" | ||
1158 | baseFrequency="0.24044943820224721" | ||
1159 | numOctaves="10" | ||
1160 | seed="655" | ||
1161 | result="result0" /> | ||
1162 | <feDisplacementMap | ||
1163 | id="feDisplacementMap3789" | ||
1164 | in="SourceGraphic" | ||
1165 | in2="result0" | ||
1166 | scale="62" | ||
1167 | xChannelSelector="B" | ||
1168 | yChannelSelector="G" /> | ||
1169 | </filter> | ||
1170 | <filter | ||
1171 | inkscape:collect="always" | ||
1172 | id="filter3677"> | ||
1173 | <feGaussianBlur | ||
1174 | inkscape:collect="always" | ||
1175 | stdDeviation="2.0397518" | ||
1176 | id="feGaussianBlur3679" /> | ||
1177 | </filter> | ||
1178 | <clipPath | ||
1179 | clipPathUnits="userSpaceOnUse" | ||
1180 | id="clipPath3722"> | ||
1181 | <path | ||
1182 | style="opacity:1;fill:#121212;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
1183 | d="M 709.28572,844.50504 C 763.57143,843.07647 835.32072,829.45305 879.28572,817.71932 C 923.33843,805.96218 1005.172,781.37208 1054.6428,759.86218 C 1103.9821,738.40946 1168.2465,700.58058 1208.9286,667.71933 C 1249.4367,634.99864 1261.3185,611.89952 1269.6429,634.1479 C 1278.012,656.51569 1253.2359,690.47352 1231.7857,715.21933 C 1210.1816,740.14273 1179.0544,767.92466 1132.8571,804.50504 C 1086.6598,841.08542 976.77458,906.08967 920,933.07647 C 862.93394,960.20183 791.79666,991.31489 747.85714,1005.5765 C 703.91762,1019.8381 616.42857,1036.6479 616.42857,1036.6479 L 709.28572,844.50504 z" | ||
1184 | id="path3724" | ||
1185 | sodipodi:nodetypes="czzzzzzzzcc" /> | ||
1186 | </clipPath> | ||
1187 | <clipPath | ||
1188 | clipPathUnits="userSpaceOnUse" | ||
1189 | id="clipPath3986"> | ||
1190 | <path | ||
1191 | style="opacity:1;fill:#121212;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
1192 | d="M 709.28572,844.50504 C 763.57143,843.07647 835.32072,829.45305 879.28572,817.71932 C 923.33843,805.96218 1005.172,781.37208 1054.6428,759.86218 C 1103.9821,738.40946 1168.2465,700.58058 1208.9286,667.71933 C 1249.4367,634.99864 1261.3185,611.89952 1269.6429,634.1479 C 1278.012,656.51569 1253.2359,690.47352 1231.7857,715.21933 C 1210.1816,740.14273 1179.0544,767.92466 1132.8571,804.50504 C 1086.6598,841.08542 976.77458,906.08967 920,933.07647 C 862.93394,960.20183 791.79666,991.31489 747.85714,1005.5765 C 703.91762,1019.8381 616.42857,1036.6479 616.42857,1036.6479 L 709.28572,844.50504 z" | ||
1193 | id="path3988" | ||
1194 | sodipodi:nodetypes="czzzzzzzzcc" /> | ||
1195 | </clipPath> | ||
1196 | <clipPath | ||
1197 | clipPathUnits="userSpaceOnUse" | ||
1198 | id="clipPath3992"> | ||
1199 | <path | ||
1200 | style="opacity:1;fill:#121212;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
1201 | d="M 709.28572,844.50504 C 763.57143,843.07647 835.32072,829.45305 879.28572,817.71932 C 923.33843,805.96218 1005.172,781.37208 1054.6428,759.86218 C 1103.9821,738.40946 1168.2465,700.58058 1208.9286,667.71933 C 1249.4367,634.99864 1261.3185,611.89952 1269.6429,634.1479 C 1278.012,656.51569 1253.2359,690.47352 1231.7857,715.21933 C 1210.1816,740.14273 1179.0544,767.92466 1132.8571,804.50504 C 1086.6598,841.08542 976.77458,906.08967 920,933.07647 C 862.93394,960.20183 791.79666,991.31489 747.85714,1005.5765 C 703.91762,1019.8381 616.42857,1036.6479 616.42857,1036.6479 L 709.28572,844.50504 z" | ||
1202 | id="path3994" | ||
1203 | sodipodi:nodetypes="czzzzzzzzcc" /> | ||
1204 | </clipPath> | ||
1205 | <clipPath | ||
1206 | clipPathUnits="userSpaceOnUse" | ||
1207 | id="clipPath3998"> | ||
1208 | <path | ||
1209 | style="opacity:1;fill:#262f2f;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
1210 | d="M 178.21428,274.14789 C 174.40985,248.88366 161.40456,223.50987 161.05748,198.62266 C 160.87122,185.26714 164.33033,172.05175 174.81301,159.06861 C 211.16003,93.772775 291.75392,74.373925 360.74767,67.603183 C 447.67006,56.586382 545.66034,85.543255 594.11901,163.00447 C 648.24303,238.73777 650.79377,335.54359 674.73105,422.53242 C 704.16884,549.66002 729.51019,678.74656 735.12329,809.38277 C 732.05981,887.56462 726.69695,974.56692 674.62008,1037.5169 C 626.59354,1087.8743 551.83361,1087.5699 487.5502,1096.5192 C 396.99481,1101.1742 303.19867,1080.3734 225.7663,1032.321 C 160.99066,994.38099 130.03611,918.84237 128.4869,846.30142 C 120.09773,766.42626 154.87842,692.49291 180.1073,619.14181 C 187.57791,536.38074 189.52016,452.89406 189.76064,369.75697 C 188.92382,337.56153 182.67111,305.93964 178.21428,274.14789 z" | ||
1211 | id="path4000" | ||
1212 | sodipodi:nodetypes="cscccccccccccc" /> | ||
1213 | </clipPath> | ||
1214 | <filter | ||
1215 | inkscape:collect="always" | ||
1216 | id="filter4002" | ||
1217 | x="-0.24334238" | ||
1218 | width="1.4866848" | ||
1219 | y="-0.39104807" | ||
1220 | height="1.7820961"> | ||
1221 | <feGaussianBlur | ||
1222 | inkscape:collect="always" | ||
1223 | stdDeviation="14.589518" | ||
1224 | id="feGaussianBlur4004" /> | ||
1225 | </filter> | ||
1226 | <filter | ||
1227 | inkscape:collect="always" | ||
1228 | id="filter4010" | ||
1229 | x="-0.14577261" | ||
1230 | width="1.2915452" | ||
1231 | y="-0.23523259" | ||
1232 | height="1.4704652"> | ||
1233 | <feGaussianBlur | ||
1234 | inkscape:collect="always" | ||
1235 | stdDeviation="4.4442907" | ||
1236 | id="feGaussianBlur4012" /> | ||
1237 | </filter> | ||
1238 | <filter | ||
1239 | inkscape:collect="always" | ||
1240 | id="filter4053"> | ||
1241 | <feGaussianBlur | ||
1242 | inkscape:collect="always" | ||
1243 | stdDeviation="0.6062947" | ||
1244 | id="feGaussianBlur4055" /> | ||
1245 | </filter> | ||
1246 | <filter | ||
1247 | inkscape:collect="always" | ||
1248 | id="filter4079"> | ||
1249 | <feGaussianBlur | ||
1250 | inkscape:collect="always" | ||
1251 | stdDeviation="6.5887624" | ||
1252 | id="feGaussianBlur4081" /> | ||
1253 | </filter> | ||
1254 | <filter | ||
1255 | inkscape:collect="always" | ||
1256 | id="filter4083"> | ||
1257 | <feGaussianBlur | ||
1258 | inkscape:collect="always" | ||
1259 | stdDeviation="1.5052066" | ||
1260 | id="feGaussianBlur4085" /> | ||
1261 | </filter> | ||
1262 | <radialGradient | ||
1263 | inkscape:collect="always" | ||
1264 | xlink:href="#linearGradient4113" | ||
1265 | id="radialGradient4119" | ||
1266 | cx="296.33783" | ||
1267 | cy="427.17749" | ||
1268 | fx="296.33783" | ||
1269 | fy="427.17749" | ||
1270 | r="19.704132" | ||
1271 | gradientUnits="userSpaceOnUse" | ||
1272 | gradientTransform="matrix(2.9797125,0,0,2.9797125,-599.28727,-827.0855)" /> | ||
1273 | <filter | ||
1274 | inkscape:collect="always" | ||
1275 | id="filter6949" | ||
1276 | x="-0.10294895" | ||
1277 | width="1.2058979" | ||
1278 | y="-0.34224695" | ||
1279 | height="1.6844939"> | ||
1280 | <feGaussianBlur | ||
1281 | inkscape:collect="always" | ||
1282 | stdDeviation="1.1675612" | ||
1283 | id="feGaussianBlur6951" /> | ||
1284 | </filter> | ||
1285 | <filter | ||
1286 | inkscape:collect="always" | ||
1287 | id="filter6953" | ||
1288 | x="-0.098320946" | ||
1289 | width="1.1966419" | ||
1290 | y="-0.19750816" | ||
1291 | height="1.3950163"> | ||
1292 | <feGaussianBlur | ||
1293 | inkscape:collect="always" | ||
1294 | stdDeviation="1.1675612" | ||
1295 | id="feGaussianBlur6955" /> | ||
1296 | </filter> | ||
1297 | <filter | ||
1298 | inkscape:collect="always" | ||
1299 | id="filter6957" | ||
1300 | x="-0.098213427" | ||
1301 | width="1.1964267" | ||
1302 | y="-0.19838208" | ||
1303 | height="1.3967642"> | ||
1304 | <feGaussianBlur | ||
1305 | inkscape:collect="always" | ||
1306 | stdDeviation="1.1675612" | ||
1307 | id="feGaussianBlur6959" /> | ||
1308 | </filter> | ||
1309 | <filter | ||
1310 | inkscape:collect="always" | ||
1311 | id="filter6961" | ||
1312 | x="-0.09919104" | ||
1313 | width="1.1983821" | ||
1314 | y="-0.22643611" | ||
1315 | height="1.4528722"> | ||
1316 | <feGaussianBlur | ||
1317 | inkscape:collect="always" | ||
1318 | stdDeviation="1.1675612" | ||
1319 | id="feGaussianBlur6963" /> | ||
1320 | </filter> | ||
1321 | <filter | ||
1322 | inkscape:collect="always" | ||
1323 | id="filter6965" | ||
1324 | x="-0.099081434" | ||
1325 | width="1.1981629" | ||
1326 | y="-0.22529824" | ||
1327 | height="1.4505965"> | ||
1328 | <feGaussianBlur | ||
1329 | inkscape:collect="always" | ||
1330 | stdDeviation="1.1675612" | ||
1331 | id="feGaussianBlur6967" /> | ||
1332 | </filter> | ||
1333 | <filter | ||
1334 | inkscape:collect="always" | ||
1335 | id="filter6969" | ||
1336 | x="-0.10450897" | ||
1337 | width="1.2090179" | ||
1338 | y="-0.40468886" | ||
1339 | height="1.8093777"> | ||
1340 | <feGaussianBlur | ||
1341 | inkscape:collect="always" | ||
1342 | stdDeviation="1.1675612" | ||
1343 | id="feGaussianBlur6971" /> | ||
1344 | </filter> | ||
1345 | <filter | ||
1346 | inkscape:collect="always" | ||
1347 | id="filter6973" | ||
1348 | x="-0.10330495" | ||
1349 | width="1.2066098" | ||
1350 | y="-0.36439717" | ||
1351 | height="1.7287945"> | ||
1352 | <feGaussianBlur | ||
1353 | inkscape:collect="always" | ||
1354 | stdDeviation="1.1675612" | ||
1355 | id="feGaussianBlur6975" /> | ||
1356 | </filter> | ||
1357 | <filter | ||
1358 | inkscape:collect="always" | ||
1359 | id="filter6977" | ||
1360 | x="-0.10224481" | ||
1361 | width="1.2044896" | ||
1362 | y="-0.32371372" | ||
1363 | height="1.6474274"> | ||
1364 | <feGaussianBlur | ||
1365 | inkscape:collect="always" | ||
1366 | stdDeviation="1.1675612" | ||
1367 | id="feGaussianBlur6979" /> | ||
1368 | </filter> | ||
1369 | <filter | ||
1370 | inkscape:collect="always" | ||
1371 | id="filter6981" | ||
1372 | x="-0.10052545" | ||
1373 | width="1.2010509" | ||
1374 | y="-0.2742162" | ||
1375 | height="1.5484324"> | ||
1376 | <feGaussianBlur | ||
1377 | inkscape:collect="always" | ||
1378 | stdDeviation="1.1675612" | ||
1379 | id="feGaussianBlur6983" /> | ||
1380 | </filter> | ||
1381 | <filter | ||
1382 | inkscape:collect="always" | ||
1383 | id="filter6985" | ||
1384 | x="-0.098428868" | ||
1385 | width="1.1968577" | ||
1386 | y="-0.20853186" | ||
1387 | height="1.4170637"> | ||
1388 | <feGaussianBlur | ||
1389 | inkscape:collect="always" | ||
1390 | stdDeviation="1.1675612" | ||
1391 | id="feGaussianBlur6987" /> | ||
1392 | </filter> | ||
1393 | <filter | ||
1394 | inkscape:collect="always" | ||
1395 | id="filter6989" | ||
1396 | x="-0.098428868" | ||
1397 | width="1.1968577" | ||
1398 | y="-0.20287035" | ||
1399 | height="1.4057407"> | ||
1400 | <feGaussianBlur | ||
1401 | inkscape:collect="always" | ||
1402 | stdDeviation="1.1675612" | ||
1403 | id="feGaussianBlur6991" /> | ||
1404 | </filter> | ||
1405 | <filter | ||
1406 | inkscape:collect="always" | ||
1407 | id="filter6993" | ||
1408 | x="-0.098213255" | ||
1409 | width="1.1964265" | ||
1410 | y="-0.19838208" | ||
1411 | height="1.3967642"> | ||
1412 | <feGaussianBlur | ||
1413 | inkscape:collect="always" | ||
1414 | stdDeviation="1.1675612" | ||
1415 | id="feGaussianBlur6995" /> | ||
1416 | </filter> | ||
1417 | <filter | ||
1418 | inkscape:collect="always" | ||
1419 | id="filter6997"> | ||
1420 | <feGaussianBlur | ||
1421 | inkscape:collect="always" | ||
1422 | stdDeviation="1.1675612" | ||
1423 | id="feGaussianBlur6999" /> | ||
1424 | </filter> | ||
1425 | <filter | ||
1426 | inkscape:collect="always" | ||
1427 | id="filter7001"> | ||
1428 | <feGaussianBlur | ||
1429 | inkscape:collect="always" | ||
1430 | stdDeviation="1.1675612" | ||
1431 | id="feGaussianBlur7003" /> | ||
1432 | </filter> | ||
1433 | <filter | ||
1434 | inkscape:collect="always" | ||
1435 | id="filter7285" | ||
1436 | x="-0.030884685" | ||
1437 | width="1.0617694" | ||
1438 | y="-0.10267408" | ||
1439 | height="1.2053483"> | ||
1440 | <feGaussianBlur | ||
1441 | inkscape:collect="always" | ||
1442 | stdDeviation="0.35026836" | ||
1443 | id="feGaussianBlur7287" /> | ||
1444 | </filter> | ||
1445 | <filter | ||
1446 | inkscape:collect="always" | ||
1447 | id="filter7289"> | ||
1448 | <feGaussianBlur | ||
1449 | inkscape:collect="always" | ||
1450 | stdDeviation="0.35026836" | ||
1451 | id="feGaussianBlur7291" /> | ||
1452 | </filter> | ||
1453 | <filter | ||
1454 | inkscape:collect="always" | ||
1455 | id="filter7293"> | ||
1456 | <feGaussianBlur | ||
1457 | inkscape:collect="always" | ||
1458 | stdDeviation="0.35026836" | ||
1459 | id="feGaussianBlur7295" /> | ||
1460 | </filter> | ||
1461 | <filter | ||
1462 | inkscape:collect="always" | ||
1463 | id="filter7297"> | ||
1464 | <feGaussianBlur | ||
1465 | inkscape:collect="always" | ||
1466 | stdDeviation="0.35026836" | ||
1467 | id="feGaussianBlur7299" /> | ||
1468 | </filter> | ||
1469 | <filter | ||
1470 | inkscape:collect="always" | ||
1471 | id="filter7301"> | ||
1472 | <feGaussianBlur | ||
1473 | inkscape:collect="always" | ||
1474 | stdDeviation="0.35026836" | ||
1475 | id="feGaussianBlur7303" /> | ||
1476 | </filter> | ||
1477 | <filter | ||
1478 | inkscape:collect="always" | ||
1479 | id="filter7305"> | ||
1480 | <feGaussianBlur | ||
1481 | inkscape:collect="always" | ||
1482 | stdDeviation="0.35026836" | ||
1483 | id="feGaussianBlur7307" /> | ||
1484 | </filter> | ||
1485 | <filter | ||
1486 | inkscape:collect="always" | ||
1487 | id="filter7309"> | ||
1488 | <feGaussianBlur | ||
1489 | inkscape:collect="always" | ||
1490 | stdDeviation="0.35026836" | ||
1491 | id="feGaussianBlur7311" /> | ||
1492 | </filter> | ||
1493 | <filter | ||
1494 | inkscape:collect="always" | ||
1495 | id="filter7313"> | ||
1496 | <feGaussianBlur | ||
1497 | inkscape:collect="always" | ||
1498 | stdDeviation="0.35026836" | ||
1499 | id="feGaussianBlur7315" /> | ||
1500 | </filter> | ||
1501 | <filter | ||
1502 | inkscape:collect="always" | ||
1503 | id="filter7317"> | ||
1504 | <feGaussianBlur | ||
1505 | inkscape:collect="always" | ||
1506 | stdDeviation="0.35026836" | ||
1507 | id="feGaussianBlur7319" /> | ||
1508 | </filter> | ||
1509 | <filter | ||
1510 | inkscape:collect="always" | ||
1511 | id="filter7321"> | ||
1512 | <feGaussianBlur | ||
1513 | inkscape:collect="always" | ||
1514 | stdDeviation="0.35026836" | ||
1515 | id="feGaussianBlur7323" /> | ||
1516 | </filter> | ||
1517 | <filter | ||
1518 | inkscape:collect="always" | ||
1519 | id="filter7325" | ||
1520 | x="-0.031352691" | ||
1521 | width="1.0627054" | ||
1522 | y="-0.12140666" | ||
1523 | height="1.2428133"> | ||
1524 | <feGaussianBlur | ||
1525 | inkscape:collect="always" | ||
1526 | stdDeviation="0.35026836" | ||
1527 | id="feGaussianBlur7327" /> | ||
1528 | </filter> | ||
1529 | <filter | ||
1530 | inkscape:collect="always" | ||
1531 | id="filter7329" | ||
1532 | x="-0.030991485" | ||
1533 | width="1.061983" | ||
1534 | y="-0.10931916" | ||
1535 | height="1.2186383"> | ||
1536 | <feGaussianBlur | ||
1537 | inkscape:collect="always" | ||
1538 | stdDeviation="0.35026836" | ||
1539 | id="feGaussianBlur7331" /> | ||
1540 | </filter> | ||
1541 | <filter | ||
1542 | inkscape:collect="always" | ||
1543 | id="filter7333"> | ||
1544 | <feGaussianBlur | ||
1545 | inkscape:collect="always" | ||
1546 | stdDeviation="0.35026836" | ||
1547 | id="feGaussianBlur7335" /> | ||
1548 | </filter> | ||
1549 | <filter | ||
1550 | inkscape:collect="always" | ||
1551 | id="filter7337"> | ||
1552 | <feGaussianBlur | ||
1553 | inkscape:collect="always" | ||
1554 | stdDeviation="0.35026836" | ||
1555 | id="feGaussianBlur7339" /> | ||
1556 | </filter> | ||
1557 | <filter | ||
1558 | inkscape:collect="always" | ||
1559 | id="filter7345"> | ||
1560 | <feGaussianBlur | ||
1561 | inkscape:collect="always" | ||
1562 | stdDeviation="1.7233839" | ||
1563 | id="feGaussianBlur7347" /> | ||
1564 | </filter> | ||
1565 | <clipPath | ||
1566 | clipPathUnits="userSpaceOnUse" | ||
1567 | id="clipPath7421"> | ||
1568 | <path | ||
1569 | sodipodi:type="inkscape:offset" | ||
1570 | inkscape:radius="0" | ||
1571 | inkscape:original="M 1111.4062 -285.9375 L 1107.4688 -284.0625 C 1107.4283 -284.05228 1107.3692 -284.04201 1107.3438 -284.03125 C 1106.925 -283.8184 1107.1791 -283.93067 1106.6875 -283.71875 C 1106.2014 -283.50919 1104.9499 -283.13456 1102.5938 -282.25 C 1099.2626 -280.99942 1096.7895 -280.10016 1095.5938 -279.1875 C 1094.0576 -279.16623 1091.8733 -278.95419 1089.9375 -278.46875 C 1086.956 -277.72108 1085.0823 -277.29474 1083.1875 -276.875 C 1081.2927 -276.45527 1081.512 -276.23281 1080.3125 -276 C 1079.0159 -275.74833 1078.5911 -276.00899 1074.875 -275.21875 C 1071.3851 -274.4766 1065.9802 -273.28768 1064.7188 -272.53125 C 1063.1348 -272.71203 1060.8513 -272.85303 1058.875 -272.5625 C 1055.8346 -272.11554 1053.9588 -271.88974 1052.0312 -271.65625 C 1051.3758 -271.57687 1050.9902 -271.45547 1050.6875 -271.375 C 1050.2613 -271.24334 1050.0017 -271.11498 1049.3125 -271.03125 C 1048.0009 -270.87188 1047.5503 -271.18808 1043.7812 -270.75 C 1040.2273 -270.33691 1034.7758 -269.47718 1033.5312 -268.8125 C 1031.9322 -269.10979 1029.6735 -269.34669 1027.6875 -269.15625 C 1024.6287 -268.86293 1022.7155 -268.67226 1020.7812 -268.5 C 1018.847 -268.32773 1019.0926 -268.07763 1017.875 -267.96875 C 1016.5588 -267.85105 1016.1152 -268.13238 1012.3438 -267.71875 C 1008.8017 -267.3303 1003.3359 -266.50948 1002.0625 -265.84375 C 1000.4636 -266.13844 998.1753 -266.35076 996.1875 -266.15625 C 993.12921 -265.857 991.2463 -265.67601 989.3125 -265.5 C 988.65501 -265.44015 988.27245 -265.32144 987.96875 -265.25 C 987.54105 -265.13104 987.28525 -265.03193 986.59375 -264.96875 C 985.27775 -264.84849 984.834 -265.16363 981.0625 -264.75 C 977.50631 -264.35998 972.0569 -263.51084 970.8125 -262.84375 C 969.21381 -263.13793 966.95265 -263.36747 964.96875 -263.15625 C 961.91305 -262.83092 959.9947 -262.63001 958.0625 -262.4375 C 956.13031 -262.24499 956.37275 -261.99662 955.15625 -261.875 C 953.84137 -261.74353 953.3932 -262.03954 949.625 -261.59375 C 946.08611 -261.17509 940.6473 -260.30158 939.375 -259.625 C 937.77741 -259.90604 935.51505 -260.04543 933.53125 -259.8125 C 930.47927 -259.45413 928.58625 -259.24464 926.65625 -259.03125 C 926.00007 -258.95869 925.6156 -258.85856 925.3125 -258.78125 C 924.88571 -258.65402 924.6276 -258.51405 923.9375 -258.4375 C 922.62411 -258.29181 922.17015 -258.61152 918.40625 -258.125 C 914.85737 -257.66624 909.4276 -256.70598 908.1875 -256 C 906.59441 -256.24424 904.3537 -256.38135 902.375 -256.125 C 899.32741 -255.73018 897.4243 -255.47655 895.5 -255.21875 C 893.57571 -254.96096 893.7739 -254.72522 892.5625 -254.5625 C 891.25301 -254.3866 890.8153 -254.66688 887.0625 -254.09375 C 883.53821 -253.55551 878.1393 -252.39458 876.875 -251.65625 C 875.28751 -251.85979 873.0295 -251.91098 871.0625 -251.5625 C 868.03631 -251.02638 866.1636 -250.70081 864.25 -250.375 C 863.59941 -250.26423 863.2363 -250.10406 862.9375 -250 C 862.51681 -249.83512 862.27405 -249.6687 861.59375 -249.53125 C 860.29905 -249.26966 859.86665 -249.53745 856.15625 -248.71875 C 852.65777 -247.9468 847.31035 -246.33582 846.09375 -245.5 C 844.53085 -245.57745 842.33625 -245.41472 840.40625 -244.90625 C 837.43387 -244.12312 835.58855 -243.67416 833.71875 -243.15625 C 831.84875 -242.63835 832.0521 -242.38897 830.875 -242.0625 C 829.60251 -241.7096 829.17795 -241.95541 825.53125 -240.875 C 822.10657 -239.86037 816.88185 -237.94183 815.65625 -237.03125 C 814.11747 -237.01851 811.93645 -236.75903 810.03125 -236.15625 C 807.10027 -235.22891 805.2809 -234.69783 803.4375 -234.09375 C 802.81071 -233.88837 802.44585 -233.70117 802.15625 -233.5625 C 801.74867 -233.34889 801.50295 -233.15375 800.84375 -232.9375 C 799.58925 -232.52596 799.1576 -232.74846 795.5625 -231.5 C 792.17261 -230.32283 786.96755 -228.2863 785.78125 -227.34375 C 784.25737 -227.28408 782.1312 -226.94888 780.25 -226.28125 C 777.35261 -225.25296 775.55095 -224.60577 773.71875 -223.96875 C 771.88655 -223.33174 772.0909 -223.12021 770.9375 -222.71875 C 769.69071 -222.28479 769.27395 -222.51903 765.71875 -221.15625 C 762.38005 -219.87645 757.23165 -217.6737 756.03125 -216.6875 C 754.52407 -216.57981 752.39555 -216.1887 750.53125 -215.46875 C 747.66307 -214.36115 745.90735 -213.68719 744.09375 -213 C 743.47705 -212.76637 743.0973 -212.55797 742.8125 -212.40625 C 742.81251 -212.40625 742.8125 -212.37673 742.8125 -212.375 L 734.8125 -209.1875 L 736.625 -194.46875 C 736.36701 -194.52956 742.8125 -191.15625 742.8125 -191.15625 C 743.03891 -191.30093 743.26145 -191.42886 743.53125 -191.53125 C 744.61177 -191.94123 745.70285 -191.74702 749.53125 -193.21875 C 753.35977 -194.69049 754.7553 -195.22373 755.4375 -195.625 C 756.11711 -196.02478 757.04925 -196.50437 757.65625 -197.15625 C 759.48317 -197.294 761.22705 -197.64948 762.59375 -198.15625 C 765.56175 -199.25677 767.4691 -199.96244 769.375 -200.625 C 771.28081 -201.28754 771.72915 -202.03987 772.78125 -202.40625 C 773.87287 -202.78636 774.97635 -202.57163 778.84375 -203.9375 C 782.71115 -205.30336 784.1269 -205.76458 784.8125 -206.15625 C 785.51361 -206.55677 786.5133 -207.08923 787.125 -207.75 C 789.09581 -207.80466 790.94195 -208.13463 792.40625 -208.625 C 795.40777 -209.63008 797.3324 -210.24671 799.25 -210.875 C 800.78861 -211.3791 801.42415 -211.92177 802.15625 -212.3125 C 802.38647 -212.44681 802.63215 -212.56623 802.90625 -212.65625 C 804.00457 -213.01673 805.0877 -212.73762 809 -213.96875 C 812.91231 -215.19988 814.366 -215.6417 815.0625 -216 C 815.75641 -216.35697 816.6926 -216.79261 817.3125 -217.40625 C 819.17771 -217.42891 820.94835 -217.67308 822.34375 -218.09375 C 825.37415 -219.00729 827.33615 -219.52385 829.28125 -220.0625 C 831.22637 -220.60114 831.70745 -221.32702 832.78125 -221.625 C 833.89527 -221.93415 835.00125 -221.61761 838.96875 -222.65625 C 842.93625 -223.69488 844.38625 -224.08898 845.09375 -224.40625 C 845.82855 -224.73584 846.90765 -225.15997 847.53125 -225.78125 C 849.52907 -225.66525 851.3887 -225.80134 852.875 -226.15625 C 855.95311 -226.89125 857.9584 -227.25719 859.9375 -227.65625 C 861.52541 -227.97643 862.1818 -228.4468 862.9375 -228.75 C 863.17501 -228.8568 863.4044 -228.94276 863.6875 -229 C 864.82091 -229.22919 865.99215 -228.79107 870.03125 -229.5 C 874.07067 -230.20893 875.5315 -230.42709 876.25 -230.6875 C 876.96581 -230.94694 877.95435 -231.25474 878.59375 -231.78125 C 880.51795 -231.54176 882.34165 -231.55672 883.78125 -231.78125 C 886.90767 -232.26887 888.9358 -232.48192 890.9375 -232.75 C 892.93921 -233.01807 893.42625 -233.69514 894.53125 -233.84375 C 895.67767 -233.99793 896.8071 -233.54218 900.875 -234.0625 C 904.94281 -234.58282 906.43525 -234.75823 907.15625 -235 C 907.89337 -235.24714 908.95435 -235.58623 909.59375 -236.125 C 911.64375 -235.78947 913.56745 -235.72704 915.09375 -235.90625 C 918.23595 -236.27521 920.27375 -236.46561 922.28125 -236.6875 C 923.89207 -236.86552 924.5459 -237.2957 925.3125 -237.53125 C 925.55341 -237.61677 925.80655 -237.68685 926.09375 -237.71875 C 927.24345 -237.84647 928.39505 -237.3721 932.46875 -237.84375 C 936.54245 -238.3154 938.0278 -238.45435 938.75 -238.6875 C 939.46941 -238.91977 940.45025 -239.16096 941.09375 -239.65625 C 943.03005 -239.32279 944.8638 -239.25201 946.3125 -239.40625 C 949.45851 -239.7412 951.49 -239.92484 953.5 -240.125 C 955.50991 -240.32514 955.98415 -240.95139 957.09375 -241.0625 C 958.24485 -241.17778 959.39025 -240.69744 963.46875 -241.125 C 967.54725 -241.55256 969.05765 -241.68709 969.78125 -241.90625 C 970.52047 -242.13011 971.57685 -242.4195 972.21875 -242.9375 C 974.27575 -242.53883 976.2206 -242.4441 977.75 -242.59375 C 980.89871 -242.90185 982.9258 -243.067 984.9375 -243.25 C 986.55151 -243.39682 987.20055 -243.81055 987.96875 -244.03125 C 988.21005 -244.11211 988.4623 -244.16116 988.75 -244.1875 C 989.90211 -244.29295 991.0429 -243.79475 995.125 -244.1875 C 999.20711 -244.58025 1000.7139 -244.71834 1001.4375 -244.9375 C 1002.1584 -245.15583 1003.1371 -245.3852 1003.7812 -245.875 C 1005.7193 -245.52501 1007.5501 -245.42062 1009 -245.5625 C 1012.1487 -245.8706 1014.1758 -246.03575 1016.1875 -246.21875 C 1018.1991 -246.40174 1018.7017 -247.05677 1019.8125 -247.15625 C 1020.9648 -247.25948 1022.1047 -246.77142 1026.1875 -247.15625 C 1030.2704 -247.54107 1031.7762 -247.65725 1032.5 -247.875 C 1033.2393 -248.09743 1034.2956 -248.38949 1034.9375 -248.90625 C 1036.9949 -248.50448 1038.9404 -248.40292 1040.4688 -248.5625 C 1043.6153 -248.89102 1045.6458 -249.0852 1047.6562 -249.28125 C 1049.2692 -249.43854 1049.9219 -249.91273 1050.6875 -250.15625 C 1050.9282 -250.24429 1051.1507 -250.27762 1051.4375 -250.3125 C 1052.5858 -250.4522 1053.7542 -249.97259 1057.8125 -250.5625 C 1061.8708 -251.15242 1063.3743 -251.33964 1064.0938 -251.59375 C 1064.8104 -251.84691 1065.7684 -252.15182 1066.4062 -252.6875 C 1068.3259 -252.47556 1070.1262 -252.53609 1071.5625 -252.78125 C 1074.6816 -253.31365 1076.6741 -253.70986 1078.6562 -254.09375 C 1080.6383 -254.47762 1081.1305 -255.1334 1082.2188 -255.375 C 1083.3475 -255.62566 1084.489 -255.25871 1088.4688 -256.25 C 1092.4483 -257.24127 1093.8983 -257.6693 1094.5938 -258.03125 C 1095.316 -258.40725 1096.3555 -258.90183 1096.9688 -259.5625 C 1098.9317 -259.57454 1100.7625 -259.85355 1102.1875 -260.40625 C 1105.1387 -261.55085 1107.0607 -262.27567 1108.875 -263.15625 C 1110.3307 -263.86277 1111.1941 -264.85828 1111.4062 -265.15625 C 1111.6185 -265.4542 1111.5051 -265.8848 1111.5312 -265.90625 C 1111.5742 -265.94148 1111.8716 -266.00028 1112.0312 -266.34375 C 1112.8902 -268.19082 1114.3544 -271.97139 1114.4688 -272.65625 C 1114.5825 -273.33839 1114.6368 -274.00902 1114.6875 -274.40625 C 1114.7169 -274.63575 1114.5404 -275.28515 1114.5625 -275.34375 C 1114.5934 -275.42579 1114.8508 -275.59432 1114.9062 -275.84375 C 1115.1725 -277.04206 1114.9953 -278.05111 1114.7812 -279.46875 C 1114.5673 -280.88638 1113.8096 -284.08338 1113.1562 -284.9375 C 1112.4973 -285.79922 1111.9314 -285.94801 1111.4062 -285.9375 z " | ||
1572 | style="fill:#bcb786;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
1573 | id="path7423" | ||
1574 | d="M 1111.4062,-285.9375 L 1107.4688,-284.0625 C 1107.4283,-284.05228 1107.3692,-284.04201 1107.3438,-284.03125 C 1106.925,-283.8184 1107.1791,-283.93067 1106.6875,-283.71875 C 1106.2014,-283.50919 1104.9499,-283.13456 1102.5938,-282.25 C 1099.2626,-280.99942 1096.7895,-280.10016 1095.5938,-279.1875 C 1094.0576,-279.16623 1091.8733,-278.95419 1089.9375,-278.46875 C 1086.956,-277.72108 1085.0823,-277.29474 1083.1875,-276.875 C 1081.2927,-276.45527 1081.512,-276.23281 1080.3125,-276 C 1079.0159,-275.74833 1078.5911,-276.00899 1074.875,-275.21875 C 1071.3851,-274.4766 1065.9802,-273.28768 1064.7188,-272.53125 C 1063.1348,-272.71203 1060.8513,-272.85303 1058.875,-272.5625 C 1055.8346,-272.11554 1053.9588,-271.88974 1052.0312,-271.65625 C 1051.3758,-271.57687 1050.9902,-271.45547 1050.6875,-271.375 C 1050.2613,-271.24334 1050.0017,-271.11498 1049.3125,-271.03125 C 1048.0009,-270.87188 1047.5503,-271.18808 1043.7812,-270.75 C 1040.2273,-270.33691 1034.7758,-269.47718 1033.5312,-268.8125 C 1031.9322,-269.10979 1029.6735,-269.34669 1027.6875,-269.15625 C 1024.6287,-268.86293 1022.7155,-268.67226 1020.7812,-268.5 C 1018.847,-268.32773 1019.0926,-268.07763 1017.875,-267.96875 C 1016.5588,-267.85105 1016.1152,-268.13238 1012.3438,-267.71875 C 1008.8017,-267.3303 1003.3359,-266.50948 1002.0625,-265.84375 C 1000.4636,-266.13844 998.1753,-266.35076 996.1875,-266.15625 C 993.12921,-265.857 991.2463,-265.67601 989.3125,-265.5 C 988.65501,-265.44015 988.27245,-265.32144 987.96875,-265.25 C 987.54105,-265.13104 987.28525,-265.03193 986.59375,-264.96875 C 985.27775,-264.84849 984.834,-265.16363 981.0625,-264.75 C 977.50631,-264.35998 972.0569,-263.51084 970.8125,-262.84375 C 969.21381,-263.13793 966.95265,-263.36747 964.96875,-263.15625 C 961.91305,-262.83092 959.9947,-262.63001 958.0625,-262.4375 C 956.13031,-262.24499 956.37275,-261.99662 955.15625,-261.875 C 953.84137,-261.74353 953.3932,-262.03954 949.625,-261.59375 C 946.08611,-261.17509 940.6473,-260.30158 939.375,-259.625 C 937.77741,-259.90604 935.51505,-260.04543 933.53125,-259.8125 C 930.47927,-259.45413 928.58625,-259.24464 926.65625,-259.03125 C 926.00007,-258.95869 925.6156,-258.85856 925.3125,-258.78125 C 924.88571,-258.65402 924.6276,-258.51405 923.9375,-258.4375 C 922.62411,-258.29181 922.17015,-258.61152 918.40625,-258.125 C 914.85737,-257.66624 909.4276,-256.70598 908.1875,-256 C 906.59441,-256.24424 904.3537,-256.38135 902.375,-256.125 C 899.32741,-255.73018 897.4243,-255.47655 895.5,-255.21875 C 893.57571,-254.96096 893.7739,-254.72522 892.5625,-254.5625 C 891.25301,-254.3866 890.8153,-254.66688 887.0625,-254.09375 C 883.53821,-253.55551 878.1393,-252.39458 876.875,-251.65625 C 875.28751,-251.85979 873.0295,-251.91098 871.0625,-251.5625 C 868.03631,-251.02638 866.1636,-250.70081 864.25,-250.375 C 863.59941,-250.26423 863.2363,-250.10406 862.9375,-250 C 862.51681,-249.83512 862.27405,-249.6687 861.59375,-249.53125 C 860.29905,-249.26966 859.86665,-249.53745 856.15625,-248.71875 C 852.65777,-247.9468 847.31035,-246.33582 846.09375,-245.5 C 844.53085,-245.57745 842.33625,-245.41472 840.40625,-244.90625 C 837.43387,-244.12312 835.58855,-243.67416 833.71875,-243.15625 C 831.84875,-242.63835 832.0521,-242.38897 830.875,-242.0625 C 829.60251,-241.7096 829.17795,-241.95541 825.53125,-240.875 C 822.10657,-239.86037 816.88185,-237.94183 815.65625,-237.03125 C 814.11747,-237.01851 811.93645,-236.75903 810.03125,-236.15625 C 807.10027,-235.22891 805.2809,-234.69783 803.4375,-234.09375 C 802.81071,-233.88837 802.44585,-233.70117 802.15625,-233.5625 C 801.74867,-233.34889 801.50295,-233.15375 800.84375,-232.9375 C 799.58925,-232.52596 799.1576,-232.74846 795.5625,-231.5 C 792.17261,-230.32283 786.96755,-228.2863 785.78125,-227.34375 C 784.25737,-227.28408 782.1312,-226.94888 780.25,-226.28125 C 777.35261,-225.25296 775.55095,-224.60577 773.71875,-223.96875 C 771.88655,-223.33174 772.0909,-223.12021 770.9375,-222.71875 C 769.69071,-222.28479 769.27395,-222.51903 765.71875,-221.15625 C 762.38005,-219.87645 757.23165,-217.6737 756.03125,-216.6875 C 754.52407,-216.57981 752.39555,-216.1887 750.53125,-215.46875 C 747.66307,-214.36115 745.90735,-213.68719 744.09375,-213 C 743.47705,-212.76637 743.0973,-212.55797 742.8125,-212.40625 C 742.81251,-212.40625 742.8125,-212.37673 742.8125,-212.375 L 734.8125,-209.1875 L 736.625,-194.46875 C 736.36701,-194.52956 742.8125,-191.15625 742.8125,-191.15625 C 743.03891,-191.30093 743.26145,-191.42886 743.53125,-191.53125 C 744.61177,-191.94123 745.70285,-191.74702 749.53125,-193.21875 C 753.35977,-194.69049 754.7553,-195.22373 755.4375,-195.625 C 756.11711,-196.02478 757.04925,-196.50437 757.65625,-197.15625 C 759.48317,-197.294 761.22705,-197.64948 762.59375,-198.15625 C 765.56175,-199.25677 767.4691,-199.96244 769.375,-200.625 C 771.28081,-201.28754 771.72915,-202.03987 772.78125,-202.40625 C 773.87287,-202.78636 774.97635,-202.57163 778.84375,-203.9375 C 782.71115,-205.30336 784.1269,-205.76458 784.8125,-206.15625 C 785.51361,-206.55677 786.5133,-207.08923 787.125,-207.75 C 789.09581,-207.80466 790.94195,-208.13463 792.40625,-208.625 C 795.40777,-209.63008 797.3324,-210.24671 799.25,-210.875 C 800.78861,-211.3791 801.42415,-211.92177 802.15625,-212.3125 C 802.38647,-212.44681 802.63215,-212.56623 802.90625,-212.65625 C 804.00457,-213.01673 805.0877,-212.73762 809,-213.96875 C 812.91231,-215.19988 814.366,-215.6417 815.0625,-216 C 815.75641,-216.35697 816.6926,-216.79261 817.3125,-217.40625 C 819.17771,-217.42891 820.94835,-217.67308 822.34375,-218.09375 C 825.37415,-219.00729 827.33615,-219.52385 829.28125,-220.0625 C 831.22637,-220.60114 831.70745,-221.32702 832.78125,-221.625 C 833.89527,-221.93415 835.00125,-221.61761 838.96875,-222.65625 C 842.93625,-223.69488 844.38625,-224.08898 845.09375,-224.40625 C 845.82855,-224.73584 846.90765,-225.15997 847.53125,-225.78125 C 849.52907,-225.66525 851.3887,-225.80134 852.875,-226.15625 C 855.95311,-226.89125 857.9584,-227.25719 859.9375,-227.65625 C 861.52541,-227.97643 862.1818,-228.4468 862.9375,-228.75 C 863.17501,-228.8568 863.4044,-228.94276 863.6875,-229 C 864.82091,-229.22919 865.99215,-228.79107 870.03125,-229.5 C 874.07067,-230.20893 875.5315,-230.42709 876.25,-230.6875 C 876.96581,-230.94694 877.95435,-231.25474 878.59375,-231.78125 C 880.51795,-231.54176 882.34165,-231.55672 883.78125,-231.78125 C 886.90767,-232.26887 888.9358,-232.48192 890.9375,-232.75 C 892.93921,-233.01807 893.42625,-233.69514 894.53125,-233.84375 C 895.67767,-233.99793 896.8071,-233.54218 900.875,-234.0625 C 904.94281,-234.58282 906.43525,-234.75823 907.15625,-235 C 907.89337,-235.24714 908.95435,-235.58623 909.59375,-236.125 C 911.64375,-235.78947 913.56745,-235.72704 915.09375,-235.90625 C 918.23595,-236.27521 920.27375,-236.46561 922.28125,-236.6875 C 923.89207,-236.86552 924.5459,-237.2957 925.3125,-237.53125 C 925.55341,-237.61677 925.80655,-237.68685 926.09375,-237.71875 C 927.24345,-237.84647 928.39505,-237.3721 932.46875,-237.84375 C 936.54245,-238.3154 938.0278,-238.45435 938.75,-238.6875 C 939.46941,-238.91977 940.45025,-239.16096 941.09375,-239.65625 C 943.03005,-239.32279 944.8638,-239.25201 946.3125,-239.40625 C 949.45851,-239.7412 951.49,-239.92484 953.5,-240.125 C 955.50991,-240.32514 955.98415,-240.95139 957.09375,-241.0625 C 958.24485,-241.17778 959.39025,-240.69744 963.46875,-241.125 C 967.54725,-241.55256 969.05765,-241.68709 969.78125,-241.90625 C 970.52047,-242.13011 971.57685,-242.4195 972.21875,-242.9375 C 974.27575,-242.53883 976.2206,-242.4441 977.75,-242.59375 C 980.89871,-242.90185 982.9258,-243.067 984.9375,-243.25 C 986.55151,-243.39682 987.20055,-243.81055 987.96875,-244.03125 C 988.21005,-244.11211 988.4623,-244.16116 988.75,-244.1875 C 989.90211,-244.29295 991.0429,-243.79475 995.125,-244.1875 C 999.20711,-244.58025 1000.7139,-244.71834 1001.4375,-244.9375 C 1002.1584,-245.15583 1003.1371,-245.3852 1003.7812,-245.875 C 1005.7193,-245.52501 1007.5501,-245.42062 1009,-245.5625 C 1012.1487,-245.8706 1014.1758,-246.03575 1016.1875,-246.21875 C 1018.1991,-246.40174 1018.7017,-247.05677 1019.8125,-247.15625 C 1020.9648,-247.25948 1022.1047,-246.77142 1026.1875,-247.15625 C 1030.2704,-247.54107 1031.7762,-247.65725 1032.5,-247.875 C 1033.2393,-248.09743 1034.2956,-248.38949 1034.9375,-248.90625 C 1036.9949,-248.50448 1038.9404,-248.40292 1040.4688,-248.5625 C 1043.6153,-248.89102 1045.6458,-249.0852 1047.6562,-249.28125 C 1049.2692,-249.43854 1049.9219,-249.91273 1050.6875,-250.15625 C 1050.9282,-250.24429 1051.1507,-250.27762 1051.4375,-250.3125 C 1052.5858,-250.4522 1053.7542,-249.97259 1057.8125,-250.5625 C 1061.8708,-251.15242 1063.3743,-251.33964 1064.0938,-251.59375 C 1064.8104,-251.84691 1065.7684,-252.15182 1066.4062,-252.6875 C 1068.3259,-252.47556 1070.1262,-252.53609 1071.5625,-252.78125 C 1074.6816,-253.31365 1076.6741,-253.70986 1078.6562,-254.09375 C 1080.6383,-254.47762 1081.1305,-255.1334 1082.2188,-255.375 C 1083.3475,-255.62566 1084.489,-255.25871 1088.4688,-256.25 C 1092.4483,-257.24127 1093.8983,-257.6693 1094.5938,-258.03125 C 1095.316,-258.40725 1096.3555,-258.90183 1096.9688,-259.5625 C 1098.9317,-259.57454 1100.7625,-259.85355 1102.1875,-260.40625 C 1105.1387,-261.55085 1107.0607,-262.27567 1108.875,-263.15625 C 1110.3307,-263.86277 1111.1941,-264.85828 1111.4062,-265.15625 C 1111.6185,-265.4542 1111.5051,-265.8848 1111.5312,-265.90625 C 1111.5742,-265.94148 1111.8716,-266.00028 1112.0312,-266.34375 C 1112.8902,-268.19082 1114.3544,-271.97139 1114.4688,-272.65625 C 1114.5825,-273.33839 1114.6368,-274.00902 1114.6875,-274.40625 C 1114.7169,-274.63575 1114.5404,-275.28515 1114.5625,-275.34375 C 1114.5934,-275.42579 1114.8508,-275.59432 1114.9062,-275.84375 C 1115.1725,-277.04206 1114.9953,-278.05111 1114.7812,-279.46875 C 1114.5673,-280.88638 1113.8096,-284.08338 1113.1562,-284.9375 C 1112.4973,-285.79922 1111.9314,-285.94801 1111.4062,-285.9375 z" | ||
1575 | transform="translate(8.0045714e-2,-3.125e-2)" /> | ||
1576 | </clipPath> | ||
1577 | <filter | ||
1578 | inkscape:collect="always" | ||
1579 | id="filter7578" | ||
1580 | x="-0.08160872" | ||
1581 | width="1.1632174" | ||
1582 | y="-0.22659944" | ||
1583 | height="1.4531989"> | ||
1584 | <feGaussianBlur | ||
1585 | inkscape:collect="always" | ||
1586 | stdDeviation="2.437399" | ||
1587 | id="feGaussianBlur7580" /> | ||
1588 | </filter> | ||
1589 | <filter | ||
1590 | inkscape:collect="always" | ||
1591 | id="filter7594" | ||
1592 | x="-0.040804356" | ||
1593 | width="1.0816087" | ||
1594 | y="-0.11329972" | ||
1595 | height="1.2265995"> | ||
1596 | <feGaussianBlur | ||
1597 | inkscape:collect="always" | ||
1598 | stdDeviation="1.2186995" | ||
1599 | id="feGaussianBlur7596" /> | ||
1600 | </filter> | ||
1601 | <clipPath | ||
1602 | clipPathUnits="userSpaceOnUse" | ||
1603 | id="clipPath7606"> | ||
1604 | <path | ||
1605 | id="path7608" | ||
1606 | d="M 1049.205,-282.26672 L 1049.1152,-282.25891 C 1047.7278,-281.37446 1042.5119,-280.65171 1042.4862,-272.73547 C 1042.462,-265.31022 1057.4991,-255.64401 1059.6425,-254.64172 C 1061.3727,-253.83263 1063.2341,-253.23296 1065.0488,-252.92297 L 1066.4862,-252.70422 C 1068.4059,-252.49228 1070.2062,-252.55281 1071.6425,-252.79797 C 1074.7616,-253.33037 1076.7541,-253.72658 1078.7362,-254.11047 C 1080.7183,-254.49434 1081.2105,-255.15012 1082.2988,-255.39172 C 1083.4275,-255.64238 1084.569,-255.27543 1088.5488,-256.26672 C 1092.5283,-257.258 1093.9782,-257.68602 1094.6738,-258.04797 C 1095.396,-258.42398 1096.4355,-258.91855 1097.0488,-259.57922 C 1099.0117,-259.59127 1100.8425,-259.87027 1102.2675,-260.42297 C 1105.2187,-261.56758 1107.1407,-262.29239 1108.955,-263.17297 C 1110.4107,-263.8795 1111.2741,-264.875 1111.4862,-265.17297 C 1111.6985,-265.47093 1111.5852,-265.90152 1111.6112,-265.92297 C 1111.6542,-265.95821 1111.9517,-266.017 1112.1112,-266.36047 C 1112.9702,-268.20755 1114.4344,-271.98811 1114.5488,-272.67297 C 1114.6625,-273.35512 1114.7168,-274.02574 1114.7675,-274.42297 C 1114.7969,-274.65248 1114.6204,-275.30187 1114.6425,-275.36047 C 1114.6734,-275.44252 1114.9308,-275.61104 1114.9862,-275.86047 C 1115.2525,-277.05879 1115.0754,-278.06783 1114.8612,-279.48547 C 1114.6473,-280.90311 1113.8896,-284.1001 1113.2362,-284.95422 C 1112.8168,-285.50279 1112.4369,-285.74672 1112.08,-285.86047 C 1112.0129,-285.87776 1111.9561,-285.90721 1111.8925,-285.92297 C 1111.8715,-285.92695 1111.8508,-285.91983 1111.83,-285.92297 C 1111.5184,-285.99847 1111.2215,-286.08164 1110.6738,-286.14172 C 1109.6883,-286.24984 1108.2491,-286.40112 1106.705,-286.39172 C 1106.1903,-286.38859 1105.6679,-286.34408 1105.1425,-286.29797 C 1101.5836,-285.98569 1096.1327,-285.30689 1094.9238,-284.67297 C 1093.2907,-285.00699 1090.9756,-285.2852 1088.9862,-285.14172 C 1085.9222,-284.92075 1084.0185,-284.79953 1082.08,-284.67297 C 1080.1416,-284.54642 1080.3939,-284.28433 1079.1738,-284.20422 C 1077.8547,-284.11762 1077.3869,-284.42747 1073.6112,-284.11047 C 1070.0655,-283.81275 1064.6306,-283.1173 1063.3925,-282.48547 C 1061.7591,-282.81998 1059.4466,-283.09786 1057.455,-282.95422 C 1054.3908,-282.73324 1052.4872,-282.58078 1050.5488,-282.45422 C 1049.8896,-282.41119 1049.5064,-282.33029 1049.205,-282.26672 z" | ||
1607 | style="opacity:0.82448976;fill:#bcb786;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
1608 | </clipPath> | ||
1609 | <filter | ||
1610 | inkscape:collect="always" | ||
1611 | id="filter7610" | ||
1612 | x="-0.021942979" | ||
1613 | width="1.0438859" | ||
1614 | y="-0.10017137" | ||
1615 | height="1.2003427"> | ||
1616 | <feGaussianBlur | ||
1617 | inkscape:collect="always" | ||
1618 | stdDeviation="0.57530213" | ||
1619 | id="feGaussianBlur7612" /> | ||
1620 | </filter> | ||
1621 | <clipPath | ||
1622 | clipPathUnits="userSpaceOnUse" | ||
1623 | id="clipPath7616"> | ||
1624 | <path | ||
1625 | id="path7618" | ||
1626 | d="M 205.47016,-408.97318 L 205.38003,-408.97164 C 203.9344,-408.18598 198.68082,-407.82829 198.10378,-399.93307 C 197.56244,-392.52754 211.88973,-381.83741 213.95811,-380.68826 C 215.62775,-379.76062 217.44286,-379.03275 219.23156,-378.59711 L 220.65023,-378.27877 C 222.5505,-377.93363 224.35065,-377.86862 225.80054,-378.01314 C 228.94914,-378.32698 230.9644,-378.58345 232.96843,-378.82834 C 234.97245,-379.07322 235.50913,-379.69312 236.61162,-379.85833 C 237.75504,-380.02976 238.86821,-379.58419 242.90739,-380.29586 C 246.94627,-381.00755 248.42246,-381.33354 249.14158,-381.64616 C 249.88822,-381.97095 250.95964,-382.39191 251.61747,-383.00826 C 253.57644,-382.88355 255.42223,-383.03435 256.88227,-383.48645 C 259.90603,-384.42272 261.87384,-385.01189 263.74507,-385.76396 C 265.24645,-386.36738 266.17709,-387.30032 266.40943,-387.58279 C 266.64197,-387.86524 266.55894,-388.30268 266.58637,-388.32227 C 266.63172,-388.35443 266.93259,-388.39235 267.11563,-388.72388 C 268.1012,-390.50664 269.82518,-394.17603 269.987,-394.85126 C 270.14794,-395.52383 270.24882,-396.18904 270.32707,-396.58177 C 270.37238,-396.80868 270.24154,-397.46878 270.26767,-397.5257 C 270.30421,-397.6054 270.57272,-397.75558 270.64536,-398.00055 C 270.99449,-399.17741 270.8881,-400.19633 270.77316,-401.62545 C 270.65853,-403.05454 270.12535,-406.29655 269.53303,-407.1941 C 269.15286,-407.77056 268.79088,-408.04035 268.44277,-408.17869 C 268.37703,-408.20061 268.32242,-408.23394 268.26007,-408.2541 C 268.2394,-408.25953 268.21826,-408.25387 268.19773,-408.25845 C 267.89214,-408.35547 267.60176,-408.45912 267.05957,-408.5572 C 266.084,-408.7337 264.65883,-408.98486 263.11782,-409.08304 C 262.60416,-409.11577 262.07992,-409.10775 261.55259,-409.09835 C 257.98058,-409.03472 252.49564,-408.73725 251.24552,-408.18907 C 249.63965,-408.63604 247.34955,-409.07483 245.35499,-409.07027 C 242.28304,-409.06325 240.37552,-409.07493 238.43292,-409.0837 C 236.49041,-409.09248 236.72384,-408.81345 235.50112,-408.81852 C 234.1792,-408.82401 233.73411,-409.16569 229.9455,-409.11245 C 226.38768,-409.06243 220.91754,-408.74723 219.63844,-408.20318 C 218.0323,-408.65065 215.74477,-409.08893 213.74801,-409.08436 C 210.67586,-409.07735 208.76626,-409.05786 206.82375,-409.06662 C 206.16316,-409.06961 205.77525,-409.0156 205.47016,-408.97318 z" | ||
1627 | style="opacity:0.82448976;fill:#bcb786;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
1628 | </clipPath> | ||
1629 | <linearGradient | ||
1630 | inkscape:collect="always" | ||
1631 | xlink:href="#linearGradient7622" | ||
1632 | id="linearGradient7708" | ||
1633 | gradientUnits="userSpaceOnUse" | ||
1634 | gradientTransform="translate(-19.091883,4.2426407)" | ||
1635 | x1="774.97668" | ||
1636 | y1="-211.87105" | ||
1637 | x2="755.11584" | ||
1638 | y2="-202.67865" /> | ||
1639 | <mask | ||
1640 | maskUnits="userSpaceOnUse" | ||
1641 | id="mask7704"> | ||
1642 | <path | ||
1643 | style="fill:url(#linearGradient7708);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" | ||
1644 | d="M 718.40812,-224.31217 L 751.65812,-168.31217 L 1027.6581,-192.31217 L 1187.1581,-240.56217 L 1120.6581,-323.31217 L 718.40812,-224.31217 z" | ||
1645 | id="path7706" /> | ||
1646 | </mask> | ||
1647 | <radialGradient | ||
1648 | inkscape:collect="always" | ||
1649 | xlink:href="#linearGradient8430" | ||
1650 | id="radialGradient7904" | ||
1651 | gradientUnits="userSpaceOnUse" | ||
1652 | gradientTransform="matrix(-0.3324832,0.9022288,-0.9582407,-0.3531242,305.29227,19.909497)" | ||
1653 | cx="142.95833" | ||
1654 | cy="107.09234" | ||
1655 | fx="142.95833" | ||
1656 | fy="107.09234" | ||
1657 | r="66.981766" /> | ||
1658 | <radialGradient | ||
1659 | inkscape:collect="always" | ||
1660 | xlink:href="#linearGradient3317" | ||
1661 | id="radialGradient7906" | ||
1662 | gradientUnits="userSpaceOnUse" | ||
1663 | gradientTransform="matrix(1.0036478,-1.0345492e-7,1.7124628e-7,1.6613125,-160.53487,-96.205369)" | ||
1664 | cx="317.78754" | ||
1665 | cy="129.65378" | ||
1666 | fx="317.78754" | ||
1667 | fy="129.65378" | ||
1668 | r="47.863216" /> | ||
1669 | <radialGradient | ||
1670 | inkscape:collect="always" | ||
1671 | xlink:href="#linearGradient8398" | ||
1672 | id="radialGradient7908" | ||
1673 | gradientUnits="userSpaceOnUse" | ||
1674 | gradientTransform="matrix(2.0747661,-0.1577957,0.2382425,3.1325183,-550.77432,-65.728909)" | ||
1675 | cx="325.30847" | ||
1676 | cy="80.909554" | ||
1677 | fx="325.30847" | ||
1678 | fy="80.909554" | ||
1679 | r="26.937988" /> | ||
1680 | <clipPath | ||
1681 | clipPathUnits="userSpaceOnUse" | ||
1682 | id="clipPath8209"> | ||
1683 | <path | ||
1684 | sodipodi:nodetypes="czcc" | ||
1685 | id="path8211" | ||
1686 | d="M 734.03125,519.49186 C 734.03125,519.49186 750.78638,556.50992 762.73266,573.44581 C 774.67895,590.3817 815.45982,629.49186 815.45982,629.49186 L 816.05699,490.90211" | ||
1687 | style="opacity:1;fill:#1a1a1a;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
1688 | </clipPath> | ||
1689 | <filter | ||
1690 | inkscape:collect="always" | ||
1691 | id="filter8225"> | ||
1692 | <feGaussianBlur | ||
1693 | inkscape:collect="always" | ||
1694 | stdDeviation="10.661912" | ||
1695 | id="feGaussianBlur8227" /> | ||
1696 | </filter> | ||
1697 | <filter | ||
1698 | inkscape:collect="always" | ||
1699 | id="filter8333"> | ||
1700 | <feGaussianBlur | ||
1701 | inkscape:collect="always" | ||
1702 | stdDeviation="7.18" | ||
1703 | id="feGaussianBlur8335" /> | ||
1704 | </filter> | ||
1705 | <clipPath | ||
1706 | clipPathUnits="userSpaceOnUse" | ||
1707 | id="clipPath8338"> | ||
1708 | <path | ||
1709 | sodipodi:nodetypes="czzzzzzcccccccccczczz" | ||
1710 | id="path8340" | ||
1711 | d="M 266.27183,924.57185 C 264.86456,943.37307 265.12693,957.32289 268.35357,973.87513 C 271.58023,990.42751 284.75966,1019.7825 288.68798,1037.0589 C 292.61419,1054.326 291.38211,1075.3686 276.22854,1088.2071 C 260.91093,1101.1846 234.17727,1109.8061 208.39624,1103.9409 C 182.61518,1098.0756 138.84716,1054.7175 119.80605,1033.7126 C 100.6939,1012.6293 56.045182,939.86193 41.867507,909.4368 C 27.689835,879.01168 29.207902,872.71823 33.747792,863.90708 C 24.38107,839.38658 21.33408,813.84026 0.035334479,788.33044 C 30.360814,791.44487 43.915624,815.28676 60.161024,835.47019 C 54.631128,787.39416 42.106309,771.05368 31.787072,744.74589 C 61.781367,750.82754 82.366432,776.61828 95.766855,817.45839 C 105.32101,813.54047 114.00462,808.08545 125.95427,808.39719 C 114.65677,766.70139 108.0048,738.48134 89.267014,707.32725 C 142.70898,712.99757 172.92404,787.96657 168.23844,795.28805 C 178.21641,793.04406 187.24409,788.75767 198.67497,789.63638 C 187.426,751.28935 177.62715,712.76848 195.01526,670.98819 C 195.01526,670.98819 243.30204,736.42507 249.40491,756.79397 C 255.50779,777.16287 250.92373,795.49448 250.92373,795.49448 C 250.92373,795.49448 267.8833,826.57978 271.21765,846.58862 C 274.59075,866.82996 267.68496,905.69193 266.27183,924.57185 z" | ||
1712 | style="opacity:1;fill:#ada469;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
1713 | </clipPath> | ||
1714 | <filter | ||
1715 | inkscape:collect="always" | ||
1716 | id="filter8354"> | ||
1717 | <feGaussianBlur | ||
1718 | inkscape:collect="always" | ||
1719 | stdDeviation="6.82" | ||
1720 | id="feGaussianBlur8356" /> | ||
1721 | </filter> | ||
1722 | <clipPath | ||
1723 | clipPathUnits="userSpaceOnUse" | ||
1724 | id="clipPath8359"> | ||
1725 | <path | ||
1726 | sodipodi:nodetypes="czzzzzzcccccccccczczz" | ||
1727 | id="path8361" | ||
1728 | d="M 266.27183,924.57185 C 264.86456,943.37307 265.12693,957.32289 268.35357,973.87513 C 271.58023,990.42751 284.75966,1019.7825 288.68798,1037.0589 C 292.61419,1054.326 291.38211,1075.3686 276.22854,1088.2071 C 260.91093,1101.1846 234.17727,1109.8061 208.39624,1103.9409 C 182.61518,1098.0756 138.84716,1054.7175 119.80605,1033.7126 C 100.6939,1012.6293 56.045182,939.86193 41.867507,909.4368 C 27.689835,879.01168 29.207902,872.71823 33.747792,863.90708 C 24.38107,839.38658 21.33408,813.84026 0.035334479,788.33044 C 30.360814,791.44487 43.915624,815.28676 60.161024,835.47019 C 54.631128,787.39416 42.106309,771.05368 31.787072,744.74589 C 61.781367,750.82754 82.366432,776.61828 95.766855,817.45839 C 105.32101,813.54047 114.00462,808.08545 125.95427,808.39719 C 114.65677,766.70139 108.0048,738.48134 89.267014,707.32725 C 142.70898,712.99757 172.92404,787.96657 168.23844,795.28805 C 178.21641,793.04406 187.24409,788.75767 198.67497,789.63638 C 187.426,751.28935 177.62715,712.76848 195.01526,670.98819 C 195.01526,670.98819 243.30204,736.42507 249.40491,756.79397 C 255.50779,777.16287 250.92373,795.49448 250.92373,795.49448 C 250.92373,795.49448 267.8833,826.57978 271.21765,846.58862 C 274.59075,866.82996 267.68496,905.69193 266.27183,924.57185 z" | ||
1729 | style="opacity:1;fill:#ada469;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
1730 | </clipPath> | ||
1731 | <filter | ||
1732 | inkscape:collect="always" | ||
1733 | id="filter8379" | ||
1734 | x="-0.14413793" | ||
1735 | width="1.288276" | ||
1736 | y="-0.10278689" | ||
1737 | height="1.2055738"> | ||
1738 | <feGaussianBlur | ||
1739 | inkscape:collect="always" | ||
1740 | stdDeviation="7.389266" | ||
1741 | id="feGaussianBlur8381" /> | ||
1742 | </filter> | ||
1743 | <clipPath | ||
1744 | clipPathUnits="userSpaceOnUse" | ||
1745 | id="clipPath8392"> | ||
1746 | <path | ||
1747 | sodipodi:nodetypes="czzzzzzcccccccccczczz" | ||
1748 | id="path8394" | ||
1749 | d="M 760.16396,935.83377 C 766.95806,954.73656 770.65765,969.13346 772.05426,987.04566 C 773.45088,1004.958 768.27158,1038.8465 769.1538,1057.7018 C 770.03555,1076.547 777.28749,1097.8008 796.49843,1106.6707 C 815.9173,1115.6365 845.81767,1116.882 870.61827,1103.5251 C 895.41887,1090.1681 928.01929,1033.1996 941.59253,1006.2164 C 955.21638,979.13246 980.3536,891.71903 986.25333,856.44781 C 992.15306,821.1766 988.80387,815.14704 981.63585,807.39232 C 984.27615,779.55217 980.13613,752.45689 994.74554,720.20614 C 964.49653,732.03184 957.36325,760.36684 946.42665,785.71122 C 938.42574,734.77829 946.63581,714.43803 949.74554,684.49186 C 920.68078,699.26977 906.88403,731.60588 904.74554,777.349 C 893.82159,776.0448 883.3541,772.91477 871.17411,776.63471 C 870.91007,730.61137 869.71055,699.7453 880.08474,662.42822 C 826.82927,683.45508 817.13746,769.02232 824.03125,775.20614 C 813.14843,775.74114 802.66017,773.90884 791.17411,778.06329 C 791.81303,735.49194 790.91365,693.15468 761.17411,655.20614 C 761.17411,655.20614 730.21605,736.12848 729.74554,758.77757 C 729.27503,781.42666 739.19713,798.94345 739.19713,798.94345 C 739.19713,798.94345 730.62906,835.68396 732.89854,857.17568 C 735.19439,878.91714 753.34144,916.85185 760.16396,935.83377 z" | ||
1750 | style="opacity:1;fill:#ada469;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
1751 | </clipPath> | ||
1752 | <filter | ||
1753 | inkscape:collect="always" | ||
1754 | id="filter8404" | ||
1755 | x="-0.090268657" | ||
1756 | width="1.1805373" | ||
1757 | y="-0.10250848" | ||
1758 | height="1.205017"> | ||
1759 | <feGaussianBlur | ||
1760 | inkscape:collect="always" | ||
1761 | stdDeviation="5.3457272" | ||
1762 | id="feGaussianBlur8406" /> | ||
1763 | </filter> | ||
1764 | <clipPath | ||
1765 | clipPathUnits="userSpaceOnUse" | ||
1766 | id="clipPath8417"> | ||
1767 | <path | ||
1768 | sodipodi:nodetypes="czzzzzzcccccccccczczz" | ||
1769 | id="path8419" | ||
1770 | d="M 760.16396,935.83377 C 766.95806,954.73656 770.65765,969.13346 772.05426,987.04566 C 773.45088,1004.958 768.27158,1038.8465 769.1538,1057.7018 C 770.03555,1076.547 777.28749,1097.8008 796.49843,1106.6707 C 815.9173,1115.6365 845.81767,1116.882 870.61827,1103.5251 C 895.41887,1090.1681 928.01929,1033.1996 941.59253,1006.2164 C 955.21638,979.13246 980.3536,891.71903 986.25333,856.44781 C 992.15306,821.1766 988.80387,815.14704 981.63585,807.39232 C 984.27615,779.55217 980.13613,752.45689 994.74554,720.20614 C 964.49653,732.03184 957.36325,760.36684 946.42665,785.71122 C 938.42574,734.77829 946.63581,714.43803 949.74554,684.49186 C 920.68078,699.26977 906.88403,731.60588 904.74554,777.349 C 893.82159,776.0448 883.3541,772.91477 871.17411,776.63471 C 870.91007,730.61137 869.71055,699.7453 880.08474,662.42822 C 826.82927,683.45508 817.13746,769.02232 824.03125,775.20614 C 813.14843,775.74114 802.66017,773.90884 791.17411,778.06329 C 791.81303,735.49194 790.91365,693.15468 761.17411,655.20614 C 761.17411,655.20614 730.21605,736.12848 729.74554,758.77757 C 729.27503,781.42666 739.19713,798.94345 739.19713,798.94345 C 739.19713,798.94345 730.62906,835.68396 732.89854,857.17568 C 735.19439,878.91714 753.34144,916.85185 760.16396,935.83377 z" | ||
1771 | style="opacity:1;fill:#ada469;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
1772 | </clipPath> | ||
1773 | </defs> | ||
1774 | <metadata | ||
1775 | id="metadata7"> | ||
1776 | <rdf:RDF> | ||
1777 | <cc:Work | ||
1778 | rdf:about=""> | ||
1779 | <dc:format>image/svg+xml</dc:format> | ||
1780 | <dc:type | ||
1781 | rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> | ||
1782 | </cc:Work> | ||
1783 | </rdf:RDF> | ||
1784 | </metadata> | ||
1785 | <g | ||
1786 | inkscape:groupmode="layer" | ||
1787 | id="layer1" | ||
1788 | inkscape:label="Shadow"> | ||
1789 | <path | ||
1790 | style="opacity:0.5;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter11361);enable-background:new" | ||
1791 | d="M 304.64285,526.6479 C 294.64285,527.00505 286.42857,529.50504 286.42857,529.50504 L 293.92857,535.57647 L 304.28571,539.1479 L 320.35714,539.50504 L 342.85714,534.1479 L 350.71428,535.21933 L 371.07143,533.07647 L 360.71428,539.86219 C 366.17351,538.83858 378.10757,543.4313 370.35714,545.21933 C 368.61714,545.62075 384.28571,540.57648 384.28571,540.57648 L 386.78571,535.93361 L 390.35714,526.6479 L 401.78571,526.6479 L 419.99999,522.00504 L 423.57143,517.00505 L 407.49999,518.07647 L 395.35714,520.21933 L 380.71428,515.21933 L 310.02218,531.92707 L 304.64285,526.6479 z" | ||
1792 | id="path10326" | ||
1793 | sodipodi:nodetypes="cccccccccsccccccccccc" | ||
1794 | transform="matrix(10.726753,0,0,10.726753,-2882.1235,-4565.4583)" | ||
1795 | inkscape:export-filename="/home/cheeseness/Documents/LCA09/mascot/tuz_new.png" | ||
1796 | inkscape:export-xdpi="142.10527" | ||
1797 | inkscape:export-ydpi="142.10527" /> | ||
1798 | </g> | ||
1799 | <g | ||
1800 | inkscape:groupmode="layer" | ||
1801 | id="layer20" | ||
1802 | inkscape:label="New Ear"> | ||
1803 | <g | ||
1804 | style="opacity:1;display:inline;enable-background:new" | ||
1805 | id="g7882" | ||
1806 | transform="matrix(0.71084,-0.1937433,0.262963,0.9648058,503.68027,136.48399)"> | ||
1807 | <path | ||
1808 | sodipodi:nodetypes="czzzzcc" | ||
1809 | id="path7876" | ||
1810 | d="M 245.12255,100.05344 C 245.12255,100.05344 197.99444,68.406519 177.9079,64.252501 C 157.86998,60.108538 139.435,60.934923 125.97426,77.859824 C 112.51352,94.784725 113.89687,139.12502 112.43872,164.82937 C 110.98057,190.53372 114.98817,235.00638 130.04332,253.49489 C 145.09848,271.98339 175.92966,267.07991 179.97027,274.90859 C 182.1831,279.19595 245.12255,100.05344 245.12255,100.05344 z" | ||
1811 | style="opacity:1;fill:url(#radialGradient7904);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
1812 | <path | ||
1813 | sodipodi:nodetypes="czzzzzc" | ||
1814 | id="path7878" | ||
1815 | d="M 135.37935,82.017807 C 135.37935,82.017807 161.7229,83.95659 173.01242,95.920995 C 184.42736,108.01833 186.74699,117.25251 188.30828,133.65558 C 189.87165,150.08057 187.45871,162.0737 180.49446,169.69292 C 173.53021,177.31214 179.49017,189.27624 154.57841,181.76399 C 129.66665,174.25174 127.54617,153.98101 128.06318,135.45924 C 128.58039,116.93026 135.37935,82.017807 135.37935,82.017807 z" | ||
1816 | style="opacity:1;fill:url(#radialGradient7906);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
1817 | <path | ||
1818 | sodipodi:nodetypes="czccssc" | ||
1819 | id="path7880" | ||
1820 | d="M 135.648,81.927211 C 135.648,81.927211 131.00335,98.292286 136.23625,110.49031 C 141.72419,123.28285 163.4605,154.75038 163.4605,165.14596 L 186.11675,160.14596 C 188.65893,153.17952 189.32727,144.3939 188.30425,133.64596 C 186.74296,117.24289 184.43795,108.02455 173.023,95.927211 C 163.36812,85.695164 141.42989,82.552354 135.648,81.927211 z" | ||
1821 | style="opacity:1;fill:url(#radialGradient7908);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
1822 | </g> | ||
1823 | </g> | ||
1824 | <g | ||
1825 | inkscape:groupmode="layer" | ||
1826 | id="layer21" | ||
1827 | inkscape:label="Rendered2" | ||
1828 | style="display:inline"> | ||
1829 | <path | ||
1830 | style="opacity:1;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
1831 | d="M 845.03125,1154.7776 C 840.74554,1155.4919 817.4031,1158.3957 787.17411,1164.7776 C 756.94512,1171.1595 729.86016,1169.7437 651.38803,1182.1072 C 571.53625,1194.688 557.32367,1224.6495 543.26578,1229.1715 C 528.56564,1233.9001 397.88839,1163.349 397.88839,1163.349 L 402.17411,1069.0633 C 402.17411,1069.0633 488.05962,1052.8624 514.31696,1035.4919 C 540.57431,1018.1214 559.89934,985.82588 573.60268,964.06329 C 587.30602,942.3007 606.45982,892.63471 606.45982,892.63471 L 845.03125,1154.7776 z" | ||
1832 | id="path7917" | ||
1833 | sodipodi:nodetypes="czzzcczzcc" /> | ||
1834 | <path | ||
1835 | style="opacity:0.5;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8888);enable-background:accumulate" | ||
1836 | d="M 332.34019,898.38549 L 299.60838,837.08593 L 261.99104,882.19239 C 264.16779,883.5095 267.76529,861.33636 307.59144,817.77531 L 332.34019,898.38549 z" | ||
1837 | id="path7919" | ||
1838 | clip-path="url(#clipPath8658)" | ||
1839 | sodipodi:nodetypes="ccccc" | ||
1840 | transform="translate(276,136)" /> | ||
1841 | <path | ||
1842 | style="opacity:1;fill:url(#linearGradient2841);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8892);enable-background:accumulate" | ||
1843 | d="M 200.81833,863.03015 L 347.18943,811.41136 L 591.14127,1037.6855 L 349.31075,1177.6927 L 168.29141,1090.0114 L 200.81833,863.03015 z" | ||
1844 | id="path7923" | ||
1845 | clip-path="url(#clipPath2833)" | ||
1846 | sodipodi:nodetypes="cccccc" | ||
1847 | transform="translate(276,136)" /> | ||
1848 | <path | ||
1849 | style="opacity:1;fill:#0f0f0f;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
1850 | d="M 642.88839,640.13471 C 642.88839,640.13471 613.33433,680.70776 595.03125,714.42042 C 576.72816,748.13309 536.41016,840.77736 524.67411,885.49185 C 512.91471,930.29529 462.17411,1009.0633 462.17411,1009.0633 L 538.24554,1027.2776 C 538.24554,1027.2776 550.05266,1014.4542 569.31696,981.20614 C 588.58126,947.95806 629.67411,842.63471 629.67411,842.63471 L 642.88839,640.13471 z" | ||
1851 | id="path7921" | ||
1852 | sodipodi:nodetypes="czzcczcc" /> | ||
1853 | <path | ||
1854 | style="opacity:0.4;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8856);enable-background:accumulate" | ||
1855 | d="M 430.28131,381.94122 C 423.21025,384.76965 194.10007,414.09303 194.10007,414.09303 L 154.46046,773.92607 L 244.65895,866.56568 L 296.98485,752.01438 L 397.45289,565.62246 L 430.28131,381.94122 z" | ||
1856 | id="path7925" | ||
1857 | sodipodi:nodetypes="ccccccc" | ||
1858 | clip-path="url(#clipPath3665)" | ||
1859 | transform="translate(276,136)" /> | ||
1860 | <path | ||
1861 | style="opacity:1;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
1862 | d="M 969.67051,1164.0346 C 969.67051,1164.0346 992.92679,1175.4283 1005.7383,1184.5107 C 1018.4357,1193.5122 1035.2107,1209.1598 1047.4307,1221.8712 C 1059.7362,1234.6714 1067.5434,1244.4699 1088.9634,1246.032 C 1110.3956,1247.5949 1142.2458,1237.2444 1162.2594,1221.3678 C 1182.2729,1205.4912 1207.9063,1152.135 1207.9063,1152.135 L 1080.7455,1009.0633" | ||
1863 | id="path7927" | ||
1864 | sodipodi:nodetypes="czzzzcc" /> | ||
1865 | <path | ||
1866 | style="opacity:0.75;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8860);enable-background:accumulate" | ||
1867 | d="M 331.34019,641.50471 L 216.17367,835.36467 L 260.2153,925.96265 L 357.79603,732.21539 L 331.34019,641.50471 z" | ||
1868 | id="path7929" | ||
1869 | clip-path="url(#clipPath8642)" | ||
1870 | sodipodi:nodetypes="ccccc" | ||
1871 | transform="translate(276,136)" /> | ||
1872 | <g | ||
1873 | style="opacity:1;display:inline;enable-background:new" | ||
1874 | id="g7931" | ||
1875 | transform="matrix(0.9934486,0.1142802,-0.1142802,0.9934486,-9.24324,588.09054)" | ||
1876 | inkscape:transform-center-x="-347.89063" | ||
1877 | inkscape:transform-center-y="-28.255779"> | ||
1878 | <path | ||
1879 | style="opacity:1;fill:#bcb786;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
1880 | d="M 1049.205,-282.26672 L 1049.1152,-282.25891 C 1047.7278,-281.37446 1042.5119,-280.65171 1042.4862,-272.73547 C 1042.462,-265.31022 1057.4991,-255.64401 1059.6425,-254.64172 C 1061.3727,-253.83263 1063.2341,-253.23296 1065.0488,-252.92297 L 1066.4862,-252.70422 C 1068.4059,-252.49228 1070.2062,-252.55281 1071.6425,-252.79797 C 1074.7616,-253.33037 1076.7541,-253.72658 1078.7362,-254.11047 C 1080.7183,-254.49434 1081.2105,-255.15012 1082.2988,-255.39172 C 1083.4275,-255.64238 1084.569,-255.27543 1088.5488,-256.26672 C 1092.5283,-257.258 1093.9782,-257.68602 1094.6738,-258.04797 C 1095.396,-258.42398 1096.4355,-258.91855 1097.0488,-259.57922 C 1099.0117,-259.59127 1100.8425,-259.87027 1102.2675,-260.42297 C 1105.2187,-261.56758 1107.1407,-262.29239 1108.955,-263.17297 C 1110.4107,-263.8795 1111.2741,-264.875 1111.4862,-265.17297 C 1111.6985,-265.47093 1111.5852,-265.90152 1111.6112,-265.92297 C 1111.6542,-265.95821 1111.9517,-266.017 1112.1112,-266.36047 C 1112.9702,-268.20755 1114.4344,-271.98811 1114.5488,-272.67297 C 1114.6625,-273.35512 1114.7168,-274.02574 1114.7675,-274.42297 C 1114.7969,-274.65248 1114.6204,-275.30187 1114.6425,-275.36047 C 1114.6734,-275.44252 1114.9308,-275.61104 1114.9862,-275.86047 C 1115.2525,-277.05879 1115.0754,-278.06783 1114.8612,-279.48547 C 1114.6473,-280.90311 1113.8896,-284.1001 1113.2362,-284.95422 C 1112.8168,-285.50279 1112.4369,-285.74672 1112.08,-285.86047 C 1112.0129,-285.87776 1111.9561,-285.90721 1111.8925,-285.92297 C 1111.8715,-285.92695 1111.8508,-285.91983 1111.83,-285.92297 C 1111.5184,-285.99847 1111.2215,-286.08164 1110.6738,-286.14172 C 1109.6883,-286.24984 1108.2491,-286.40112 1106.705,-286.39172 C 1106.1903,-286.38859 1105.6679,-286.34408 1105.1425,-286.29797 C 1101.5836,-285.98569 1096.1327,-285.30689 1094.9238,-284.67297 C 1093.2907,-285.00699 1090.9756,-285.2852 1088.9862,-285.14172 C 1085.9222,-284.92075 1084.0185,-284.79953 1082.08,-284.67297 C 1080.1416,-284.54642 1080.3939,-284.28433 1079.1738,-284.20422 C 1077.8547,-284.11762 1077.3869,-284.42747 1073.6112,-284.11047 C 1070.0655,-283.81275 1064.6306,-283.1173 1063.3925,-282.48547 C 1061.7591,-282.81998 1059.4466,-283.09786 1057.455,-282.95422 C 1054.3908,-282.73324 1052.4872,-282.58078 1050.5488,-282.45422 C 1049.8896,-282.41119 1049.5064,-282.33029 1049.205,-282.26672 z" | ||
1881 | id="path7933" /> | ||
1882 | <g | ||
1883 | clip-path="url(#clipPath7616)" | ||
1884 | style="display:inline;filter:url(#filter7610);enable-background:new" | ||
1885 | id="g7935" | ||
1886 | transform="matrix(0.9975712,-6.9654277e-2,6.9654277e-2,0.9975712,872.72062,140.02502)"> | ||
1887 | <path | ||
1888 | sodipodi:nodetypes="ccssscsssscscsscsssccscssccsscssscc" | ||
1889 | id="path7937" | ||
1890 | d="M 229.94262,-409.12268 C 226.38481,-409.07267 220.91842,-408.76259 219.63928,-408.21854 C 218.03319,-408.66601 215.73612,-409.09985 213.73933,-409.09528 C 210.66734,-409.08826 208.77464,-409.08651 206.83206,-409.09528 C 206.17159,-409.09827 205.78447,-409.02811 205.47939,-408.98569 C 205.47939,-408.98569 205.47939,-407.88976 205.47939,-407.88976 C 205.59911,-408.06923 205.87191,-408.58022 206.42914,-408.65691 C 207.17672,-408.7598 211.59842,-408.80814 213.73933,-408.76651 C 215.51393,-408.73198 218.19456,-408.49224 220.12854,-407.80756 C 220.44994,-407.69378 220.74779,-407.53378 221.02073,-407.39659 C 222.98415,-406.40966 228.96409,-403.09505 228.96409,-403.09505 C 228.96409,-403.09505 222.33134,-407.04273 221.48122,-407.53358 C 221.27791,-407.65097 220.90658,-407.79127 220.44513,-407.94456 C 221.66576,-408.39235 225.5211,-408.56427 228.27336,-408.65691 C 231.29786,-408.75873 231.62112,-408.7465 233.68405,-408.46512 C 235.81336,-408.17469 237.02256,-407.86236 237.02256,-407.86236 C 237.02255,-407.86236 236.9442,-408.50354 238.05865,-408.65691 C 238.80622,-408.7598 243.22794,-408.80814 245.36884,-408.76651 C 247.43834,-408.72625 250.73489,-408.35935 252.65024,-407.39659 C 253.65356,-406.89226 255.68588,-405.82796 257.44559,-404.86088 L 257.5412,-404.88031 C 257.5412,-404.88031 253.96086,-407.04273 253.11073,-407.53358 C 252.90742,-407.65097 252.5361,-407.79127 252.07464,-407.94456 C 253.29526,-408.39235 257.12183,-408.56427 259.87409,-408.65691 C 262.89859,-408.75873 263.22184,-408.7465 265.28478,-408.46512 C 267.23794,-408.19872 268.2977,-407.93506 268.47939,-407.88976 C 268.47939,-407.88976 268.4523,-408.20122 268.4523,-408.20122 C 268.04327,-408.33767 267.73806,-408.43457 267.05192,-408.5587 C 265.75111,-408.79403 263.6528,-409.16026 261.54335,-409.12268 C 257.9714,-409.05904 252.49007,-408.76672 251.24001,-408.21854 C 249.63418,-408.66549 247.36339,-409.09984 245.36884,-409.09528 C 242.29685,-409.08826 240.37536,-409.08651 238.43279,-409.09528 C 236.49023,-409.10406 236.72011,-408.81621 235.49721,-408.8213 C 234.1753,-408.8268 233.73109,-409.17593 229.94262,-409.12268 C 229.94262,-409.12268 229.94262,-409.12268 229.94262,-409.12268" | ||
1891 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
1892 | <path | ||
1893 | id="path7939" | ||
1894 | d="M 206.1989,-407.47878 C 208.11911,-406.66172 210.77605,-405.28595 212.35787,-404.08139 C 213.93971,-402.87683 215.26544,-402.30771 217.91246,-400.16344 C 218.79803,-399.44606 219.66111,-398.81359 220.50439,-398.2417 L 221.04496,-398.43181 C 220.33173,-398.9152 219.5772,-399.45212 218.77587,-400.05384 C 215.95364,-402.17305 215.14932,-402.86357 212.7608,-404.32798 C 210.37226,-405.79238 208.66132,-406.69374 206.1989,-407.47878 C 206.1989,-407.47878 206.1989,-407.47878 206.1989,-407.47878" | ||
1895 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
1896 | sodipodi:nodetypes="cssccsscc" /> | ||
1897 | <path | ||
1898 | id="path7941" | ||
1899 | d="M 237.79963,-407.47878 C 239.71984,-406.66172 242.40557,-405.28595 243.98738,-404.08139 C 244.80045,-403.46223 245.54587,-403.01097 246.43784,-402.42738 L 247.08684,-402.54404 C 246.28853,-403.12041 245.51507,-403.63839 244.39031,-404.32798 C 242.00177,-405.79238 240.26205,-406.69374 237.79963,-407.47878 C 237.79963,-407.47878 237.79963,-407.47878 237.79963,-407.47878" | ||
1900 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
1901 | sodipodi:nodetypes="csccscc" /> | ||
1902 | </g> | ||
1903 | <g | ||
1904 | clip-path="url(#clipPath7606)" | ||
1905 | id="g7943"> | ||
1906 | <path | ||
1907 | style="opacity:0.75;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7578);enable-background:new" | ||
1908 | d="M 1056.25,-278.80481 C 1060.3946,-280.28358 1066.25,-275.67981 1066.25,-275.67981 C 1067.149,-275.39889 1068.9751,-276.57428 1068.8743,-277.36595 C 1068.8743,-277.36595 1067.324,-279.22657 1068.5,-280.30481 C 1069.676,-281.38305 1073.796,-278.79743 1076,-278.67981 C 1078.204,-278.56219 1081.5621,-278.90922 1083,-279.42981 C 1084.4379,-279.9504 1084.1129,-280.8544 1085.625,-281.17981 C 1087.1371,-281.50522 1090.7439,-280.14227 1092.6855,-280.01098 C 1094.6271,-279.87969 1097.3336,-279.67671 1098.5,-280.17981 C 1099.6664,-280.68291 1098.6782,-281.33902 1100.375,-282.05481 C 1102.0718,-282.7706 1108.1352,-283.01143 1110,-282.17981 C 1111.8648,-281.34819 1111.8099,-281.66061 1112.625,-279.17981 C 1113.4401,-276.69901 1120.0648,-274.01696 1111.5,-265.80481 C 1102.9352,-257.59266 1052.1221,-252.01887 1045.875,-263.05481 C 1039.6279,-274.09075 1052.1054,-277.32604 1056.25,-278.80481 z" | ||
1909 | id="path7945" | ||
1910 | sodipodi:nodetypes="czzzzzzzzzzzzzz" /> | ||
1911 | <path | ||
1912 | style="opacity:0.75;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7594);enable-background:new" | ||
1913 | d="M 1058.5,-275.42981 C 1062.6446,-276.90858 1068.5,-272.30481 1068.5,-272.30481 C 1069.399,-272.02389 1071.2251,-273.19928 1071.1243,-273.99095 C 1071.1243,-273.99095 1069.574,-275.85157 1070.75,-276.92981 C 1071.926,-278.00805 1076.046,-275.42243 1078.25,-275.30481 C 1080.454,-275.18719 1083.8121,-275.53422 1085.25,-276.05481 C 1086.6879,-276.5754 1086.3629,-277.4794 1087.875,-277.80481 C 1089.3871,-278.13022 1092.9939,-276.76727 1094.9355,-276.63598 C 1096.8771,-276.50469 1099.5836,-276.30171 1100.75,-276.80481 C 1101.9164,-277.30791 1100.9282,-277.96402 1102.625,-278.67981 C 1104.3218,-279.3956 1110.3852,-279.63643 1112.25,-278.80481 C 1114.1148,-277.97319 1114.0599,-278.28561 1114.875,-275.80481 C 1115.6901,-273.32401 1122.3148,-270.64196 1113.75,-262.42981 C 1105.1852,-254.21766 1054.3721,-248.64387 1048.125,-259.67981 C 1041.8779,-270.71575 1054.3554,-273.95104 1058.5,-275.42981 z" | ||
1914 | id="path7947" | ||
1915 | sodipodi:nodetypes="czzzzzzzzzzzzzz" /> | ||
1916 | </g> | ||
1917 | </g> | ||
1918 | <path | ||
1919 | style="opacity:1;fill:#101414;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
1920 | d="M 628.24553,347.99185 C 624.4411,322.72762 611.43581,297.35383 611.08873,272.46662 C 610.90247,259.1111 614.36158,245.89571 624.84426,232.91257 C 661.19128,167.61674 741.78517,148.21789 810.77892,141.44715 C 897.70131,130.43035 995.69159,159.38722 1044.1503,236.84843 C 1098.2743,312.58173 1100.825,409.38755 1124.7623,496.37638 C 1154.2001,623.50398 1179.5414,752.59052 1185.1545,883.22673 C 1182.0911,961.40858 1176.7282,1048.4109 1124.6513,1111.3609 C 1076.6248,1161.7183 1001.8649,1161.4139 937.58145,1170.3632 C 847.02606,1175.0182 753.22992,1154.2174 675.79755,1106.165 C 611.02191,1068.225 580.06736,992.68633 578.51815,920.14538 C 570.12898,840.27022 604.90967,766.33687 630.13855,692.98577 C 637.60916,610.2247 639.55141,526.73802 639.79189,443.60093 C 638.95507,411.40549 632.70236,379.7836 628.24553,347.99185 z" | ||
1921 | id="path7949" | ||
1922 | sodipodi:nodetypes="cscccccccccccc" /> | ||
1923 | <path | ||
1924 | style="opacity:0.25;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8940);enable-background:accumulate" | ||
1925 | d="M 311.83409,415.43155 L 321.73359,537.05392 L 261.62951,673.52553 L 277.18586,848.1809 C 292.79912,910.0601 309.37131,946.84995 351.56201,965.23473 C 355.88112,928.99475 312.95049,822.27485 312.31937,776.11489 C 311.68792,729.93044 323.14971,667.50703 342.99704,617.81842 C 363.04539,567.62654 379.89378,572.972 385.12193,525.22549 C 390.35008,477.47898 367.69553,375.83357 367.69553,375.83357 L 311.83409,415.43155 z" | ||
1926 | id="path7951" | ||
1927 | sodipodi:nodetypes="ccccczzzcc" | ||
1928 | clip-path="url(#clipPath8616)" | ||
1929 | transform="translate(276,136)" /> | ||
1930 | <path | ||
1931 | style="opacity:1;fill:url(#linearGradient8970);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
1932 | d="M 1010.0312,655.49186 C 1010.0312,655.49186 1026.7864,692.50992 1038.7327,709.44581 C 1050.6789,726.3817 1091.4598,765.49186 1091.4598,765.49186 L 1144.057,637.90211" | ||
1933 | id="path7953" | ||
1934 | sodipodi:nodetypes="czcc" /> | ||
1935 | <path | ||
1936 | style="opacity:0.07999998;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8822);enable-background:accumulate" | ||
1937 | d="M 730.31998,536.56864 C 730.31998,545.05392 772.86772,595.03667 772.86772,595.03667 L 785.47431,566.26713 L 730.31998,536.56864 z" | ||
1938 | id="path7955" | ||
1939 | sodipodi:nodetypes="cccc" | ||
1940 | clip-path="url(#clipPath8209)" | ||
1941 | transform="translate(276,136)" /> | ||
1942 | <g | ||
1943 | transform="translate(450.03125,73.843964)" | ||
1944 | style="opacity:1;display:inline;enable-background:new" | ||
1945 | id="g7957" | ||
1946 | clip-path="url(#clipPath3998)"> | ||
1947 | <g | ||
1948 | transform="translate(-174.03125,62.156036)" | ||
1949 | style="filter:url(#filter3677)" | ||
1950 | id="g7959"> | ||
1951 | <g | ||
1952 | id="g7961" | ||
1953 | style="filter:url(#filter3785)"> | ||
1954 | <path | ||
1955 | sodipodi:nodetypes="czzzzzzzzzz" | ||
1956 | id="path7963" | ||
1957 | d="M 425.88244,476.99186 C 436.68787,475.5132 450.62645,480.34637 470.5253,480.20614 C 490.42415,480.06591 527.97852,463.29492 552.66815,463.06328 C 577.35778,462.83164 615.41985,475.34734 631.95387,478.06328 C 648.48789,480.77922 654.80219,477.90476 659.45386,485.92043 C 664.10553,493.9361 661.38057,496.66767 649.09672,506.63472 C 636.81287,516.60177 608.30704,519.27104 583.02529,519.49186 C 557.74295,519.71268 512.644,526.57038 487.66815,523.42042 C 462.6923,520.27046 430.73059,515.59775 418.73958,505.56328 C 406.74857,495.52881 398.88874,488.83146 401.23958,481.63471 C 403.59042,474.43796 415.07701,478.47052 425.88244,476.99186 z" | ||
1958 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
1959 | <rect | ||
1960 | y="412.60312" | ||
1961 | x="343.6539" | ||
1962 | height="181.01935" | ||
1963 | width="381.83765" | ||
1964 | id="rect7965" | ||
1965 | style="opacity:1;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
1966 | </g> | ||
1967 | <g | ||
1968 | id="g7967" | ||
1969 | style="filter:url(#filter3785)"> | ||
1970 | <path | ||
1971 | sodipodi:nodetypes="czzzcc" | ||
1972 | id="path7969" | ||
1973 | d="M 687.14286,452.36218 C 676.68117,462.07661 600.16326,471.36732 586.42857,481.6479 C 572.69388,491.92848 571.67605,494.53616 574.28571,501.6479 C 576.89537,508.75964 580.83098,511.05362 600,510.21932 C 619.16902,509.38502 698.57143,482.5976 698.57143,488.79075 L 687.14286,452.36218 z" | ||
1974 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
1975 | transform="translate(174.03125,-62.156036)" /> | ||
1976 | <rect | ||
1977 | y="344.82138" | ||
1978 | x="702.86414" | ||
1979 | height="162.63455" | ||
1980 | width="207.8894" | ||
1981 | id="rect7971" | ||
1982 | style="opacity:1;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
1983 | </g> | ||
1984 | </g> | ||
1985 | <g | ||
1986 | transform="translate(-174.03125,62.156036)" | ||
1987 | style="opacity:0.18000004;display:inline;enable-background:new" | ||
1988 | id="g7973"> | ||
1989 | <g | ||
1990 | id="g7975" | ||
1991 | style="filter:url(#filter3785)"> | ||
1992 | <path | ||
1993 | sodipodi:nodetypes="czzzzzzzzzz" | ||
1994 | id="path7977" | ||
1995 | d="M 425.88244,476.99186 C 436.68787,475.5132 450.62645,480.34637 470.5253,480.20614 C 490.42415,480.06591 527.97852,463.29492 552.66815,463.06328 C 577.35778,462.83164 615.41985,475.34734 631.95387,478.06328 C 648.48789,480.77922 654.80219,477.90476 659.45386,485.92043 C 664.10553,493.9361 661.38057,496.66767 649.09672,506.63472 C 636.81287,516.60177 608.30704,519.27104 583.02529,519.49186 C 557.74295,519.71268 512.644,526.57038 487.66815,523.42042 C 462.6923,520.27046 430.73059,515.59775 418.73958,505.56328 C 406.74857,495.52881 398.88874,488.83146 401.23958,481.63471 C 403.59042,474.43796 415.07701,478.47052 425.88244,476.99186 z" | ||
1996 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
1997 | <rect | ||
1998 | y="412.60312" | ||
1999 | x="343.6539" | ||
2000 | height="181.01935" | ||
2001 | width="381.83765" | ||
2002 | id="rect7979" | ||
2003 | style="opacity:1;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
2004 | </g> | ||
2005 | <g | ||
2006 | id="g7981" | ||
2007 | style="filter:url(#filter3785)"> | ||
2008 | <path | ||
2009 | sodipodi:nodetypes="czzzcc" | ||
2010 | id="path7983" | ||
2011 | d="M 687.14286,452.36218 C 676.68117,462.07661 600.16326,471.36732 586.42857,481.6479 C 572.69388,491.92848 571.67605,494.53616 574.28571,501.6479 C 576.89537,508.75964 580.83098,511.05362 600,510.21932 C 619.16902,509.38502 698.57143,482.5976 698.57143,488.79075 L 687.14286,452.36218 z" | ||
2012 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2013 | transform="translate(174.03125,-62.156036)" /> | ||
2014 | <rect | ||
2015 | y="344.82138" | ||
2016 | x="702.86414" | ||
2017 | height="162.63455" | ||
2018 | width="207.8894" | ||
2019 | id="rect7985" | ||
2020 | style="opacity:1;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
2021 | </g> | ||
2022 | </g> | ||
2023 | </g> | ||
2024 | <path | ||
2025 | style="opacity:0.75;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8802);enable-background:accumulate" | ||
2026 | d="M 582.65599,-7.4183011 L 695.79307,78.848726 L 804.68752,337.64981 L 842.87128,545.5392 L 963.07944,637.46308 C 963.07944,637.46308 950.35151,350.37773 943.28044,323.50767 C 936.20938,296.63761 793.37381,-69.643698 793.37381,-69.643698 L 582.65599,-7.4183011 z" | ||
2027 | id="path7987" | ||
2028 | clip-path="url(#clipPath8604)" | ||
2029 | sodipodi:nodetypes="cccccscc" | ||
2030 | transform="translate(276,136)" /> | ||
2031 | <path | ||
2032 | style="opacity:1;fill:url(#linearGradient8958);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2033 | d="M 964.13839,239.599 C 964.13839,239.599 972.81571,250.49562 988.24554,251.56328 C 1003.6754,252.63094 1037.9672,211.61061 1058.4241,199.42043 C 1078.9034,187.2169 1105.4705,172.81818 1122.3527,179.06329 C 1139.2348,185.30839 1144.5105,205.49938 1150.2098,227.099 C 1155.9092,248.69861 1156.9284,288.91289 1147.5313,319.95615 C 1138.1341,350.9994 1097.028,393.0599 1082.1741,423.349 C 1067.3202,453.6381 1070.567,463.17043 1070.567,463.17043" | ||
2034 | id="path7989" | ||
2035 | sodipodi:nodetypes="czzzzzzc" /> | ||
2036 | <path | ||
2037 | style="opacity:1;fill:url(#radialGradient3315);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2038 | d="M 1124.4955,207.63471 C 1108.6027,206.74185 1074.7767,219.74054 1058.4241,231.92043 C 1041.9855,244.16433 1029.2032,256.03483 1029.1384,284.06328 C 1029.0732,312.26932 1042.2575,323.13969 1058.2455,331.02757 C 1074.2335,338.91546 1091.9317,338.14685 1110.2098,319.24186 C 1128.488,300.33686 1124.4955,207.63471 1124.4955,207.63471 z" | ||
2039 | id="path7991" | ||
2040 | sodipodi:nodetypes="czzzzc" /> | ||
2041 | <path | ||
2042 | sodipodi:type="arc" | ||
2043 | style="opacity:0.75;fill:url(#radialGradient3543);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:bevel;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter4120);enable-background:accumulate" | ||
2044 | id="path7993" | ||
2045 | sodipodi:cx="385" | ||
2046 | sodipodi:cy="237.00504" | ||
2047 | sodipodi:rx="86.428574" | ||
2048 | sodipodi:ry="73.928574" | ||
2049 | d="M 471.42857,237.00504 A 86.428574,73.928574 0 1 1 298.57143,237.00504 A 86.428574,73.928574 0 1 1 471.42857,237.00504 z" | ||
2050 | transform="matrix(0.9434749,-0.1239943,0.1440089,1.0957669,451.94827,134.5988)" | ||
2051 | clip-path="url(#clipPath4100)" /> | ||
2052 | <path | ||
2053 | transform="translate(450.03125,73.843964)" | ||
2054 | style="opacity:1;fill:url(#radialGradient3915);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2055 | d="M 527.60588,407.44884 C 527.60588,407.44884 405.56444,445.85232 340.09154,417.08065 C 274.61865,388.30899 265.71429,292.36218 265.71429,292.36218 C 265.71429,292.36218 339.09587,211.85825 395.63507,208.74742 C 451.46212,205.67578 486.20893,228.89074 510.50508,274.59913 C 534.85708,320.41261 527.60588,407.44884 527.60588,407.44884 z" | ||
2056 | id="path7995" | ||
2057 | sodipodi:nodetypes="csczzc" | ||
2058 | mask="url(#mask3684)" /> | ||
2059 | <path | ||
2060 | style="opacity:1;fill:url(#linearGradient3959);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:bevel;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2061 | d="M 772.17411,393.349 C 772.17411,393.349 808.39165,365.96653 823.78125,357.45614 C 838.95859,349.06313 849.49553,345.849 859.6741,345.849 L 844.13839,412.81328" | ||
2062 | id="path7997" | ||
2063 | sodipodi:nodetypes="czcc" /> | ||
2064 | <path | ||
2065 | sodipodi:type="arc" | ||
2066 | style="opacity:1;fill:url(#radialGradient3933);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:bevel;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2067 | id="path7999" | ||
2068 | sodipodi:cx="409.28571" | ||
2069 | sodipodi:cy="306.64789" | ||
2070 | sodipodi:rx="36.25" | ||
2071 | sodipodi:ry="36.25" | ||
2072 | d="M 445.53571,306.64789 A 36.25,36.25 0 1 1 373.03571,306.64789 A 36.25,36.25 0 1 1 445.53571,306.64789 z" | ||
2073 | transform="translate(449.49554,74.915393)" /> | ||
2074 | <path | ||
2075 | style="opacity:0.3;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8806);enable-background:accumulate" | ||
2076 | d="M 311.83409,415.43155 L 321.73359,537.05392 L 261.62951,673.52553 L 277.18586,848.1809 C 292.79912,910.0601 309.37131,946.84995 351.56201,965.23473 C 355.88112,928.99475 360.24362,892.86709 320.31937,742.11489 L 337.99704,672.81842 L 410.12193,534.22549 L 367.69553,375.83357 L 311.83409,415.43155 z" | ||
2077 | id="path8001" | ||
2078 | sodipodi:nodetypes="cccccccccc" | ||
2079 | clip-path="url(#clipPath8616)" | ||
2080 | transform="translate(276,136)" /> | ||
2081 | <path | ||
2082 | style="opacity:0.5;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8826);enable-background:accumulate" | ||
2083 | d="M 635.21025,581.13004 C 621.06811,593.85796 674.44372,615.71019 711.57778,605.17167 C 748.71184,594.63315 816.22265,569.6073 814.81537,525.97571 C 813.40809,482.34413 738.44784,397.28228 738.44784,397.28228 L 635.21025,581.13004 z" | ||
2084 | id="path8003" | ||
2085 | sodipodi:nodetypes="czzcc" /> | ||
2086 | <path | ||
2087 | sodipodi:type="arc" | ||
2088 | style="opacity:1;fill:url(#radialGradient3991);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:bevel;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2089 | id="path8005" | ||
2090 | sodipodi:cx="410" | ||
2091 | sodipodi:cy="306.64789" | ||
2092 | sodipodi:rx="23.214285" | ||
2093 | sodipodi:ry="23.214285" | ||
2094 | d="M 433.21428,306.64789 A 23.214285,23.214285 0 1 1 386.78572,306.64789 A 23.214285,23.214285 0 1 1 433.21428,306.64789 z" | ||
2095 | transform="translate(449.67411,74.915393)" /> | ||
2096 | <path | ||
2097 | sodipodi:type="arc" | ||
2098 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:bevel;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter3981);enable-background:accumulate" | ||
2099 | id="path8007" | ||
2100 | sodipodi:cx="414.28571" | ||
2101 | sodipodi:cy="303.07648" | ||
2102 | sodipodi:rx="7.5" | ||
2103 | sodipodi:ry="7.5" | ||
2104 | d="M 421.78571,303.07648 A 7.5,7.5 0 1 1 406.78571,303.07648 A 7.5,7.5 0 1 1 421.78571,303.07648 z" | ||
2105 | transform="translate(451.99554,73.486821)" /> | ||
2106 | <path | ||
2107 | style="opacity:1;fill:url(#radialGradient4112);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2108 | d="M 789.31696,478.349 C 789.31696,478.349 796.33977,497.91759 788.24553,513.349 C 780.15129,528.78041 745.92236,552.33722 720.74554,563.349 C 695.43582,574.41891 635.27254,596.31293 618.95982,605.31328 C 602.49834,614.39571 600.74554,617.99185 600.74554,617.99185 C 600.74554,617.99185 593.59861,598.92744 629.49553,566.20615 C 665.66764,533.23401 771.52265,518.15665 789.31696,478.349 z" | ||
2109 | id="path8009" | ||
2110 | sodipodi:nodetypes="czzzczc" /> | ||
2111 | <g | ||
2112 | style="opacity:1;display:inline;enable-background:new" | ||
2113 | id="g8011" | ||
2114 | transform="translate(780.74553,74.55825)"> | ||
2115 | <path | ||
2116 | transform="translate(-329.81481,0)" | ||
2117 | clip-path="url(#clipPath3999)" | ||
2118 | sodipodi:nodetypes="czzczzzszc" | ||
2119 | id="path8013" | ||
2120 | d="M 179.64286,267.36218 C 157.23242,307.0651 119.02676,383.14247 110.35715,417.00504 C 101.70994,450.78014 101.58516,483.42158 110,503.43362 C 118.3602,523.31575 136.16398,539.06642 150.71428,544.86218 C 150.1179,530.48631 165.08723,501.57635 223.57143,472.36218 C 282.1977,443.07704 301.95306,445.23132 327.14285,425.21932 C 352.77291,404.85756 335.34872,345.57268 330.35714,331.29075 C 325.36556,317.00882 329.12051,327.91101 328.41112,326.19774 C 317.72184,300.38182 294.1968,271.76744 263.92857,261.6479 C 233.66034,251.52836 198.91081,256.79953 179.64286,267.36218 z" | ||
2121 | style="opacity:1;fill:url(#radialGradient3585);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:20.79999924;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline" /> | ||
2122 | <path | ||
2123 | transform="matrix(0.8823874,0.4705236,-0.4705236,0.8823874,-166.62245,2.387362)" | ||
2124 | d="M 248.28731,338.07648 A 64.715881,134.00607 0 1 1 118.85555,338.07648 A 64.715881,134.00607 0 1 1 248.28731,338.07648 z" | ||
2125 | sodipodi:ry="134.00607" | ||
2126 | sodipodi:rx="64.715881" | ||
2127 | sodipodi:cy="338.07648" | ||
2128 | sodipodi:cx="183.57143" | ||
2129 | id="path8015" | ||
2130 | style="opacity:1;fill:url(#radialGradient4060);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:20.79999924;stroke-linecap:butt;stroke-linejoin:bevel;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2131 | sodipodi:type="arc" /> | ||
2132 | <path | ||
2133 | transform="matrix(0.8823874,0.4705236,-0.4705236,0.8823874,-162.19388,-18.755495)" | ||
2134 | d="M 248.28731,338.07648 A 64.715881,134.00607 0 1 1 118.85555,338.07648 A 64.715881,134.00607 0 1 1 248.28731,338.07648 z" | ||
2135 | sodipodi:ry="134.00607" | ||
2136 | sodipodi:rx="64.715881" | ||
2137 | sodipodi:cy="338.07648" | ||
2138 | sodipodi:cx="183.57143" | ||
2139 | id="path8017" | ||
2140 | style="opacity:1;fill:url(#radialGradient4062);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:20.79999924;stroke-linecap:butt;stroke-linejoin:bevel;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2141 | sodipodi:type="arc" /> | ||
2142 | <path | ||
2143 | transform="translate(-329.81481,3e-7)" | ||
2144 | clip-path="url(#clipPath3999)" | ||
2145 | sodipodi:nodetypes="czzczzzszc" | ||
2146 | id="path8019" | ||
2147 | d="M 179.64286,267.36218 C 157.23242,307.0651 119.02676,383.14247 110.35715,417.00504 C 101.70994,450.78014 101.58516,483.42158 110,503.43362 C 118.3602,523.31575 136.16398,539.06642 150.71428,544.86218 C 150.1179,530.48631 165.08723,501.57635 223.57143,472.36218 C 282.1977,443.07704 301.95306,445.23132 327.14285,425.21932 C 352.77291,404.85756 335.34872,345.57268 330.35714,331.29075 C 325.36556,317.00882 329.12051,327.91101 328.41112,326.19774 C 317.72184,300.38182 294.1968,271.76744 263.92857,261.6479 C 233.66034,251.52836 198.91081,256.79953 179.64286,267.36218 z" | ||
2148 | style="opacity:1;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient3587);stroke-width:20.79999924;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline;filter:url(#filter4079);enable-background:new" /> | ||
2149 | </g> | ||
2150 | <path | ||
2151 | sodipodi:type="arc" | ||
2152 | style="opacity:1;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:bevel;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2153 | id="path8021" | ||
2154 | sodipodi:cx="310.71429" | ||
2155 | sodipodi:cy="398.07648" | ||
2156 | sodipodi:rx="19.704132" | ||
2157 | sodipodi:ry="19.704132" | ||
2158 | d="M 330.41843,398.07648 A 19.704132,19.704132 0 1 1 291.01016,398.07648 A 19.704132,19.704132 0 1 1 330.41843,398.07648 z" | ||
2159 | transform="translate(452.55663,72.581273)" /> | ||
2160 | <path | ||
2161 | sodipodi:type="arc" | ||
2162 | style="opacity:1;fill:url(#radialGradient4056);fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient4082);stroke-width:20.79999924;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter4083);enable-background:accumulate" | ||
2163 | id="path8023" | ||
2164 | sodipodi:cx="310.71429" | ||
2165 | sodipodi:cy="398.07648" | ||
2166 | sodipodi:rx="19.704132" | ||
2167 | sodipodi:ry="19.704132" | ||
2168 | d="M 330.41843,398.07648 A 19.704132,19.704132 0 1 1 291.01016,398.07648 A 19.704132,19.704132 0 1 1 330.41843,398.07648 z" | ||
2169 | transform="translate(450.55663,72.581273)" /> | ||
2170 | <path | ||
2171 | sodipodi:type="arc" | ||
2172 | style="opacity:1;fill:url(#radialGradient4119);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:bevel;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2173 | id="path8025" | ||
2174 | sodipodi:cx="310.71429" | ||
2175 | sodipodi:cy="398.07648" | ||
2176 | sodipodi:rx="19.704132" | ||
2177 | sodipodi:ry="19.704132" | ||
2178 | d="M 330.41843,398.07648 A 19.704132,19.704132 0 1 1 291.01016,398.07648 A 19.704132,19.704132 0 1 1 330.41843,398.07648 z" | ||
2179 | transform="translate(450.55663,72.581273)" /> | ||
2180 | <path | ||
2181 | sodipodi:type="arc" | ||
2182 | style="opacity:1;fill:url(#radialGradient4868);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:0.99999994px;stroke-linecap:butt;stroke-linejoin:bevel;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter4002);enable-background:accumulate" | ||
2183 | id="path8027" | ||
2184 | sodipodi:cx="429.56738" | ||
2185 | sodipodi:cy="377.42877" | ||
2186 | sodipodi:rx="72.079735" | ||
2187 | sodipodi:ry="44.547726" | ||
2188 | d="M 501.64712,377.42877 A 72.079735,44.547726 0 1 1 357.48765,377.42877 A 72.079735,44.547726 0 1 1 501.64712,377.42877 z" | ||
2189 | transform="matrix(0.9969564,-7.7961675e-2,7.7961675e-2,0.9969564,436.61877,125.29509)" | ||
2190 | inkscape:transform-center-x="-47.231976" | ||
2191 | inkscape:transform-center-y="-3.6935079" /> | ||
2192 | <path | ||
2193 | sodipodi:type="arc" | ||
2194 | style="opacity:1;fill:url(#radialGradient4876);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:0.99999994px;stroke-linecap:butt;stroke-linejoin:bevel;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter4010);enable-background:accumulate" | ||
2195 | id="path8029" | ||
2196 | sodipodi:cx="437.6991" | ||
2197 | sodipodi:cy="391.21735" | ||
2198 | sodipodi:rx="36.611931" | ||
2199 | sodipodi:ry="22.627417" | ||
2200 | d="M 474.31103,391.21735 A 36.611931,22.627417 0 1 1 401.08717,391.21735 A 36.611931,22.627417 0 1 1 474.31103,391.21735 z" | ||
2201 | transform="matrix(1.4357951,-6.9991037e-2,6.9991037e-2,1.4357951,235.18065,-63.86546)" | ||
2202 | inkscape:transform-center-x="-20.955902" | ||
2203 | inkscape:transform-center-y="-13.056625" /> | ||
2204 | <g | ||
2205 | transform="translate(450.03125,73.843964)" | ||
2206 | id="g8031" | ||
2207 | style="opacity:1;display:inline;filter:url(#filter4053);enable-background:new"> | ||
2208 | <path | ||
2209 | d="M 416.87499,401.82648 A 3.2142856,3.2142856 0 1 1 410.44642,401.82648 A 3.2142856,3.2142856 0 1 1 416.87499,401.82648 z" | ||
2210 | sodipodi:ry="3.2142856" | ||
2211 | sodipodi:rx="3.2142856" | ||
2212 | sodipodi:cy="401.82648" | ||
2213 | sodipodi:cx="413.66071" | ||
2214 | id="path8033" | ||
2215 | style="opacity:1;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient4484);stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2216 | sodipodi:type="arc" /> | ||
2217 | <path | ||
2218 | transform="translate(13.125009,8.1249913)" | ||
2219 | d="M 416.87499,401.82648 A 3.2142856,3.2142856 0 1 1 410.44642,401.82648 A 3.2142856,3.2142856 0 1 1 416.87499,401.82648 z" | ||
2220 | sodipodi:ry="3.2142856" | ||
2221 | sodipodi:rx="3.2142856" | ||
2222 | sodipodi:cy="401.82648" | ||
2223 | sodipodi:cx="413.66071" | ||
2224 | id="path8035" | ||
2225 | style="opacity:1;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient4486);stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2226 | sodipodi:type="arc" /> | ||
2227 | <path | ||
2228 | transform="translate(32.946437,7.4999913)" | ||
2229 | d="M 416.87499,401.82648 A 3.2142856,3.2142856 0 1 1 410.44642,401.82648 A 3.2142856,3.2142856 0 1 1 416.87499,401.82648 z" | ||
2230 | sodipodi:ry="3.2142856" | ||
2231 | sodipodi:rx="3.2142856" | ||
2232 | sodipodi:cy="401.82648" | ||
2233 | sodipodi:cx="413.66071" | ||
2234 | id="path8037" | ||
2235 | style="opacity:1;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient4488);stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2236 | sodipodi:type="arc" /> | ||
2237 | <path | ||
2238 | transform="translate(24.910723,-10.267866)" | ||
2239 | d="M 416.87499,401.82648 A 3.2142856,3.2142856 0 1 1 410.44642,401.82648 A 3.2142856,3.2142856 0 1 1 416.87499,401.82648 z" | ||
2240 | sodipodi:ry="3.2142856" | ||
2241 | sodipodi:rx="3.2142856" | ||
2242 | sodipodi:cy="401.82648" | ||
2243 | sodipodi:cx="413.66071" | ||
2244 | id="path8039" | ||
2245 | style="opacity:1;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient4490);stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2246 | sodipodi:type="arc" /> | ||
2247 | <path | ||
2248 | transform="translate(47.589294,-0.6250087)" | ||
2249 | d="M 416.87499,401.82648 A 3.2142856,3.2142856 0 1 1 410.44642,401.82648 A 3.2142856,3.2142856 0 1 1 416.87499,401.82648 z" | ||
2250 | sodipodi:ry="3.2142856" | ||
2251 | sodipodi:rx="3.2142856" | ||
2252 | sodipodi:cy="401.82648" | ||
2253 | sodipodi:cx="413.66071" | ||
2254 | id="path8041" | ||
2255 | style="opacity:1;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient4492);stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2256 | sodipodi:type="arc" /> | ||
2257 | </g> | ||
2258 | <path | ||
2259 | style="opacity:1;fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2260 | d="M 896.20301,482.92837 C 897.1881,487.27845 900.74008,489.10785 903.58974,490.82019 C 908.05042,493.33311 910.1099,492.3423 912.74425,490.06258 C 914.3462,488.14141 923.42736,485.36393 928.33848,482.99151 C 932.66809,481.5326 937.24178,477.63278 941.723,474.65775 C 945.11814,473.03051 947.06964,475.01239 949.55168,475.6679 C 952.4958,476.38451 953.96285,477.83965 955.6126,479.20344 C 958.00876,480.37863 954.6847,482.34657 958.8956,483.49658 C 960.08651,483.71452 961.31255,484.07303 962.17859,482.99151" | ||
2261 | id="path8043" | ||
2262 | sodipodi:nodetypes="ccccccccc" /> | ||
2263 | <path | ||
2264 | style="opacity:1;fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2265 | d="M 910.85021,475.35223 C 913.16515,475.32025 914.02799,475.99476 916.34292,474.53148 C 919.79856,471.45035 921.74546,471.38671 924.29787,470.11206 C 927.32444,468.79683 930.83357,478.26375 934.3994,479.96105 C 936.79449,479.13963 935.68854,481.75484 935.85149,482.6127 C 935.90862,485.25954 938.65843,486.29076 940.20777,488.04227 C 943.52381,490.29776 947.583,494.33773 951.31945,493.34557 C 957.7647,490.4145 961.59867,492.06411 967.60816,485.95883 C 968.31221,484.77749 967.02391,479.06423 970.70175,478.76149 C 973.22574,479.01487 974.86842,478.81164 976.76267,479.32971 C 982.20367,481.4469 984.50045,485.77971 991.47301,487.28466 C 997.65591,488.25105 999.08565,491.07892 1005.3626,492.33542" | ||
2266 | id="path8045" | ||
2267 | sodipodi:nodetypes="cccccccccccc" /> | ||
2268 | <path | ||
2269 | style="opacity:1;fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2270 | d="M 876.98133,483.52197 C 879.37991,482.72817 883.08746,487.71407 885.15446,490.56765 C 885.74727,493.24717 886.30823,496.0541 885.91207,502.68948 C 886.6972,505.10702 888.59256,505.72043 890.7103,505.97248 C 893.82775,505.4357 896.58699,504.64818 898.0339,502.94202 C 899.9055,501.00035 903.34643,505.33596 906.11512,506.98263 C 909.72521,508.89472 913.8889,508.96149 917.98442,509.25547 C 919.688,509.02483 920.35482,513.77062 921.26741,517.3367 C 921.65155,521.71476 920.38197,524.23239 919.49965,527.18568 C 919.20535,529.68223 922.48815,530.71542 925.8131,531.73137 C 928.99554,532.47261 932.35734,533.39321 934.90447,533.49914 C 940.04633,534.37405 942.99321,536.18966 947.0263,537.53975 C 949.26544,538.3563 950.28649,539.78191 951.57199,541.07528" | ||
2271 | id="path8047" | ||
2272 | sodipodi:nodetypes="ccccccccccccc" /> | ||
2273 | <path | ||
2274 | style="opacity:0.25;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter8814);enable-background:new" | ||
2275 | d="M 332,187.69519 C 332,187.69519 389.5,162.19519 389.5,159.69519 C 389.5,157.19519 395,107.69519 395,107.69519 C 395,107.69519 486,59.195189 486.5,57.195189 C 487,55.195189 572.5,-4.8048114 572.5,-4.8048114 L 386.5,17.195189 L 311,123.19519 L 332,187.69519 z" | ||
2276 | id="path8049" | ||
2277 | clip-path="url(#clipPath8514)" | ||
2278 | transform="translate(276,136)" /> | ||
2279 | <path | ||
2280 | style="opacity:0.25;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2281 | d="M 1697.2846,722.5514 C 1697.2846,722.5514 1581.3191,796.0905 1574.2481,800.33314 C 1567.177,804.57578 1343.7312,937.51186 1343.7312,937.51186 L 1347.9739,977.10984 L 1564.3486,876.70067 L 1681.7283,774.8773 L 1697.2846,722.5514 z" | ||
2282 | id="path8051" /> | ||
2283 | <path | ||
2284 | style="opacity:0.5;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8810);enable-background:accumulate" | ||
2285 | d="M 528.91587,556.85291 C 523.25902,555.4387 347.89654,631.80623 347.89654,631.80623 L 313.95541,812.82557 L 365.05087,1006.7738 L 622.25397,1074.4551 C 622.25397,1074.4551 828.72915,1227.1901 834.386,1222.9475 C 840.04286,1218.7049 1002.6774,1029.2002 1002.6774,1029.2002 L 842.87128,845.35248 L 796.20224,667.16157 L 528.91587,556.85291 z" | ||
2286 | id="path8053" | ||
2287 | clip-path="url(#clipPath8610)" | ||
2288 | sodipodi:nodetypes="cccccscccc" | ||
2289 | transform="translate(276,136)" /> | ||
2290 | <path | ||
2291 | style="opacity:1;fill:#0c0c0c;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2292 | d="M 1097.6433,613.88997 C 1097.6433,613.88997 1120.2628,607.38316 1133.386,608.01724 C 1146.5093,608.65133 1164.0276,609.95586 1177.0949,620.20343 C 1190.1622,630.45099 1202.1626,647.3435 1211.2073,678.57308 C 1220.2519,709.80266 1212.9056,777.82509 1205.0312,821.92043 C 1197.1569,866.01577 1176.7661,928.03341 1160.0312,961.92043 C 1143.2964,995.80745 1110.2335,1039.4156 1099.4618,1051.7966 C 1088.0976,1064.8586 1043.2559,1088.2228 1020.0312,1094.0633 C 1025.3346,1083.4567 1068.931,1043.4744 1055.0312,1033.349 C 1041.0123,1023.1367 1009.2712,1079.3314 970.7381,1062.3822 C 992.12041,1049.2501 1012.5175,1011.1961 1004.7787,995.78772 C 996.93846,980.17733 974.07378,1044.5453 911.24317,1032.8006 C 941.29521,1005.2739 966.65023,961.89659 952.50587,949.8209 C 938.09071,937.51403 892.04412,1004.1141 892.04412,1004.1141 C 892.04412,1004.1141 889.22222,962.41287 905.81732,935.50673 C 922.45667,908.52886 985.47029,853.89146 1005.3704,823.80331 C 1025.2706,793.71517 1038.983,757.79429 1047.5059,731.28537 C 1056.0287,704.77645 1063.3068,654.18583 1063.3068,654.18583" | ||
2293 | id="path8055" | ||
2294 | sodipodi:nodetypes="czzzzzzczczczczzzc" /> | ||
2295 | <path | ||
2296 | style="opacity:0.25;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8818);enable-background:accumulate" | ||
2297 | d="M 770.74639,609.17881 L 719.8347,706.75955 L 639.93163,817.77531 L 674.57987,889.19309 L 717.00628,968.38906 L 789.13117,923.13422 L 803.27331,730.80117 L 824.48651,592.20825 L 810.34437,502.05213 L 770.74639,609.17881 z" | ||
2298 | id="path8057" | ||
2299 | clip-path="url(#clipPath8622)" | ||
2300 | sodipodi:nodetypes="cccccccccc" | ||
2301 | transform="translate(276,136)" /> | ||
2302 | <path | ||
2303 | style="opacity:1;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8810);enable-background:accumulate" | ||
2304 | d="M 295,846.19519 L 301.64488,777.27234 C 301.64488,777.27234 391.96439,866.27691 464,900.19519 C 536.03561,934.11347 772,962.19519 772,962.19519 L 926,936.19519 L 890,1098.1952 L 604,1124.1952 L 306,1035.1952 L 295,846.19519 z" | ||
2305 | id="path8059" | ||
2306 | clip-path="url(#clipPath8906)" | ||
2307 | sodipodi:nodetypes="cczcccccc" | ||
2308 | transform="translate(276,136)" /> | ||
2309 | <path | ||
2310 | transform="translate(450.03125,73.843964)" | ||
2311 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter3587);enable-background:new" | ||
2312 | d="M 405.79629,845.99023 L 480.74961,911.04406 L 483.24924,927.92446 L 502.6526,938.08337 L 509.14464,961.13446 L 540.85369,952.76336 L 555.70293,1000.8466 C 567.95945,1013.5745 645.49637,887.7369 611.56436,1039.0304 L 550.75318,1055.2939 L 461.55026,960.60104 L 398.72523,906.80141 L 405.79629,845.99023 z" | ||
2313 | id="path8061" | ||
2314 | sodipodi:nodetypes="cccccccccccc" | ||
2315 | clip-path="url(#clipPath3602)" /> | ||
2316 | <path | ||
2317 | style="opacity:1;fill:#121212;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" | ||
2318 | d="M 1159.317,918.349 C 1213.6027,916.92043 1285.352,903.29701 1329.317,891.56328 C 1373.3697,879.80614 1455.2033,855.21604 1504.674,833.70614 C 1554.0133,812.25342 1618.2778,774.42454 1658.9599,741.56329 C 1699.468,708.8426 1711.3498,685.74348 1719.6741,707.99186 C 1728.0432,730.35965 1703.2672,764.31748 1681.817,789.06329 C 1660.2128,813.98669 1629.0856,841.76862 1582.8883,878.349 C 1536.691,914.92938 1426.8058,979.93363 1370.0312,1006.9204 C 1312.9652,1034.0458 1241.8279,1065.1589 1197.8884,1079.4205 C 1153.9489,1093.6821 1066.4598,1110.4919 1066.4598,1110.4919 L 1159.317,918.349 z" | ||
2319 | id="path8063" | ||
2320 | sodipodi:nodetypes="czzzzzzzzcc" /> | ||
2321 | <path | ||
2322 | transform="translate(450.03125,73.843964)" | ||
2323 | style="opacity:0.5;fill:url(#linearGradient3666);fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter3779);enable-background:accumulate" | ||
2324 | d="M 1241.5965,652.95007 C 1241.5965,652.95007 1176.875,707.28713 1095.9326,751.94501 C 1013.9082,797.19985 811.67556,845.28311 811.67556,845.28311 C 811.67556,845.28311 796.57419,866.33507 856.93045,873.56739 C 917.28671,880.79971 1081.0124,820.2667 1135.5306,777.40085 C 1190.0488,734.535 1255.7387,665.67799 1255.7387,665.67799 L 1241.5965,652.95007 z" | ||
2325 | id="path8065" | ||
2326 | sodipodi:nodetypes="czczzcc" | ||
2327 | clip-path="url(#clipPath3992)" /> | ||
2328 | <g | ||
2329 | transform="translate(450.03125,73.843964)" | ||
2330 | style="opacity:1;display:inline;enable-background:new" | ||
2331 | id="g8067" | ||
2332 | clip-path="url(#clipPath3986)"> | ||
2333 | <g | ||
2334 | transform="translate(-174.03125,62.156036)" | ||
2335 | style="filter:url(#filter3677)" | ||
2336 | id="g8069"> | ||
2337 | <g | ||
2338 | style="filter:url(#filter3785)" | ||
2339 | id="g8071"> | ||
2340 | <path | ||
2341 | sodipodi:nodetypes="czzccccc" | ||
2342 | id="path8073" | ||
2343 | d="M 1094.2857,725.93361 C 1094.2857,725.93361 1093.9896,752.09452 1098.9285,763.79076 C 1103.8674,775.487 1118.9666,790.27741 1127.5,795.21933 C 1136.0334,800.16125 1146.4286,803.79075 1146.4286,803.79075 L 1264.2857,688.79075 L 1282.1429,613.07647 L 1185.7143,651.6479 L 1094.2857,725.93361 z" | ||
2344 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2345 | transform="translate(174.03125,-62.156036)" /> | ||
2346 | <rect | ||
2347 | y="486.14224" | ||
2348 | x="1197.8389" | ||
2349 | height="309.71277" | ||
2350 | width="333.75412" | ||
2351 | id="rect8075" | ||
2352 | style="opacity:1;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
2353 | </g> | ||
2354 | </g> | ||
2355 | <g | ||
2356 | transform="translate(-174.03125,62.156036)" | ||
2357 | style="opacity:0.18000004;display:inline;enable-background:new" | ||
2358 | id="g8077"> | ||
2359 | <g | ||
2360 | style="filter:url(#filter3785)" | ||
2361 | id="g8079"> | ||
2362 | <path | ||
2363 | sodipodi:nodetypes="czzccccc" | ||
2364 | id="path8081" | ||
2365 | d="M 1094.2857,725.93361 C 1094.2857,725.93361 1093.9896,752.09452 1098.9285,763.79076 C 1103.8674,775.487 1118.9666,790.27741 1127.5,795.21933 C 1136.0334,800.16125 1146.4286,803.79075 1146.4286,803.79075 L 1264.2857,688.79075 L 1282.1429,613.07647 L 1185.7143,651.6479 L 1094.2857,725.93361 z" | ||
2366 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2367 | transform="translate(174.03125,-62.156036)" /> | ||
2368 | <rect | ||
2369 | y="486.14224" | ||
2370 | x="1197.8389" | ||
2371 | height="309.71277" | ||
2372 | width="333.75412" | ||
2373 | id="rect8083" | ||
2374 | style="opacity:1;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
2375 | </g> | ||
2376 | </g> | ||
2377 | </g> | ||
2378 | <path | ||
2379 | transform="translate(450.03125,73.843964)" | ||
2380 | style="opacity:0.83300003;fill:#050505;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:15;stroke-linecap:butt;stroke-linejoin:miter;marker:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter8225);enable-background:accumulate" | ||
2381 | d="M 1264.1875,605 C 1259.6964,605.73268 1256.0305,608.45509 1252.25,611.40625 C 1242.1687,619.27601 1224.0805,645.83149 1204.2188,661.875 C 1164.3514,694.07816 1100.2228,731.85201 1051.6562,752.96875 C 1003.0422,774.10613 921.11498,798.78676 877.34375,810.46875 C 833.94554,822.05121 762.29972,835.59982 709.09375,837 L 704.53125,837.125 L 702.53125,841.25 L 609.6875,1033.375 L 603.1875,1046.8438 L 617.84375,1044 C 617.84375,1044 705.11343,1027.3486 750.1875,1012.7188 C 794.9127,998.20213 865.97836,967.05197 923.21875,939.84375 C 980.82199,912.46306 1090.1551,847.86412 1137.5,810.375 C 1183.8608,773.66518 1215.3049,745.65818 1237.4375,720.125 C 1248.3386,707.549 1260.1823,692.59356 1268.4688,677.375 C 1276.7552,662.15644 1287.6285,633.15692 1282.1562,618.53125 C 1280.9385,615.27651 1279.6048,612.46995 1277.5625,610.03125 C 1275.5202,607.59255 1269.0878,608.45926 1269,605 C 1268.7902,596.73518 1265.6845,604.75577 1264.1875,605 z M 1266.3438,620.21875 C 1266.7586,620.80449 1267.3749,621.77641 1268.125,623.78125 C 1271.0218,631.52338 1266.6843,655.68 1259.3125,669.21875 C 1251.9407,682.7575 1236.6741,698.14269 1226.125,710.3125 C 1205.0496,734.62606 1174.2213,762.17406 1128.1875,798.625 C 1083.1379,834.29659 972.72717,899.71959 916.78125,926.3125 C 859.88952,953.35499 788.68509,984.4309 745.53125,998.4375 C 709.16634,1010.2406 649.68654,1022.2713 629.8125,1026.2188 L 714.09375,851.75 C 768.80066,849.7007 837.88634,836.53365 881.21875,824.96875 C 925.55297,813.1365 1007.2974,788.63242 1057.625,766.75 C 1107.737,744.96129 1170.1594,705.58184 1211.6562,672.0625 C 1232.3026,655.38529 1253.4011,629.51662 1261.4688,623.21875 C 1263.9058,621.31633 1265.5494,620.58295 1266.3438,620.21875 z" | ||
2382 | id="path8085" | ||
2383 | clip-path="url(#clipPath3722)" | ||
2384 | sodipodi:nodetypes="cssssccccccssssssssccssssssccssssc" /> | ||
2385 | <g | ||
2386 | style="opacity:1;display:inline;enable-background:new" | ||
2387 | id="g8087" | ||
2388 | mask="url(#mask7704)" | ||
2389 | transform="matrix(0.9934486,0.1142802,-0.1142802,0.9934486,-9.24324,588.09054)" | ||
2390 | inkscape:transform-center-x="-185.09603" | ||
2391 | inkscape:transform-center-y="-12.859654"> | ||
2392 | <path | ||
2393 | transform="translate(8.0045714e-2,-3.125e-2)" | ||
2394 | style="fill:#bcb786;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2395 | d="M 1111.4062,-285.9375 L 1107.4688,-284.0625 C 1107.4283,-284.05228 1107.3692,-284.04201 1107.3438,-284.03125 C 1106.925,-283.8184 1107.1791,-283.93067 1106.6875,-283.71875 C 1106.2014,-283.50919 1104.9499,-283.13456 1102.5938,-282.25 C 1099.2626,-280.99942 1096.7895,-280.10016 1095.5938,-279.1875 C 1094.0576,-279.16623 1091.8733,-278.95419 1089.9375,-278.46875 C 1086.956,-277.72108 1085.0823,-277.29474 1083.1875,-276.875 C 1081.2927,-276.45527 1081.512,-276.23281 1080.3125,-276 C 1079.0159,-275.74833 1078.5911,-276.00899 1074.875,-275.21875 C 1071.3851,-274.4766 1065.9802,-273.28768 1064.7188,-272.53125 C 1063.1348,-272.71203 1060.8513,-272.85303 1058.875,-272.5625 C 1055.8346,-272.11554 1053.9588,-271.88974 1052.0312,-271.65625 C 1051.3758,-271.57687 1050.9902,-271.45547 1050.6875,-271.375 C 1050.2613,-271.24334 1050.0017,-271.11498 1049.3125,-271.03125 C 1048.0009,-270.87188 1047.5503,-271.18808 1043.7812,-270.75 C 1040.2273,-270.33691 1034.7758,-269.47718 1033.5312,-268.8125 C 1031.9322,-269.10979 1029.6735,-269.34669 1027.6875,-269.15625 C 1024.6287,-268.86293 1022.7155,-268.67226 1020.7812,-268.5 C 1018.847,-268.32773 1019.0926,-268.07763 1017.875,-267.96875 C 1016.5588,-267.85105 1016.1152,-268.13238 1012.3438,-267.71875 C 1008.8017,-267.3303 1003.3359,-266.50948 1002.0625,-265.84375 C 1000.4636,-266.13844 998.1753,-266.35076 996.1875,-266.15625 C 993.12921,-265.857 991.2463,-265.67601 989.3125,-265.5 C 988.65501,-265.44015 988.27245,-265.32144 987.96875,-265.25 C 987.54105,-265.13104 987.28525,-265.03193 986.59375,-264.96875 C 985.27775,-264.84849 984.834,-265.16363 981.0625,-264.75 C 977.50631,-264.35998 972.0569,-263.51084 970.8125,-262.84375 C 969.21381,-263.13793 966.95265,-263.36747 964.96875,-263.15625 C 961.91305,-262.83092 959.9947,-262.63001 958.0625,-262.4375 C 956.13031,-262.24499 956.37275,-261.99662 955.15625,-261.875 C 953.84137,-261.74353 953.3932,-262.03954 949.625,-261.59375 C 946.08611,-261.17509 940.6473,-260.30158 939.375,-259.625 C 937.77741,-259.90604 935.51505,-260.04543 933.53125,-259.8125 C 930.47927,-259.45413 928.58625,-259.24464 926.65625,-259.03125 C 926.00007,-258.95869 925.6156,-258.85856 925.3125,-258.78125 C 924.88571,-258.65402 924.6276,-258.51405 923.9375,-258.4375 C 922.62411,-258.29181 922.17015,-258.61152 918.40625,-258.125 C 914.85737,-257.66624 909.4276,-256.70598 908.1875,-256 C 906.59441,-256.24424 904.3537,-256.38135 902.375,-256.125 C 899.32741,-255.73018 897.4243,-255.47655 895.5,-255.21875 C 893.57571,-254.96096 893.7739,-254.72522 892.5625,-254.5625 C 891.25301,-254.3866 890.8153,-254.66688 887.0625,-254.09375 C 883.53821,-253.55551 878.1393,-252.39458 876.875,-251.65625 C 875.28751,-251.85979 873.0295,-251.91098 871.0625,-251.5625 C 868.03631,-251.02638 866.1636,-250.70081 864.25,-250.375 C 863.59941,-250.26423 863.2363,-250.10406 862.9375,-250 C 862.51681,-249.83512 862.27405,-249.6687 861.59375,-249.53125 C 860.29905,-249.26966 859.86665,-249.53745 856.15625,-248.71875 C 852.65777,-247.9468 847.31035,-246.33582 846.09375,-245.5 C 844.53085,-245.57745 842.33625,-245.41472 840.40625,-244.90625 C 837.43387,-244.12312 835.58855,-243.67416 833.71875,-243.15625 C 831.84875,-242.63835 832.0521,-242.38897 830.875,-242.0625 C 829.60251,-241.7096 829.17795,-241.95541 825.53125,-240.875 C 822.10657,-239.86037 816.88185,-237.94183 815.65625,-237.03125 C 814.11747,-237.01851 811.93645,-236.75903 810.03125,-236.15625 C 807.10027,-235.22891 805.2809,-234.69783 803.4375,-234.09375 C 802.81071,-233.88837 802.44585,-233.70117 802.15625,-233.5625 C 801.74867,-233.34889 801.50295,-233.15375 800.84375,-232.9375 C 799.58925,-232.52596 799.1576,-232.74846 795.5625,-231.5 C 792.17261,-230.32283 786.96755,-228.2863 785.78125,-227.34375 C 784.25737,-227.28408 782.1312,-226.94888 780.25,-226.28125 C 777.35261,-225.25296 775.55095,-224.60577 773.71875,-223.96875 C 771.88655,-223.33174 772.0909,-223.12021 770.9375,-222.71875 C 769.69071,-222.28479 769.27395,-222.51903 765.71875,-221.15625 C 762.38005,-219.87645 757.23165,-217.6737 756.03125,-216.6875 C 754.52407,-216.57981 752.39555,-216.1887 750.53125,-215.46875 C 747.66307,-214.36115 745.90735,-213.68719 744.09375,-213 C 743.47705,-212.76637 743.0973,-212.55797 742.8125,-212.40625 C 742.81251,-212.40625 742.8125,-212.37673 742.8125,-212.375 L 734.8125,-209.1875 L 722.3366,-205.69561 L 730.26626,-186.41789 C 729.67463,-184.44432 742.8125,-191.15625 742.8125,-191.15625 C 743.03891,-191.30093 743.26145,-191.42886 743.53125,-191.53125 C 744.61177,-191.94123 745.70285,-191.74702 749.53125,-193.21875 C 753.35977,-194.69049 754.7553,-195.22373 755.4375,-195.625 C 756.11711,-196.02478 757.04925,-196.50437 757.65625,-197.15625 C 759.48317,-197.294 761.22705,-197.64948 762.59375,-198.15625 C 765.56175,-199.25677 767.4691,-199.96244 769.375,-200.625 C 771.28081,-201.28754 771.72915,-202.03987 772.78125,-202.40625 C 773.87287,-202.78636 774.97635,-202.57163 778.84375,-203.9375 C 782.71115,-205.30336 784.1269,-205.76458 784.8125,-206.15625 C 785.51361,-206.55677 786.5133,-207.08923 787.125,-207.75 C 789.09581,-207.80466 790.94195,-208.13463 792.40625,-208.625 C 795.40777,-209.63008 797.3324,-210.24671 799.25,-210.875 C 800.78861,-211.3791 801.42415,-211.92177 802.15625,-212.3125 C 802.38647,-212.44681 802.63215,-212.56623 802.90625,-212.65625 C 804.00457,-213.01673 805.0877,-212.73762 809,-213.96875 C 812.91231,-215.19988 814.366,-215.6417 815.0625,-216 C 815.75641,-216.35697 816.6926,-216.79261 817.3125,-217.40625 C 819.17771,-217.42891 820.94835,-217.67308 822.34375,-218.09375 C 825.37415,-219.00729 827.33615,-219.52385 829.28125,-220.0625 C 831.22637,-220.60114 831.70745,-221.32702 832.78125,-221.625 C 833.89527,-221.93415 835.00125,-221.61761 838.96875,-222.65625 C 842.93625,-223.69488 844.38625,-224.08898 845.09375,-224.40625 C 845.82855,-224.73584 846.90765,-225.15997 847.53125,-225.78125 C 849.52907,-225.66525 851.3887,-225.80134 852.875,-226.15625 C 855.95311,-226.89125 857.9584,-227.25719 859.9375,-227.65625 C 861.52541,-227.97643 862.1818,-228.4468 862.9375,-228.75 C 863.17501,-228.8568 863.4044,-228.94276 863.6875,-229 C 864.82091,-229.22919 865.99215,-228.79107 870.03125,-229.5 C 874.07067,-230.20893 875.5315,-230.42709 876.25,-230.6875 C 876.96581,-230.94694 877.95435,-231.25474 878.59375,-231.78125 C 880.51795,-231.54176 882.34165,-231.55672 883.78125,-231.78125 C 886.90767,-232.26887 888.9358,-232.48192 890.9375,-232.75 C 892.93921,-233.01807 893.42625,-233.69514 894.53125,-233.84375 C 895.67767,-233.99793 896.8071,-233.54218 900.875,-234.0625 C 904.94281,-234.58282 906.43525,-234.75823 907.15625,-235 C 907.89337,-235.24714 908.95435,-235.58623 909.59375,-236.125 C 911.64375,-235.78947 913.56745,-235.72704 915.09375,-235.90625 C 918.23595,-236.27521 920.27375,-236.46561 922.28125,-236.6875 C 923.89207,-236.86552 924.5459,-237.2957 925.3125,-237.53125 C 925.55341,-237.61677 925.80655,-237.68685 926.09375,-237.71875 C 927.24345,-237.84647 928.39505,-237.3721 932.46875,-237.84375 C 936.54245,-238.3154 938.0278,-238.45435 938.75,-238.6875 C 939.46941,-238.91977 940.45025,-239.16096 941.09375,-239.65625 C 943.03005,-239.32279 944.8638,-239.25201 946.3125,-239.40625 C 949.45851,-239.7412 951.49,-239.92484 953.5,-240.125 C 955.50991,-240.32514 955.98415,-240.95139 957.09375,-241.0625 C 958.24485,-241.17778 959.39025,-240.69744 963.46875,-241.125 C 967.54725,-241.55256 969.05765,-241.68709 969.78125,-241.90625 C 970.52047,-242.13011 971.57685,-242.4195 972.21875,-242.9375 C 974.27575,-242.53883 976.2206,-242.4441 977.75,-242.59375 C 980.89871,-242.90185 982.9258,-243.067 984.9375,-243.25 C 986.55151,-243.39682 987.20055,-243.81055 987.96875,-244.03125 C 988.21005,-244.11211 988.4623,-244.16116 988.75,-244.1875 C 989.90211,-244.29295 991.0429,-243.79475 995.125,-244.1875 C 999.20711,-244.58025 1000.7139,-244.71834 1001.4375,-244.9375 C 1002.1584,-245.15583 1003.1371,-245.3852 1003.7812,-245.875 C 1005.7193,-245.52501 1007.5501,-245.42062 1009,-245.5625 C 1012.1487,-245.8706 1014.1758,-246.03575 1016.1875,-246.21875 C 1018.1991,-246.40174 1018.7017,-247.05677 1019.8125,-247.15625 C 1020.9648,-247.25948 1022.1047,-246.77142 1026.1875,-247.15625 C 1030.2704,-247.54107 1031.7762,-247.65725 1032.5,-247.875 C 1033.2393,-248.09743 1034.2956,-248.38949 1034.9375,-248.90625 C 1036.9949,-248.50448 1038.9404,-248.40292 1040.4688,-248.5625 C 1043.6153,-248.89102 1045.6458,-249.0852 1047.6562,-249.28125 C 1049.2692,-249.43854 1049.9219,-249.91273 1050.6875,-250.15625 C 1050.9282,-250.24429 1051.1507,-250.27762 1051.4375,-250.3125 C 1052.5858,-250.4522 1053.7542,-249.97259 1057.8125,-250.5625 C 1061.8708,-251.15242 1063.3743,-251.33964 1064.0938,-251.59375 C 1064.8104,-251.84691 1065.7684,-252.15182 1066.4062,-252.6875 C 1068.3259,-252.47556 1070.1262,-252.53609 1071.5625,-252.78125 C 1074.6816,-253.31365 1076.6741,-253.70986 1078.6562,-254.09375 C 1080.6383,-254.47762 1081.1305,-255.1334 1082.2188,-255.375 C 1083.3475,-255.62566 1084.489,-255.25871 1088.4688,-256.25 C 1092.4483,-257.24127 1093.8983,-257.6693 1094.5938,-258.03125 C 1095.316,-258.40725 1096.3555,-258.90183 1096.9688,-259.5625 C 1098.9317,-259.57454 1100.7625,-259.85355 1102.1875,-260.40625 C 1105.1387,-261.55085 1107.0607,-262.27567 1108.875,-263.15625 C 1110.3307,-263.86277 1111.1941,-264.85828 1111.4062,-265.15625 C 1111.6185,-265.4542 1111.5051,-265.8848 1111.5312,-265.90625 C 1111.5742,-265.94148 1111.8716,-266.00028 1112.0312,-266.34375 C 1112.8902,-268.19082 1114.3544,-271.97139 1114.4688,-272.65625 C 1114.5825,-273.33839 1114.6368,-274.00902 1114.6875,-274.40625 C 1114.7169,-274.63575 1114.5404,-275.28515 1114.5625,-275.34375 C 1114.5934,-275.42579 1114.8508,-275.59432 1114.9062,-275.84375 C 1115.1725,-277.04206 1114.9953,-278.05111 1114.7812,-279.46875 C 1114.5673,-280.88638 1113.8096,-284.08338 1113.1562,-284.9375 C 1112.4973,-285.79922 1111.9314,-285.94801 1111.4062,-285.9375 z" | ||
2396 | id="path8089" | ||
2397 | sodipodi:nodetypes="ccssscsssscssssscsssscssssscsssscssssscsssscssssscsssscssssscsssscssscccccssscssssscsssssscssssscsssssscssssscsssssscssssscsssssscssssscsssssscssssscsssssssssssc" /> | ||
2398 | <g | ||
2399 | clip-path="url(#clipPath7421)" | ||
2400 | id="g8091"> | ||
2401 | <path | ||
2402 | id="path8093" | ||
2403 | d="M 1107.409,-284.04961 C 1106.9903,-283.83678 1107.2534,-283.95572 1106.7618,-283.7438 C 1106.2757,-283.53426 1105.0384,-283.16941 1102.6822,-282.28485 C 1099.3511,-281.03428 1096.852,-280.13141 1095.6563,-279.21875 C 1094.1202,-279.19749 1091.9358,-278.98544 1090,-278.5 C 1087.0185,-277.75234 1085.1448,-277.32599 1083.25,-276.90625 C 1081.3552,-276.48653 1081.5745,-276.26406 1080.375,-276.03125 C 1079.0784,-275.77959 1078.6536,-276.04024 1074.9375,-275.25 C 1071.4476,-274.50786 1066.0427,-273.31893 1064.7813,-272.5625 C 1063.1974,-272.74329 1060.9138,-272.88428 1058.9375,-272.59375 C 1055.8971,-272.1468 1054.0213,-271.92099 1052.0938,-271.6875 C 1051.4384,-271.60813 1051.0527,-271.48672 1050.75,-271.40625 C 1050.3238,-271.2746 1050.0642,-271.14623 1049.375,-271.0625 C 1048.0634,-270.90314 1047.6128,-271.21933 1043.8438,-270.78125 C 1040.2899,-270.36817 1034.8384,-269.50843 1033.5938,-268.84375 C 1031.9948,-269.14105 1029.736,-269.37794 1027.75,-269.1875 C 1024.6912,-268.89419 1022.778,-268.70351 1020.8438,-268.53125 C 1018.9095,-268.35899 1019.1551,-268.10888 1017.9375,-268 C 1016.6213,-267.88231 1016.1777,-268.16363 1012.4063,-267.75 C 1008.8644,-267.36156 1003.3984,-266.54073 1002.125,-265.875 C 1000.5261,-266.1697 998.23783,-266.38201 996.25,-266.1875 C 993.19176,-265.88826 991.30887,-265.70726 989.375,-265.53125 C 988.71751,-265.47141 988.33496,-265.35269 988.03125,-265.28125 C 987.6036,-265.1623 987.34774,-265.06318 986.65625,-265 C 985.34029,-264.87975 984.89649,-265.19488 981.125,-264.78125 C 977.56886,-264.39124 972.11946,-263.54209 970.875,-262.875 C 969.27637,-263.16919 967.01516,-263.39872 965.03125,-263.1875 C 961.97565,-262.86218 960.05721,-262.66126 958.125,-262.46875 C 956.19279,-262.27625 956.43513,-262.02787 955.21875,-261.90625 C 953.90387,-261.77479 953.45577,-262.07079 949.6875,-261.625 C 946.14863,-261.20635 940.70982,-260.33283 939.4375,-259.65625 C 937.83995,-259.9373 935.57754,-260.07668 933.59375,-259.84375 C 930.54177,-259.48539 928.64867,-259.27589 926.71875,-259.0625 C 926.06255,-258.98995 925.67809,-258.88981 925.375,-258.8125 C 924.94823,-258.68528 924.69009,-258.5453 924,-258.46875 C 922.68667,-258.32307 922.23254,-258.64277 918.46875,-258.15625 C 914.91986,-257.6975 909.49012,-256.73723 908.25,-256.03125 C 906.65695,-256.27549 904.41619,-256.4126 902.4375,-256.15625 C 899.38991,-255.76144 897.48679,-255.5078 895.5625,-255.25 C 893.63822,-254.99221 893.83639,-254.75647 892.625,-254.59375 C 891.31554,-254.41785 890.87781,-254.69813 887.125,-254.125 C 883.60071,-253.58676 878.20185,-252.42583 876.9375,-251.6875 C 875.35,-251.89104 873.092,-251.94223 871.125,-251.59375 C 868.09883,-251.05763 866.22611,-250.73206 864.3125,-250.40625 C 863.66189,-250.29548 863.29879,-250.13531 863,-250.03125 C 862.57933,-249.86637 862.33655,-249.69995 861.65625,-249.5625 C 860.3616,-249.30091 859.92913,-249.5687 856.21875,-248.75 C 852.72022,-247.97805 847.3728,-246.36707 846.15625,-245.53125 C 844.59347,-245.6087 842.39867,-245.44597 840.46875,-244.9375 C 837.49631,-244.15437 835.65114,-243.70541 833.78125,-243.1875 C 831.91137,-242.6696 832.11465,-242.42022 830.9375,-242.09375 C 829.66504,-241.74085 829.24047,-241.98666 825.59375,-240.90625 C 822.16905,-239.89162 816.94431,-237.97308 815.71875,-237.0625 C 814.17992,-237.04976 811.99892,-236.79028 810.09375,-236.1875 C 807.16269,-235.26016 805.34344,-234.72908 803.5,-234.125 C 802.87324,-233.91962 802.50827,-233.73242 802.21875,-233.59375 C 801.81112,-233.38014 801.56541,-233.185 800.90625,-232.96875 C 799.65179,-232.55721 799.22014,-232.77971 795.625,-231.53125 C 792.23515,-230.35408 787.03002,-228.31755 785.84375,-227.375 C 784.31986,-227.31533 782.1937,-226.98013 780.3125,-226.3125 C 777.41511,-225.28421 775.61342,-224.63702 773.78125,-224 C 771.94908,-223.36299 772.1534,-223.15146 771,-222.75 C 769.75322,-222.31604 769.33639,-222.55028 765.78125,-221.1875 C 762.44258,-219.9077 757.2941,-217.70495 756.09375,-216.71875 C 754.58657,-216.61106 752.45806,-216.21995 750.59375,-215.5 C 747.72557,-214.3924 745.96995,-213.71844 744.15625,-213.03125 C 743.53959,-212.79762 743.15984,-212.58922 742.875,-212.4375 C 742.875,-212.4375 742.875,-211.34375 742.875,-211.34375 C 742.98678,-211.56611 743.26099,-212.16118 743.78125,-212.4375 C 744.47922,-212.80822 748.59488,-214.43087 750.59375,-215.15625 C 752.25061,-215.7575 754.74764,-216.48493 756.5625,-216.46875 C 756.86412,-216.46606 757.15012,-216.41785 757.40625,-216.375 C 759.24874,-216.06675 764.875,-214.8125 764.875,-214.8125 C 764.87499,-214.8125 758.64151,-216.45925 757.84375,-216.65625 C 757.65296,-216.70336 757.30803,-216.72497 756.875,-216.71875 C 758.02046,-217.58846 761.636,-219.11226 764.21875,-220.15625 C 767.05697,-221.30352 767.33556,-221.40807 769.28125,-221.8125 C 771.28955,-222.22994 772.4375,-222.3125 772.4375,-222.3125 C 772.4375,-222.31249 772.35514,-222.91364 773.40625,-223.4375 C 774.11135,-223.78891 778.29327,-225.3299 780.3125,-226 C 782.2644,-226.64773 785.3699,-227.3585 787.1875,-227 C 789.05073,-226.6325 794.71875,-225.1875 794.71875,-225.1875 C 794.71876,-225.1875 788.43175,-227.05861 787.625,-227.28125 C 787.43208,-227.3345 787.09416,-227.36729 786.65625,-227.375 C 787.81459,-228.20788 791.45069,-229.57032 794.0625,-230.53125 C 796.93266,-231.58726 797.22984,-231.69305 799.1875,-232.0625 C 801.04099,-232.41229 802.04634,-232.48798 802.21875,-232.5 C 802.33235,-232.71724 802.5962,-233.31002 803.125,-233.5625 C 803.83444,-233.90124 808.05107,-235.27525 810.09375,-235.875 C 811.78692,-236.37211 814.33452,-236.91177 816.1875,-236.78125 C 816.49545,-236.75957 816.80099,-236.68399 817.0625,-236.625 C 818.94368,-236.20068 824.65625,-234.59375 824.65625,-234.59375 C 824.65626,-234.59375 818.31451,-236.659 817.5,-236.90625 C 817.30521,-236.96539 816.94212,-237.01019 816.5,-237.03125 C 817.66949,-237.8288 821.36302,-239.08747 824,-239.96875 C 826.89781,-240.93722 827.23301,-240.97207 829.21875,-241.25 C 831.2684,-241.53689 832.40625,-241.5625 832.40625,-241.5625 C 832.40623,-241.5625 832.3335,-242.16947 833.40625,-242.625 C 834.12585,-242.93057 838.39723,-244.12575 840.46875,-244.625 C 842.47119,-245.10758 845.66724,-245.55329 847.53125,-245.03125 C 849.44203,-244.4961 855.25,-242.53125 855.25,-242.53125 C 855.25,-242.53125 848.82734,-244.95476 848,-245.25 C 847.80216,-245.32061 847.41784,-245.39039 846.96875,-245.4375 C 848.15665,-246.16615 851.88402,-247.21158 854.5625,-247.9375 C 857.50592,-248.73525 857.85458,-248.70833 859.875,-248.84375 C 861.78789,-248.97198 862.82205,-248.91484 863,-248.90625 C 863.11728,-249.10991 863.39176,-249.68573 863.9375,-249.875 C 864.66969,-250.12894 869.01602,-250.92289 871.125,-251.25 C 872.87313,-251.52111 875.52588,-251.7347 877.4375,-251.34375 C 877.75516,-251.27879 878.04272,-251.15824 878.3125,-251.0625 C 880.25324,-250.37377 886.15625,-247.96875 886.15625,-247.96875 C 886.15626,-247.96875 879.62154,-250.91952 878.78125,-251.28125 C 878.58028,-251.36776 878.20612,-251.44804 877.75,-251.53125 C 878.9565,-252.16443 882.77956,-252.92685 885.5,-253.4375 C 888.48953,-253.99869 888.80023,-253.96704 890.84375,-253.96875 C 892.95301,-253.97052 894.15625,-253.84375 894.15625,-253.84375 C 894.15625,-253.84374 894.08354,-254.47494 895.1875,-254.78125 C 895.92802,-254.98672 900.31362,-255.61512 902.4375,-255.84375 C 904.49052,-256.06474 907.75613,-256.09597 909.65625,-255.375 C 911.60404,-254.63593 917.5,-252 917.5,-252 C 917.50002,-252 910.93712,-255.17897 910.09375,-255.5625 C 909.89207,-255.65423 909.55154,-255.74871 909.09375,-255.84375 C 910.30467,-256.44563 914.07817,-257.09259 916.8125,-257.5 C 919.8173,-257.94772 920.13801,-257.9517 922.1875,-257.90625 C 924.12795,-257.86323 925.19449,-257.71202 925.375,-257.6875 C 925.49392,-257.88066 925.7589,-258.45333 926.3125,-258.59375 C 927.05521,-258.78213 931.46679,-259.32803 933.59375,-259.53125 C 935.35678,-259.69967 938.01384,-259.76554 939.9375,-259.28125 C 940.25718,-259.20077 940.54101,-259.07766 940.8125,-258.96875 C 942.76543,-258.18526 948.71875,-255.5 948.71875,-255.5 C 948.71873,-255.5 942.12684,-258.75348 941.28125,-259.15625 C 941.07903,-259.25257 940.70899,-259.36328 940.25,-259.46875 C 941.46414,-260.04302 945.29366,-260.59094 948.03125,-260.96875 C 951.03963,-261.38395 951.35432,-261.41138 953.40625,-261.34375 C 955.52423,-261.27394 956.71875,-261.09375 956.71875,-261.09375 C 956.71873,-261.09375 956.6415,-261.73116 957.75,-262 C 958.49362,-262.18035 962.90176,-262.66355 965.03125,-262.84375 C 967.08972,-263.01792 970.37449,-262.96807 972.28125,-262.1875 C 974.23584,-261.38734 980.15625,-258.65625 980.15625,-258.65625 C 980.15623,-258.65625 973.59632,-261.96501 972.75,-262.375 C 972.54763,-262.47305 972.17814,-262.5781 971.71875,-262.6875 C 972.93392,-263.2514 976.72883,-263.8018 979.46875,-264.15625 C 982.47966,-264.54577 982.79006,-264.5539 984.84375,-264.46875 C 986.78814,-264.38815 987.85038,-264.21551 988.03125,-264.1875 C 988.15041,-264.37836 988.41402,-264.93281 988.96875,-265.0625 C 989.71301,-265.2365 994.11868,-265.71297 996.25,-265.875 C 998.01662,-266.00927 1000.6997,-266.00071 1002.625,-265.5 C 1002.945,-265.41679 1003.2283,-265.29873 1003.5,-265.1875 C 1005.4546,-264.38734 1011.4063,-261.625 1011.4063,-261.625 C 1011.4062,-261.625 1004.8151,-264.96501 1003.9688,-265.375 C 1003.7664,-265.47305 1003.3969,-265.57811 1002.9375,-265.6875 C 1004.1526,-266.2514 1007.9788,-266.77056 1010.7188,-267.125 C 1013.7297,-267.51453 1014.0713,-267.5539 1016.125,-267.46875 C 1018.2447,-267.38087 1019.4375,-267.15625 1019.4375,-267.15625 C 1019.4375,-267.15625 1019.3591,-267.80527 1020.4688,-268.0625 C 1021.2131,-268.23506 1025.6183,-268.68586 1027.75,-268.84375 C 1029.8106,-268.99635 1033.0929,-268.94052 1035,-268.15625 C 1036.955,-267.3523 1042.875,-264.65625 1042.875,-264.65625 C 1042.875,-264.65625 1036.3152,-267.93212 1035.4688,-268.34375 C 1035.2663,-268.44219 1034.897,-268.54597 1034.4375,-268.65625 C 1035.6529,-269.21779 1039.4494,-269.78403 1042.1875,-270.15625 C 1045.1965,-270.5653 1045.5102,-270.57183 1047.5625,-270.5 C 1049.5056,-270.43201 1050.5697,-270.33515 1050.75,-270.3125 C 1050.8688,-270.5069 1051.1346,-271.04131 1051.6875,-271.1875 C 1052.4293,-271.38362 1056.8186,-272.01628 1058.9375,-272.28125 C 1060.6939,-272.50086 1063.3428,-272.61356 1065.25,-272.25 C 1065.5669,-272.18959 1065.8558,-272.06062 1066.125,-271.96875 C 1068.0612,-271.30783 1073.9688,-269.03125 1073.9688,-269.03125 C 1073.9687,-269.03125 1067.4321,-271.8378 1066.5938,-272.1875 C 1066.3933,-272.27113 1066.0176,-272.36083 1065.5625,-272.4375 C 1066.7662,-273.08796 1070.5816,-273.80945 1073.2813,-274.4375 C 1076.248,-275.1277 1076.5702,-275.19257 1078.5938,-275.3125 C 1080.6824,-275.4363 1081.875,-275.34375 1081.875,-275.34375 C 1081.875,-275.34374 1081.788,-275.9758 1082.875,-276.375 C 1083.6042,-276.6428 1087.9222,-277.71297 1090,-278.1875 C 1092.0085,-278.64619 1095.1679,-279.2168 1097,-278.8125 C 1098.8781,-278.39804 1110.5782,-275.79687 1110.5782,-275.79687 C 1110.5782,-275.79687 1098.2507,-278.81953 1097.4375,-279.0625 C 1097.243,-279.12062 1096.8789,-279.16876 1096.4375,-279.1875 C 1097.6051,-279.99119 1099.9517,-280.8748 1102.5469,-281.89062 C 1104.2283,-282.5488 1103.4706,-282.26721 1105.3228,-282.89422 C 1107.0764,-283.48788 1107.8082,-283.90493 1107.9532,-284.00721 C 1108.2993,-284.21372 1107.5972,-284.12909 1107.409,-284.04961 z" | ||
2404 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7001);enable-background:new" | ||
2405 | sodipodi:nodetypes="czscsssscssssscsssscssssscsssscssssscsssscssssscsssscssssscsssscssccsssscscsscssscscsscsssscscsscssscscsscsssscscsscssscscsscsssscscsscssscscsscsssscscsscssscscsscsssscscsscssscscsscc" /> | ||
2406 | <path | ||
2407 | id="path8095" | ||
2408 | d="M 1082.625,-275.125 C 1084.498,-274.73152 1087.1211,-273.97945 1088.6563,-273.15625 C 1090.1915,-272.33306 1091.4785,-272.10025 1094.0313,-270.65625 C 1096.5579,-269.22699 1098.8271,-268.64929 1101,-268.125 C 1103.3476,-267.55858 1106.4354,-267.40977 1109.8438,-266.9375 C 1108.7549,-267.77725 1103.2364,-268.10995 1101.4375,-268.5 C 1099.6386,-268.89006 1097.5434,-269.51616 1094.8438,-270.8125 C 1092.1441,-272.10884 1091.3494,-272.61146 1089.0313,-273.5 C 1086.7131,-274.38854 1085.0269,-274.88314 1082.625,-275.125 z" | ||
2409 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6949);enable-background:new" /> | ||
2410 | <path | ||
2411 | id="path8097" | ||
2412 | d="M 1051.4688,-270 C 1053.3741,-269.42241 1055.9969,-268.38428 1057.5625,-267.40625 C 1059.1281,-266.42823 1060.4427,-266.04644 1063.0625,-264.28125 C 1065.6555,-262.53409 1068.0484,-261.57198 1070.3125,-260.6875 C 1072.7586,-259.73193 1075.9951,-259.03037 1079.7188,-257.625 C 1078.5292,-258.76284 1072.6557,-260.31175 1070.7813,-261 C 1068.9068,-261.68825 1066.6995,-262.5662 1063.9063,-264.28125 C 1061.113,-265.99629 1060.3327,-266.56515 1057.9688,-267.6875 C 1055.6047,-268.80984 1053.9121,-269.52205 1051.4688,-270 z" | ||
2413 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6961);enable-background:new" /> | ||
2414 | <path | ||
2415 | id="path8099" | ||
2416 | d="M 1020.2188,-266.84375 C 1022.1307,-266.20564 1024.8,-265.08839 1026.375,-264.03125 C 1027.9501,-262.9741 1029.2706,-262.52258 1031.9063,-260.625 C 1034.5149,-258.74679 1036.9347,-257.59497 1039.2188,-256.5625 C 1041.6865,-255.44705 1044.9833,-254.3892 1048.75,-252.71875 C 1047.5467,-253.94128 1041.5472,-256.03298 1039.6563,-256.84375 C 1037.7653,-257.65452 1035.5914,-258.73754 1032.7813,-260.59375 C 1029.9711,-262.44995 1029.1595,-263.07068 1026.7813,-264.3125 C 1024.403,-265.5543 1022.6706,-266.28819 1020.2188,-266.84375 z" | ||
2417 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6957);enable-background:new" /> | ||
2418 | <path | ||
2419 | id="path8101" | ||
2420 | d="M 1110.1719,-266.89063 C 1110.3227,-266.84207 1110.8599,-266.25963 1110.2813,-265.40625 C 1109.4712,-264.21166 1104.5764,-262.08196 1101.7188,-261.28125 C 1098.8739,-260.48413 1095.4287,-260.30351 1091.1563,-261.65625 C 1086.8547,-263.0182 1085.6866,-264.12497 1080.5,-265.96875 C 1085.164,-263.85358 1086.6953,-262.01642 1090.625,-260.625 C 1092.2457,-260.05113 1093.9921,-259.6854 1095.6875,-259.59375 C 1095.2424,-259.26812 1094.1572,-258.61045 1092.125,-258 C 1089.3295,-257.16031 1085.4759,-256.46622 1083.875,-256.375 C 1082.3604,-256.28868 1080.733,-256.88749 1080.4375,-257 C 1080.6042,-256.89692 1080.8107,-256.62266 1080.1875,-255.96875 C 1079.2882,-255.02512 1074.0401,-254.04575 1071.0625,-253.71875 C 1068.0982,-253.3932 1064.5409,-253.73471 1060.1563,-255.625 C 1056.1783,-257.33997 1054.8173,-258.54036 1050.75,-260.375 C 1050.75,-260.375 1050.75,-260.21875 1050.75,-260.21875 C 1054.3931,-258.12346 1056.034,-256.33548 1059.625,-254.65625 C 1061.3552,-253.84716 1063.2167,-253.24749 1065.0313,-252.9375 C 1064.4964,-252.65074 1063.4735,-252.22599 1061.5938,-251.90625 C 1058.7248,-251.41829 1054.7848,-251.09011 1053.1563,-251.15625 C 1052.3056,-251.19079 1051.4277,-251.34062 1050.75,-251.5625 C 1050.0652,-251.77738 1049.5603,-252.00717 1049.4375,-252.0625 C 1049.6069,-251.95529 1049.8686,-251.65962 1049.2188,-251.03125 C 1048.3091,-250.15163 1042.9727,-249.69487 1039.9688,-249.5625 C 1036.9783,-249.43071 1033.3799,-250.01313 1028.9688,-252.125 C 1024.5276,-254.25126 1023.3273,-255.5266 1018.0625,-257.90625 C 1022.7968,-255.30921 1024.349,-253.27715 1028.4063,-251.1875 C 1030.0796,-250.32565 1031.8915,-249.69325 1033.6563,-249.25 C 1033.193,-249.01668 1032.0669,-248.56186 1029.9688,-248.3125 C 1027.0825,-247.96952 1023.1342,-247.81962 1021.5,-247.9375 C 1019.9538,-248.049 1018.2688,-248.79446 1017.9688,-248.9375 C 1018.1379,-248.81721 1018.3826,-248.52702 1017.75,-247.9375 C 1016.8372,-247.08677 1011.5059,-246.67538 1008.5,-246.5625 C 1005.5075,-246.45013 1001.9103,-247.05293 997.5,-249.15625 C 993.49875,-251.06448 992.11197,-252.29408 988.03125,-254.25 C 988.03122,-254.25 988.03125,-254.09375 988.03125,-254.09375 C 991.68631,-251.88983 993.32546,-250.0412 996.9375,-248.1875 C 998.67779,-247.29435 1000.5745,-246.65923 1002.4063,-246.21875 C 1001.8663,-245.97045 1000.8282,-245.60342 998.9375,-245.375 C 996.05182,-245.02642 992.07145,-244.85405 990.4375,-244.96875 C 989.58405,-245.02865 988.71119,-245.22666 988.03125,-245.46875 C 987.34415,-245.70405 986.8419,-245.94101 986.71875,-246 C 986.88873,-245.88773 987.18323,-245.57775 986.53125,-244.96875 C 985.6186,-244.11625 980.25592,-243.67538 977.25,-243.5625 C 974.25754,-243.45013 970.65654,-244.09055 966.25,-246.15625 C 961.81347,-248.23603 960.60312,-249.48796 955.34375,-251.8125 C 960.07313,-249.26501 961.63449,-247.2347 965.6875,-245.1875 C 967.35905,-244.34317 969.17304,-243.72107 970.9375,-243.28125 C 970.47427,-243.04703 969.3478,-242.59718 967.25,-242.34375 C 964.36431,-241.99517 960.4138,-241.77423 958.78125,-241.875 C 957.23669,-241.97032 955.58094,-242.70385 955.28125,-242.84375 C 955.45024,-242.72522 955.66317,-242.4399 955.03125,-241.84375 C 954.11939,-240.98347 948.7846,-240.5135 945.78125,-240.375 C 942.7913,-240.2371 939.2138,-240.82568 934.8125,-242.84375 C 930.81942,-244.67464 929.44739,-245.87295 925.375,-247.75 C 925.37498,-247.75 925.375,-247.59375 925.375,-247.59375 C 929.02261,-245.46048 930.64533,-243.65888 934.25,-241.875 C 935.98675,-241.01549 937.85727,-240.42486 939.6875,-240 C 939.14803,-239.7471 938.13687,-239.35871 936.25,-239.09375 C 933.37022,-238.68939 929.41187,-238.44813 927.78125,-238.53125 C 926.92953,-238.57466 926.05355,-238.7398 925.375,-238.96875 C 924.68931,-239.19076 924.1854,-239.41214 924.0625,-239.46875 C 924.23209,-239.35976 924.4944,-239.0591 923.84375,-238.4375 C 922.93296,-237.56736 917.59354,-237.04598 914.59375,-236.875 C 911.60742,-236.70479 908.01994,-237.19077 903.625,-239.15625 C 899.20011,-241.13513 898.01904,-242.38444 892.78125,-244.53125 C 897.49122,-242.14358 899.05142,-240.14252 903.09375,-238.1875 C 904.7609,-237.38119 906.55418,-236.79092 908.3125,-236.40625 C 907.85087,-236.15755 906.7155,-235.694 904.625,-235.375 C 901.7494,-234.93624 897.8446,-234.6419 896.21875,-234.6875 C 894.68052,-234.73062 892.98595,-235.43272 892.6875,-235.5625 C 892.85583,-235.44968 893.09807,-235.14875 892.46875,-234.53125 C 891.56063,-233.64015 886.2658,-233.003 883.28125,-232.71875 C 880.31007,-232.43577 876.70783,-232.89455 872.34375,-234.65625 C 868.38441,-236.25456 867.0146,-237.45112 863,-238.96875 C 863.00003,-238.96875 863,-238.8125 863,-238.8125 C 866.5959,-237.00115 868.23831,-235.23017 871.8125,-233.65625 C 873.53457,-232.8979 875.39998,-232.3673 877.21875,-232.03125 C 876.68266,-231.75217 875.65217,-231.34362 873.78125,-230.96875 C 870.92586,-230.39665 866.99183,-229.94936 865.375,-229.9375 C 864.53049,-229.93129 863.66892,-230.01844 863,-230.1875 C 862.32409,-230.34901 861.83991,-230.51673 861.71875,-230.5625 C 861.88597,-230.46848 862.14142,-230.17902 861.5,-229.5 C 860.60213,-228.54948 855.31352,-227.58292 852.375,-227.0625 C 849.44966,-226.54441 845.94285,-226.68826 841.65625,-228.09375 C 837.34045,-229.50882 836.18348,-230.62369 831.09375,-232.0625 C 835.6706,-230.31149 837.1823,-228.50244 841.125,-227.0625 C 842.75108,-226.46861 844.49385,-226.10685 846.21875,-225.90625 C 845.7659,-225.60923 844.66397,-225.02286 842.625,-224.4375 C 839.82028,-223.63233 835.98614,-222.86167 834.40625,-222.6875 C 832.9115,-222.5227 831.29002,-223.00431 831,-223.09375 C 831.16356,-223.00368 831.39278,-222.73382 830.78125,-222.03125 C 829.89878,-221.0174 824.73673,-219.6596 821.84375,-218.96875 C 818.96373,-218.28097 815.50815,-218.20873 811.28125,-219.40625 C 807.4464,-220.4927 806.10867,-221.47862 802.21875,-222.53125 C 802.21874,-222.53125 802.21875,-222.375 802.21875,-222.375 C 805.70293,-220.98015 807.28816,-219.4556 810.75,-218.34375 C 812.41793,-217.80803 814.20578,-217.55701 815.96875,-217.46875 C 815.44911,-217.11663 814.46836,-216.55423 812.65625,-215.9375 C 809.89059,-214.99625 806.06601,-214.00213 804.5,-213.78125 C 803.68206,-213.66586 802.8669,-213.65842 802.21875,-213.75 C 801.56379,-213.83321 801.08615,-213.96827 800.96875,-214 C 801.13079,-213.92536 801.40274,-213.65956 800.78125,-212.90625 C 799.91125,-211.85172 794.77162,-210.247 791.90625,-209.46875 C 789.05372,-208.69399 785.64713,-208.51055 781.46875,-209.5625 C 777.26192,-210.62163 776.11206,-211.60416 771.125,-212.71875 C 775.60954,-211.25929 777.09435,-209.58352 780.9375,-208.46875 C 782.52254,-208.00898 784.22429,-207.8305 785.90625,-207.78125 C 785.46468,-207.44449 784.39374,-206.75352 782.40625,-206 C 779.67232,-204.96351 775.95427,-203.83731 774.40625,-203.5625 C 772.94163,-203.30248 771.34667,-203.67904 771.0625,-203.75 C 771.22275,-203.67035 771.44294,-203.42902 770.84375,-202.6875 C 769.97909,-201.61744 764.92723,-199.86935 762.09375,-199 C 759.27295,-198.13453 755.88625,-197.84369 751.75,-198.78125 C 747.99741,-199.63186 746.70215,-200.49772 742.875,-201.375 C 742.875,-201.375 742.875,-201.21875 742.875,-201.21875 C 746.30296,-199.98096 747.86241,-198.58645 751.25,-197.6875 C 752.88216,-197.25436 754.61704,-197.10449 756.34375,-197.125 C 755.83482,-196.74083 754.867,-196.10318 753.09375,-195.375 C 750.38741,-194.26366 746.65742,-193.06719 745.125,-192.75 C 744.3246,-192.58431 743.51269,-192.53138 742.875,-192.59375 C 742.875,-192.59375 742.875,-192.07823 742.875,-191.67146 C 742.875,-191.40639 742.875,-191.1875 742.875,-191.1875 C 743.10145,-191.33218 743.32391,-191.46011 743.59375,-191.5625 C 744.67427,-191.97248 745.76536,-191.77827 749.59375,-193.25 C 753.42218,-194.72174 754.81787,-195.25498 755.5,-195.65625 C 756.1796,-196.05603 757.11165,-196.53562 757.71875,-197.1875 C 759.5456,-197.32525 761.2895,-197.68073 762.65625,-198.1875 C 765.62437,-199.28802 767.53162,-199.99369 769.4375,-200.65625 C 771.34336,-201.31879 771.79159,-202.07112 772.84375,-202.4375 C 773.9353,-202.81761 775.03886,-202.60288 778.90625,-203.96875 C 782.7737,-205.33461 784.18941,-205.79583 784.875,-206.1875 C 785.57609,-206.58802 786.57581,-207.12048 787.1875,-207.78125 C 789.1583,-207.83591 791.00435,-208.16588 792.46875,-208.65625 C 795.47023,-209.66133 797.3949,-210.27796 799.3125,-210.90625 C 800.8511,-211.41035 801.48652,-211.95302 802.21875,-212.34375 C 802.44891,-212.47806 802.69449,-212.59748 802.96875,-212.6875 C 804.06698,-213.04798 805.1502,-212.76887 809.0625,-214 C 812.97483,-215.23113 814.42855,-215.67295 815.125,-216.03125 C 815.81888,-216.38822 816.75515,-216.82386 817.375,-217.4375 C 819.24021,-217.46016 821.01081,-217.70433 822.40625,-218.125 C 825.43668,-219.03854 827.39863,-219.5551 829.34375,-220.09375 C 831.28886,-220.63239 831.76993,-221.35827 832.84375,-221.65625 C 833.95776,-221.9654 835.06369,-221.64886 839.03125,-222.6875 C 842.99886,-223.72613 844.44883,-224.12023 845.15625,-224.4375 C 845.89112,-224.76709 846.97008,-225.19122 847.59375,-225.8125 C 849.59149,-225.6965 851.45118,-225.83259 852.9375,-226.1875 C 856.01561,-226.9225 858.02094,-227.28844 860,-227.6875 C 861.58792,-228.00768 862.24429,-228.47805 863,-228.78125 C 863.23757,-228.88805 863.46695,-228.97401 863.75,-229.03125 C 864.88347,-229.26044 866.05448,-228.82232 870.09375,-229.53125 C 874.13308,-230.24018 875.594,-230.45834 876.3125,-230.71875 C 877.02836,-230.97819 878.01678,-231.28599 878.65625,-231.8125 C 880.58052,-231.57301 882.40413,-231.58797 883.84375,-231.8125 C 886.97008,-232.30012 888.9983,-232.51317 891,-232.78125 C 893.00171,-233.04932 893.48869,-233.72639 894.59375,-233.875 C 895.74014,-234.02918 896.86967,-233.57343 900.9375,-234.09375 C 905.00534,-234.61407 906.49763,-234.78948 907.21875,-235.03125 C 907.95585,-235.27839 909.01684,-235.61748 909.65625,-236.15625 C 911.70632,-235.82072 913.63003,-235.75829 915.15625,-235.9375 C 918.29856,-236.30646 920.33619,-236.49686 922.34375,-236.71875 C 923.95451,-236.89677 924.60842,-237.32695 925.375,-237.5625 C 925.61594,-237.64802 925.86912,-237.7181 926.15625,-237.75 C 927.30603,-237.87772 928.45754,-237.40335 932.53125,-237.875 C 936.60499,-238.34665 938.09034,-238.4856 938.8125,-238.71875 C 939.53196,-238.95102 940.51274,-239.19221 941.15625,-239.6875 C 943.09262,-239.35404 944.92631,-239.28326 946.375,-239.4375 C 949.52102,-239.77245 951.55256,-239.95609 953.5625,-240.15625 C 955.57246,-240.35639 956.04664,-240.98264 957.15625,-241.09375 C 958.30739,-241.20903 959.45268,-240.72869 963.53125,-241.15625 C 967.60986,-241.58381 969.12011,-241.71834 969.84375,-241.9375 C 970.5829,-242.16136 971.63947,-242.45075 972.28125,-242.96875 C 974.33835,-242.57008 976.28312,-242.47535 977.8125,-242.625 C 980.96123,-242.9331 982.98834,-243.09825 985,-243.28125 C 986.61407,-243.42807 987.2631,-243.8418 988.03125,-244.0625 C 988.27267,-244.14336 988.52478,-244.19241 988.8125,-244.21875 C 989.96461,-244.3242 991.10546,-243.826 995.1875,-244.21875 C 999.26958,-244.6115 1000.7764,-244.74959 1001.5,-244.96875 C 1002.2209,-245.18708 1003.1997,-245.41645 1003.8438,-245.90625 C 1005.7818,-245.55626 1007.6126,-245.45187 1009.0625,-245.59375 C 1012.2112,-245.90185 1014.2383,-246.067 1016.25,-246.25 C 1018.2616,-246.43299 1018.7642,-247.08802 1019.875,-247.1875 C 1021.0273,-247.29073 1022.1672,-246.80267 1026.25,-247.1875 C 1030.3329,-247.57232 1031.8387,-247.6885 1032.5625,-247.90625 C 1033.3018,-248.12868 1034.3581,-248.42074 1035,-248.9375 C 1037.0574,-248.53573 1039.0029,-248.43417 1040.5313,-248.59375 C 1043.6779,-248.92227 1045.7084,-249.11645 1047.7188,-249.3125 C 1049.3318,-249.46979 1049.9844,-249.94398 1050.75,-250.1875 C 1050.9907,-250.27554 1051.2132,-250.30887 1051.5,-250.34375 C 1052.6483,-250.48345 1053.8167,-250.00384 1057.875,-250.59375 C 1061.9333,-251.18367 1063.4368,-251.37089 1064.1563,-251.625 C 1064.873,-251.87816 1065.8308,-252.18307 1066.4688,-252.71875 C 1068.3885,-252.50681 1070.1887,-252.56734 1071.625,-252.8125 C 1074.7441,-253.3449 1076.7366,-253.74111 1078.7188,-254.125 C 1080.7009,-254.50887 1081.1931,-255.16465 1082.2813,-255.40625 C 1083.4101,-255.65691 1084.5516,-255.28996 1088.5313,-256.28125 C 1092.5109,-257.27253 1093.9609,-257.70055 1094.6563,-258.0625 C 1095.3786,-258.43851 1096.4182,-258.93308 1097.0313,-259.59375 C 1098.9943,-259.6058 1100.825,-259.8848 1102.25,-260.4375 C 1105.2012,-261.58211 1107.1232,-262.30692 1108.9375,-263.1875 C 1110.3932,-263.89403 1111.2723,-264.87391 1111.4844,-265.17188 C 1111.6966,-265.46984 1111.5962,-265.91718 1111.6223,-265.93863 C 1111.6652,-265.97387 1111.9416,-266.0236 1112.1013,-266.36707 C 1112.9602,-268.21415 1114.4223,-272.01166 1114.5365,-272.69652 C 1114.6502,-273.37868 1114.7003,-274.04426 1114.751,-274.44149 C 1114.7804,-274.67101 1114.6043,-275.30693 1114.6264,-275.36553 C 1114.6573,-275.44759 1114.9309,-275.63081 1114.9863,-275.88024 C 1115.2526,-277.07857 1115.0752,-278.07153 1114.8612,-279.48917 C 1114.6472,-280.90681 1113.8775,-284.11131 1113.2243,-284.96543 C 1112.5654,-285.82715 1112.0014,-285.9766 1111.4764,-285.96609 C 1111.2678,-285.69633 1111.6132,-285.703 1111.639,-285.65348 C 1112.3196,-285.60269 1112.573,-285.28484 1113.0582,-284.75686 C 1113.5434,-284.22888 1114.501,-280.8173 1114.6376,-279.36691 C 1114.7742,-277.91652 1114.8276,-276.50671 1114.5496,-275.89827 C 1114.2715,-275.28982 1113.6054,-275.46963 1113.313,-275.40375 C 1113.844,-275.21786 1114.2038,-275.19053 1114.2654,-274.34607 C 1114.3247,-273.53269 1114.1322,-272.70638 1113.7456,-271.54045 C 1113.3544,-270.36044 1111.9004,-267.19047 1111.4599,-266.94168 C 1111.0076,-266.68617 1110.5075,-266.75969 1110.1719,-266.89063 z" | ||
2421 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6997);enable-background:new" | ||
2422 | sodipodi:nodetypes="cssscscsscsssccscssssssscscsscsssscscssssssscscsscsssscscssssssscscsscsssscscssssssscscsscsssscscssssssscscsscsssccscsscscssscssssscsssssscssssscsssssscssssscsssssscssssscsssssscssssscsssssscssssscsszsszssszzcczzzczzzc" /> | ||
2423 | <path | ||
2424 | id="path8103" | ||
2425 | d="M 988.75,-263.84375 C 990.66161,-263.20935 993.30027,-262.08534 994.875,-261.03125 C 996.44977,-259.97716 997.7711,-259.54873 1000.4063,-257.65625 C 1003.0145,-255.78311 1005.4332,-254.64103 1007.7188,-253.59375 C 1010.1881,-252.46228 1013.4709,-251.43901 1017.25,-249.65625 C 1016.0428,-250.91465 1010.111,-253.0207 1008.2188,-253.84375 C 1006.3266,-254.66679 1004.0908,-255.77424 1001.2813,-257.625 C 998.47169,-259.47575 997.65906,-260.10654 995.28125,-261.34375 C 992.90343,-262.58094 991.20137,-263.29295 988.75,-263.84375 z" | ||
2426 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6953);enable-background:new" /> | ||
2427 | <path | ||
2428 | id="path8105" | ||
2429 | d="M 957.5,-260.78125 C 959.41,-260.16315 962.08288,-259.07191 963.65625,-258.03125 C 965.22964,-256.99059 966.55233,-256.54873 969.1875,-254.65625 C 971.79573,-252.7831 974.21442,-251.64104 976.5,-250.59375 C 978.96931,-249.46228 982.25213,-248.439 986.03125,-246.65625 C 984.82397,-247.91465 978.82971,-250.05195 976.9375,-250.875 C 975.04533,-251.69804 972.84084,-252.8055 970.03125,-254.65625 C 967.22167,-256.507 966.4383,-257.09557 964.0625,-258.3125 C 961.68672,-259.52941 959.94929,-260.25135 957.5,-260.78125 z" | ||
2430 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6993);enable-background:new" /> | ||
2431 | <path | ||
2432 | id="path8107" | ||
2433 | d="M 926.09375,-257.375 C 928.00147,-256.77755 930.64723,-255.71116 932.21875,-254.6875 C 933.79025,-253.66385 935.08897,-253.24779 937.71875,-251.40625 C 940.32166,-249.58352 942.74762,-248.43405 945.03125,-247.40625 C 947.49845,-246.29584 950.7866,-245.31302 954.5625,-243.5625 C 953.35627,-244.8106 947.3906,-246.88059 945.5,-247.6875 C 943.60942,-248.4944 941.39758,-249.57854 938.59375,-251.375 C 935.7899,-253.17144 934.96671,-253.77751 932.59375,-254.96875 C 930.22078,-256.15999 928.54013,-256.87158 926.09375,-257.375 z" | ||
2434 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6989);enable-background:new" /> | ||
2435 | <path | ||
2436 | id="path8109" | ||
2437 | d="M 894.90625,-253.5625 C 896.80838,-253.00895 899.49326,-251.97363 901.0625,-250.96875 C 902.63173,-249.96388 903.93651,-249.56011 906.5625,-247.75 C 909.16162,-245.95836 911.56284,-244.87811 913.84375,-243.875 C 916.30803,-242.79126 919.60359,-241.83471 923.375,-240.125 C 922.1702,-241.36007 916.20084,-243.36978 914.3125,-244.15625 C 912.42418,-244.94272 910.2373,-245.98705 907.4375,-247.75 C 904.63773,-249.51294 903.83831,-250.11836 901.46875,-251.28125 C 899.09918,-252.44413 897.3455,-253.11537 894.90625,-253.5625 z" | ||
2438 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6985);enable-background:new" /> | ||
2439 | <path | ||
2440 | id="path8111" | ||
2441 | d="M 863.71875,-248.65625 C 865.59937,-248.22716 868.22302,-247.27587 869.78125,-246.34375 C 871.33948,-245.41164 872.63358,-245.08599 875.25,-243.34375 C 877.83971,-241.61931 880.23067,-240.63573 882.5,-239.71875 C 884.95176,-238.72806 888.23959,-237.84168 892,-236.21875 C 890.79869,-237.42609 884.84751,-239.28484 882.96875,-240 C 881.09,-240.71517 878.88335,-241.68442 876.09375,-243.375 C 873.30412,-245.06557 872.50914,-245.60322 870.15625,-246.65625 C 867.80333,-247.70926 866.13041,-248.36873 863.71875,-248.65625 z" | ||
2442 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6965);enable-background:new" /> | ||
2443 | <path | ||
2444 | id="path8113" | ||
2445 | d="M 833.15625,-241.375 C 835.00461,-241.07856 837.6257,-240.39868 839.15625,-239.59375 C 840.68683,-238.78882 841.96999,-238.53802 844.53125,-237.0625 C 847.06629,-235.60204 849.42193,-234.73741 851.65625,-234 C 854.07024,-233.20332 857.31336,-232.53311 861.03125,-231.15625 C 859.84354,-232.28498 853.94353,-233.746 852.09375,-234.3125 C 850.24398,-234.879 848.09033,-235.68642 845.34375,-237.15625 C 842.59718,-238.62608 841.84239,-239.07653 839.53125,-239.9375 C 837.2201,-240.79845 835.52654,-241.25759 833.15625,-241.375 z" | ||
2446 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6981);enable-background:new" /> | ||
2447 | <path | ||
2448 | id="path8115" | ||
2449 | d="M 802.90625,-232.3125 C 804.72845,-232.10123 807.27201,-231.51193 808.78125,-230.78125 C 810.2905,-230.05059 811.53693,-229.85127 814.0625,-228.5 C 816.56226,-227.16254 818.89404,-226.45157 821.09375,-225.84375 C 823.47028,-225.18708 826.65839,-224.77087 830.3125,-223.65625 C 829.14515,-224.70121 823.38362,-225.75954 821.5625,-226.21875 C 819.74139,-226.67796 817.61025,-227.34571 814.90625,-228.65625 C 812.20222,-229.96677 811.43519,-230.37615 809.15625,-231.125 C 806.8773,-231.87383 805.243,-232.30431 802.90625,-232.3125 z" | ||
2450 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6977);enable-background:new" /> | ||
2451 | <path | ||
2452 | id="path8117" | ||
2453 | d="M 773.1875,-222.1875 C 774.99859,-222.0088 777.50809,-221.52244 779,-220.84375 C 780.49194,-220.16506 781.7534,-220.04553 784.25,-218.78125 C 786.72107,-217.52987 789.04005,-216.88511 791.21875,-216.34375 C 793.57262,-215.75887 796.71009,-215.44623 800.3125,-214.5 C 799.16166,-215.49116 793.45999,-216.2833 791.65625,-216.6875 C 789.85253,-217.0917 787.74072,-217.70866 785.0625,-218.9375 C 782.38432,-220.16634 781.65905,-220.54839 779.40625,-221.21875 C 777.15346,-221.88909 775.50998,-222.22107 773.1875,-222.1875 z" | ||
2454 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6973);enable-background:new" /> | ||
2455 | <path | ||
2456 | id="path8119" | ||
2457 | d="M 743.5625,-211.1875 C 745.35531,-211.05839 747.83563,-210.63785 749.3125,-210 C 750.7894,-209.36215 752.0286,-209.25844 754.5,-208.0625 C 756.94618,-206.87878 759.22054,-206.31584 761.375,-205.84375 C 763.70267,-205.33372 766.7946,-205.16311 770.375,-204.28125 C 769.23121,-205.25185 763.62741,-205.8719 761.84375,-206.21875 C 760.06008,-206.56559 757.9609,-207.10631 755.3125,-208.25 C 752.66409,-209.39368 751.91755,-209.76631 749.6875,-210.375 C 747.45742,-210.98368 745.86156,-211.28466 743.5625,-211.1875 z" | ||
2458 | style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter6969);enable-background:new" /> | ||
2459 | <g | ||
2460 | id="g8121" | ||
2461 | style="fill:#ffffff;fill-opacity:1;filter:url(#filter7345)"> | ||
2462 | <path | ||
2463 | sodipodi:nodetypes="czzzczzc" | ||
2464 | id="path8123" | ||
2465 | d="M 744.9375,-212.11731 C 744.9375,-212.11731 752.15979,-215.34049 754,-215.61731 C 755.84021,-215.89413 757.35225,-215.62054 760,-215.05481 C 762.64775,-214.48908 768.7357,-212.83963 771.1875,-211.67981 C 773.6393,-210.51999 776.5,-208.11731 776.5,-208.11731 C 776.5,-208.11731 769.35356,-210.8975 766.3125,-211.67981 C 763.27144,-212.46212 758.66789,-213.76355 755.9375,-213.99231 C 753.20711,-214.22107 744.9375,-212.11731 744.9375,-212.11731 z" | ||
2466 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /> | ||
2467 | <path | ||
2468 | sodipodi:nodetypes="czzzczzc" | ||
2469 | id="path8125" | ||
2470 | d="M 735.46875,-206.95416 C 735.46875,-206.95416 739.12854,-209.17734 740.96875,-209.45416 C 742.80896,-209.73098 744.6335,-209.20739 747.28125,-208.64166 C 749.929,-208.07593 756.01695,-206.42648 758.46875,-205.26666 C 760.92055,-204.10684 765.03125,-203.14166 765.03125,-203.14166 C 765.03125,-203.14166 756.63481,-204.48435 753.59375,-205.26666 C 750.55269,-206.04897 745.63664,-207.6004 742.90625,-207.82916 C 740.17586,-208.05792 735.46875,-206.95416 735.46875,-206.95416 z" | ||
2471 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2472 | <path | ||
2473 | sodipodi:nodetypes="czzzczzc" | ||
2474 | id="path8127" | ||
2475 | d="M 759.85042,-217.61116 C 759.85042,-217.61116 768.39412,-220.90973 770.2482,-221.06902 C 772.10229,-221.22832 773.88986,-220.58982 776.4963,-219.85694 C 779.10274,-219.12406 785.07354,-217.091 787.44666,-215.77769 C 789.81978,-214.46438 793.86083,-213.23987 793.86083,-213.23987 C 793.86083,-213.23987 785.5667,-215.11352 782.58152,-216.08754 C 779.59633,-217.06156 774.78883,-218.92232 772.0785,-219.32416 C 769.36817,-219.726 759.85042,-217.61116 759.85042,-217.61116 z" | ||
2476 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2477 | <path | ||
2478 | sodipodi:nodetypes="czzzczzc" | ||
2479 | id="path8129" | ||
2480 | d="M 775.19813,-223.2266 C 775.19813,-223.2266 782.96946,-226.00904 784.82644,-226.13009 C 786.68341,-226.25113 788.45744,-225.57592 791.04822,-224.78947 C 793.63899,-224.00302 799.56662,-221.8473 801.91216,-220.48535 C 804.25771,-219.1234 808.27265,-217.81585 808.27265,-217.81585 C 808.27265,-217.81585 800.01892,-219.86008 797.05444,-220.89543 C 794.08997,-221.93078 789.32185,-223.89024 786.62038,-224.34786 C 783.91891,-224.80549 775.19813,-223.2266 775.19813,-223.2266 z" | ||
2481 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2482 | <path | ||
2483 | inkscape:transform-center-y="-4.3190906" | ||
2484 | inkscape:transform-center-x="13.852145" | ||
2485 | sodipodi:nodetypes="czzzczzc" | ||
2486 | id="path8131" | ||
2487 | d="M 789.64298,-227.95417 C 789.64298,-227.95417 798.32554,-231.47448 800.18452,-231.55952 C 802.04349,-231.64455 803.8041,-230.9351 806.37915,-230.09859 C 808.9542,-229.2621 814.83894,-226.99193 817.15766,-225.58479 C 819.47638,-224.17764 823.46523,-222.79255 823.46523,-222.79255 C 823.46523,-222.79255 815.25266,-224.99632 812.3088,-226.08891 C 809.36494,-227.1815 804.63568,-229.23299 801.94358,-229.74288 C 799.25149,-230.25276 789.64298,-227.95417 789.64298,-227.95417 z" | ||
2488 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2489 | <path | ||
2490 | inkscape:transform-center-y="-4.3190906" | ||
2491 | inkscape:transform-center-x="13.852145" | ||
2492 | sodipodi:nodetypes="czzzczzc" | ||
2493 | id="path8133" | ||
2494 | d="M 804.49513,-233.32948 C 804.49513,-233.32948 812.30269,-235.91229 814.16167,-235.99733 C 816.02064,-236.08236 817.78125,-235.37291 820.3563,-234.5364 C 822.93135,-233.69991 828.81609,-231.42974 831.13481,-230.0226 C 833.45353,-228.61545 837.44238,-227.23036 837.44238,-227.23036 C 837.44238,-227.23036 829.22981,-229.43413 826.28595,-230.52672 C 823.34209,-231.61931 818.61283,-233.6708 815.92073,-234.18069 C 813.22864,-234.69057 804.49513,-233.32948 804.49513,-233.32948 z" | ||
2495 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2496 | <path | ||
2497 | inkscape:transform-center-y="-4.3190906" | ||
2498 | inkscape:transform-center-x="13.852145" | ||
2499 | sodipodi:nodetypes="czzzczzc" | ||
2500 | id="path8135" | ||
2501 | d="M 819.55763,-237.57948 C 819.55763,-237.57948 828.11519,-240.16229 829.97417,-240.24733 C 831.83314,-240.33236 833.59375,-239.62291 836.1688,-238.7864 C 838.74385,-237.94991 844.62859,-235.67974 846.94731,-234.2726 C 849.26603,-232.86545 853.25488,-231.48036 853.25488,-231.48036 C 853.25488,-231.48036 845.04231,-233.68413 842.09845,-234.77672 C 839.15459,-235.86931 834.42533,-237.9208 831.73323,-238.43069 C 829.04114,-238.94057 819.55763,-237.57948 819.55763,-237.57948 z" | ||
2502 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2503 | <path | ||
2504 | inkscape:transform-center-y="-4.9269042" | ||
2505 | inkscape:transform-center-x="13.64141" | ||
2506 | sodipodi:nodetypes="czzzczzc" | ||
2507 | id="path8137" | ||
2508 | d="M 836.23395,-242.60125 C 836.23395,-242.60125 843.20097,-244.58848 845.06179,-244.56882 C 846.9226,-244.54915 848.64052,-243.7418 851.16444,-242.76177 C 853.68837,-241.78177 859.4361,-239.18419 861.672,-237.64886 C 863.9079,-236.11351 867.81253,-234.50625 867.81253,-234.50625 C 867.81253,-234.50625 859.73692,-237.16847 856.85917,-238.42491 C 853.98143,-239.68136 849.37505,-241.99561 846.71589,-242.65612 C 844.05674,-243.31661 836.23395,-242.60125 836.23395,-242.60125 z" | ||
2509 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2510 | <path | ||
2511 | inkscape:transform-center-y="-5.1542119" | ||
2512 | inkscape:transform-center-x="13.55068" | ||
2513 | sodipodi:nodetypes="czzzczzc" | ||
2514 | id="path8139" | ||
2515 | d="M 850.73028,-246.00461 C 850.73028,-246.00461 858.41812,-248.03229 860.2781,-247.97315 C 862.13807,-247.914 863.83848,-247.07036 866.34103,-246.03699 C 868.84358,-245.00365 874.5349,-242.28467 876.73771,-240.70224 C 878.94053,-239.11979 882.81016,-237.43004 882.81016,-237.43004 C 882.81016,-237.43004 874.79287,-240.26302 871.94244,-241.58026 C 869.09201,-242.89749 864.53578,-245.30898 861.89124,-246.02576 C 859.2467,-246.74254 850.73028,-246.00461 850.73028,-246.00461 z" | ||
2516 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2517 | <path | ||
2518 | inkscape:transform-center-y="-5.4740887" | ||
2519 | inkscape:transform-center-x="13.41151" | ||
2520 | sodipodi:nodetypes="czzzczzc" | ||
2521 | id="path8141" | ||
2522 | d="M 864.82496,-249.21081 C 864.82496,-249.21081 872.99448,-251.17987 874.85184,-251.06477 C 876.70919,-250.94965 878.38342,-250.05521 880.85374,-248.94698 C 883.32405,-247.83877 888.93094,-244.94971 891.08512,-243.30167 C 893.2393,-241.65363 897.05632,-239.84815 897.05632,-239.84815 C 897.05632,-239.84815 889.12793,-242.92121 886.31845,-244.32365 C 883.50896,-245.72609 879.02739,-248.27364 876.40562,-249.06971 C 873.78386,-249.86577 864.82496,-249.21081 864.82496,-249.21081 z" | ||
2523 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2524 | <path | ||
2525 | inkscape:transform-center-y="-5.79376" | ||
2526 | inkscape:transform-center-x="13.258805" | ||
2527 | sodipodi:nodetypes="czzzczzc" | ||
2528 | id="path8143" | ||
2529 | d="M 881.38485,-251.60282 C 881.38485,-251.60282 889.47021,-253.51091 891.32322,-253.33946 C 893.17622,-253.16799 894.82252,-252.22313 897.25804,-251.04038 C 899.69357,-249.85767 905.21013,-246.79968 907.31327,-245.08699 C 909.41641,-243.37429 913.17684,-241.45373 913.17684,-241.45373 C 913.17684,-241.45373 905.34544,-244.76613 902.57984,-246.25323 C 899.81423,-247.74035 895.41209,-250.42282 892.8157,-251.29814 C 890.21933,-252.17345 881.38485,-251.60282 881.38485,-251.60282 z" | ||
2530 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2531 | <path | ||
2532 | inkscape:transform-center-y="-5.7433893" | ||
2533 | inkscape:transform-center-x="13.28378" | ||
2534 | sodipodi:nodetypes="czzzczzc" | ||
2535 | id="path8145" | ||
2536 | d="M 896.58415,-254.34724 C 896.58415,-254.34724 904.22581,-255.77494 906.07962,-255.61239 C 907.93342,-255.44983 909.58424,-254.51289 912.02541,-253.34186 C 914.46659,-252.17086 919.99779,-249.1394 922.10913,-247.43684 C 924.22047,-245.73426 927.99009,-243.83179 927.99009,-243.83179 C 927.99009,-243.83179 920.14286,-247.10653 917.37014,-248.58034 C 914.59743,-250.05414 910.18245,-252.71543 907.58189,-253.57827 C 904.98134,-254.44109 896.58415,-254.34724 896.58415,-254.34724 z" | ||
2537 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2538 | <path | ||
2539 | inkscape:transform-center-y="-5.7433893" | ||
2540 | inkscape:transform-center-x="13.28378" | ||
2541 | sodipodi:nodetypes="czzzczzc" | ||
2542 | id="path8147" | ||
2543 | d="M 911.45328,-255.98544 C 911.45328,-255.98544 920.09494,-257.53814 921.94875,-257.37559 C 923.80255,-257.21303 925.45337,-256.27609 927.89454,-255.10506 C 930.33572,-253.93406 935.86692,-250.9026 937.97826,-249.20004 C 940.0896,-247.49746 943.85922,-245.59499 943.85922,-245.59499 C 943.85922,-245.59499 936.01199,-248.86973 933.23927,-250.34354 C 930.46656,-251.81734 926.05158,-254.47863 923.45102,-255.34147 C 920.85047,-256.20429 911.45328,-255.98544 911.45328,-255.98544 z" | ||
2544 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2545 | <path | ||
2546 | inkscape:transform-center-y="-5.7433893" | ||
2547 | inkscape:transform-center-x="13.28378" | ||
2548 | sodipodi:nodetypes="czzzczzc" | ||
2549 | id="path8149" | ||
2550 | d="M 927.70328,-258.29794 C 927.70328,-258.29794 935.34494,-259.16314 937.19875,-259.00059 C 939.05255,-258.83803 940.70337,-257.90109 943.14454,-256.73006 C 945.58572,-255.55906 951.11692,-252.5276 953.22826,-250.82504 C 955.3396,-249.12246 959.10922,-247.21999 959.10922,-247.21999 C 959.10922,-247.21999 951.26199,-250.49473 948.48927,-251.96854 C 945.71656,-253.44234 941.30158,-256.10363 938.70102,-256.96647 C 936.10047,-257.82929 927.70328,-258.29794 927.70328,-258.29794 z" | ||
2551 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2552 | <path | ||
2553 | inkscape:transform-center-y="-5.7433893" | ||
2554 | inkscape:transform-center-x="13.28378" | ||
2555 | sodipodi:nodetypes="czzzczzc" | ||
2556 | id="path8151" | ||
2557 | d="M 942.82828,-259.48544 C 942.82828,-259.48544 951.40744,-260.97564 953.26125,-260.81309 C 955.11505,-260.65053 956.76587,-259.71359 959.20704,-258.54256 C 961.64822,-257.37156 967.17942,-254.3401 969.29076,-252.63754 C 971.4021,-250.93496 975.17172,-249.03249 975.17172,-249.03249 C 975.17172,-249.03249 967.32449,-252.30723 964.55177,-253.78104 C 961.77906,-255.25484 957.36408,-257.91613 954.76352,-258.77897 C 952.16297,-259.64179 942.82828,-259.48544 942.82828,-259.48544 z" | ||
2558 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2559 | <path | ||
2560 | inkscape:transform-center-y="-5.7433893" | ||
2561 | inkscape:transform-center-x="13.28378" | ||
2562 | sodipodi:nodetypes="czzzczzc" | ||
2563 | id="path8153" | ||
2564 | d="M 959.07828,-261.54794 C 959.07828,-261.54794 966.90744,-262.35064 968.76125,-262.18809 C 970.61505,-262.02553 972.26587,-261.08859 974.70704,-259.91756 C 977.14822,-258.74656 982.67942,-255.7151 984.79076,-254.01254 C 986.9021,-252.30996 990.67172,-250.40749 990.67172,-250.40749 C 990.67172,-250.40749 982.82449,-253.68223 980.05177,-255.15604 C 977.27906,-256.62984 972.86408,-259.29113 970.26352,-260.15397 C 967.66297,-261.01679 959.07828,-261.54794 959.07828,-261.54794 z" | ||
2565 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2566 | <path | ||
2567 | inkscape:transform-center-y="-5.7433893" | ||
2568 | inkscape:transform-center-x="13.28378" | ||
2569 | sodipodi:nodetypes="czzzczzc" | ||
2570 | id="path8155" | ||
2571 | d="M 974.45328,-262.79794 C 974.45328,-262.79794 982.84494,-263.97564 984.69875,-263.81309 C 986.55255,-263.65053 988.20337,-262.71359 990.64454,-261.54256 C 993.08572,-260.37156 998.61692,-257.3401 1000.7283,-255.63754 C 1002.8396,-253.93496 1006.6092,-252.03249 1006.6092,-252.03249 C 1006.6092,-252.03249 998.76199,-255.30723 995.98927,-256.78104 C 993.21656,-258.25484 988.80158,-260.91613 986.20102,-261.77897 C 983.60047,-262.64179 974.45328,-262.79794 974.45328,-262.79794 z" | ||
2572 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2573 | <path | ||
2574 | inkscape:transform-center-y="-5.7433893" | ||
2575 | inkscape:transform-center-x="13.28378" | ||
2576 | sodipodi:nodetypes="czzzczzc" | ||
2577 | id="path8157" | ||
2578 | d="M 990.64078,-264.86044 C 990.64078,-264.86044 997.53244,-265.85064 999.38625,-265.68809 C 1001.2401,-265.52553 1002.8909,-264.58859 1005.332,-263.41756 C 1007.7732,-262.24656 1013.3044,-259.2151 1015.4158,-257.51254 C 1017.5271,-255.80996 1021.2967,-253.90749 1021.2967,-253.90749 C 1021.2967,-253.90749 1013.4495,-257.18223 1010.6768,-258.65604 C 1007.9041,-260.12984 1003.4891,-262.79113 1000.8885,-263.65397 C 998.28797,-264.51679 990.64078,-264.86044 990.64078,-264.86044 z" | ||
2579 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2580 | <path | ||
2581 | inkscape:transform-center-y="-5.7433893" | ||
2582 | inkscape:transform-center-x="13.28378" | ||
2583 | sodipodi:nodetypes="czzzczzc" | ||
2584 | id="path8159" | ||
2585 | d="M 1007.7658,-265.79794 C 1007.7658,-265.79794 1014.5949,-266.97564 1016.4488,-266.81309 C 1018.3026,-266.65053 1019.9534,-265.71359 1022.3945,-264.54256 C 1024.8357,-263.37156 1030.3669,-260.3401 1032.4783,-258.63754 C 1034.5896,-256.93496 1038.3592,-255.03249 1038.3592,-255.03249 C 1038.3592,-255.03249 1030.512,-258.30723 1027.7393,-259.78104 C 1024.9666,-261.25484 1020.5516,-263.91613 1017.951,-264.77897 C 1015.3505,-265.64179 1007.7658,-265.79794 1007.7658,-265.79794 z" | ||
2586 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2587 | <path | ||
2588 | inkscape:transform-center-y="-5.7433893" | ||
2589 | inkscape:transform-center-x="13.28378" | ||
2590 | sodipodi:nodetypes="czzzczzc" | ||
2591 | id="path8161" | ||
2592 | d="M 1023.8908,-267.79794 C 1023.8908,-267.79794 1029.9699,-268.22564 1031.8238,-268.06309 C 1033.6776,-267.90053 1035.3284,-266.96359 1037.7695,-265.79256 C 1040.2107,-264.62156 1045.7419,-261.5901 1047.8533,-259.88754 C 1049.9646,-258.18496 1053.7342,-256.28249 1053.7342,-256.28249 C 1053.7342,-256.28249 1045.887,-259.55723 1043.1143,-261.03104 C 1040.3416,-262.50484 1035.9266,-265.16613 1033.326,-266.02897 C 1030.7255,-266.89179 1023.8908,-267.79794 1023.8908,-267.79794 z" | ||
2593 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2594 | <path | ||
2595 | inkscape:transform-center-y="-5.7433893" | ||
2596 | inkscape:transform-center-x="13.28378" | ||
2597 | sodipodi:nodetypes="czzzczzc" | ||
2598 | id="path8163" | ||
2599 | d="M 1039.7033,-269.17294 C 1039.7033,-269.17294 1046.1574,-269.85064 1048.0113,-269.68809 C 1049.8651,-269.52553 1051.5159,-268.58859 1053.957,-267.41756 C 1056.3982,-266.24656 1061.9294,-263.2151 1064.0408,-261.51254 C 1066.1521,-259.80996 1069.9217,-257.90749 1069.9217,-257.90749 C 1069.9217,-257.90749 1062.0745,-261.18223 1059.3018,-262.65604 C 1056.5291,-264.12984 1052.1141,-266.79113 1049.5135,-267.65397 C 1046.913,-268.51679 1039.7033,-269.17294 1039.7033,-269.17294 z" | ||
2600 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2601 | <path | ||
2602 | inkscape:transform-center-y="-5.1360724" | ||
2603 | inkscape:transform-center-x="13.55813" | ||
2604 | sodipodi:nodetypes="czzzczzc" | ||
2605 | id="path8165" | ||
2606 | d="M 1055.2718,-271.03319 C 1055.2718,-271.03319 1060.7694,-271.94264 1062.6296,-271.88667 C 1064.4897,-271.83067 1066.1915,-270.98993 1068.6957,-269.96081 C 1071.2001,-268.93171 1076.896,-266.22241 1079.1015,-264.64372 C 1081.307,-263.06501 1085.1795,-261.38182 1085.1795,-261.38182 C 1085.1795,-261.38182 1077.1575,-264.20121 1074.3047,-265.5136 C 1071.4521,-266.82598 1066.8918,-269.22973 1064.246,-269.94203 C 1061.6003,-270.65431 1055.2718,-271.03319 1055.2718,-271.03319 z" | ||
2607 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2608 | <path | ||
2609 | inkscape:transform-center-y="-4.6370147" | ||
2610 | inkscape:transform-center-x="13.74758" | ||
2611 | sodipodi:nodetypes="czzzczzc" | ||
2612 | id="path8167" | ||
2613 | d="M 1072.7007,-273.48537 C 1072.7007,-273.48537 1077.2479,-274.64118 1079.1087,-274.67158 C 1080.9694,-274.70196 1082.7083,-273.94109 1085.2576,-273.02927 C 1087.807,-272.1175 1093.6225,-269.67541 1095.899,-268.20077 C 1098.1753,-266.72609 1102.1217,-265.22441 1102.1217,-265.22441 C 1102.1217,-265.22441 1093.9775,-267.66852 1091.067,-268.84713 C 1088.1565,-270.02573 1083.4896,-272.21528 1080.8136,-272.80404 C 1078.1377,-273.39279 1072.7007,-273.48537 1072.7007,-273.48537 z" | ||
2614 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2615 | <path | ||
2616 | inkscape:transform-center-y="-4.4842392" | ||
2617 | inkscape:transform-center-x="13.79933" | ||
2618 | sodipodi:nodetypes="czzzczzc" | ||
2619 | id="path8169" | ||
2620 | d="M 1087.1585,-276.5244 C 1087.1585,-276.5244 1093.1185,-278.29795 1094.9787,-278.35464 C 1096.8387,-278.41131 1098.5883,-277.67509 1101.1502,-276.79939 C 1103.7122,-275.92373 1103.6728,-275.94226 1106.4837,-275.30924 C 1109.2806,-274.67938 1113.5604,-273.79611 1113.5604,-273.79611 C 1113.5604,-273.79611 1109.9449,-273.81239 1106.7681,-274.26225 C 1103.6526,-274.70344 1099.3938,-275.9605 1096.7097,-276.51138 C 1094.0258,-277.06226 1087.1585,-276.5244 1087.1585,-276.5244 z" | ||
2621 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" /> | ||
2622 | <path | ||
2623 | sodipodi:nodetypes="czczc" | ||
2624 | id="path8171" | ||
2625 | d="M 1099.25,-279.92981 C 1099.4112,-279.66119 1110.4581,-284.53027 1111.4375,-284.61731 C 1112.4169,-284.70435 1113.4375,-281.49231 1113.4375,-281.49231 C 1113.4375,-281.49231 1112.6624,-282.99665 1110.5625,-282.55481 C 1108.4626,-282.11297 1099.2616,-279.8834 1099.25,-279.92981 z" | ||
2626 | style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /> | ||
2627 | </g> | ||
2628 | <path | ||
2629 | id="path8173" | ||
2630 | d="M 1107.4532,-284.0938 C 1107.0345,-283.88097 1107.2976,-283.99991 1106.806,-283.78799 C 1106.3199,-283.57845 1105.0826,-283.2136 1102.7264,-282.32904 C 1099.3953,-281.07847 1096.8962,-280.1756 1095.7005,-279.26294 C 1094.1644,-279.24168 1091.98,-279.02963 1090.0442,-278.54419 C 1087.0627,-277.79653 1085.189,-277.37018 1083.2942,-276.95044 C 1081.3994,-276.53072 1081.6187,-276.30825 1080.4192,-276.07544 C 1079.1226,-275.82378 1078.6978,-276.08443 1074.9817,-275.29419 C 1071.4918,-274.55205 1066.0869,-273.36312 1064.8255,-272.60669 C 1063.2416,-272.78748 1060.958,-272.92847 1058.9817,-272.63794 C 1055.9413,-272.19099 1054.0655,-271.96518 1052.138,-271.73169 C 1051.4826,-271.65232 1051.0969,-271.53091 1050.7942,-271.45044 C 1050.368,-271.31879 1050.1084,-271.19042 1049.4192,-271.10669 C 1048.1076,-270.94733 1047.657,-271.26352 1043.888,-270.82544 C 1040.3341,-270.41236 1034.8826,-269.55262 1033.638,-268.88794 C 1032.039,-269.18524 1029.7802,-269.42213 1027.7942,-269.23169 C 1024.7354,-268.93838 1022.8222,-268.7477 1020.888,-268.57544 C 1018.9537,-268.40318 1019.1993,-268.15307 1017.9817,-268.04419 C 1016.6655,-267.9265 1016.2219,-268.20782 1012.4505,-267.79419 C 1008.9086,-267.40575 1003.4426,-266.58492 1002.1692,-265.91919 C 1000.5703,-266.21389 998.28202,-266.4262 996.29419,-266.23169 C 993.23595,-265.93245 991.35306,-265.75145 989.41919,-265.57544 C 988.7617,-265.5156 988.37915,-265.39688 988.07544,-265.32544 C 987.64779,-265.20649 987.39193,-265.10737 986.70044,-265.04419 C 985.38448,-264.92394 984.94068,-265.23907 981.16919,-264.82544 C 977.61305,-264.43543 972.16365,-263.58628 970.91919,-262.91919 C 969.32056,-263.21338 967.05935,-263.44291 965.07544,-263.23169 C 962.01984,-262.90637 960.1014,-262.70545 958.16919,-262.51294 C 956.23698,-262.32044 956.47932,-262.07206 955.26294,-261.95044 C 953.94806,-261.81898 953.49996,-262.11498 949.73169,-261.66919 C 946.19282,-261.25054 940.75401,-260.37702 939.48169,-259.70044 C 937.88414,-259.98149 935.62173,-260.12087 933.63794,-259.88794 C 930.58596,-259.52958 928.69286,-259.32008 926.76294,-259.10669 C 926.10674,-259.03414 925.72228,-258.934 925.41919,-258.85669 C 924.99242,-258.72947 924.73428,-258.58949 924.04419,-258.51294 C 922.73086,-258.36726 922.27673,-258.68696 918.51294,-258.20044 C 914.96405,-257.74169 909.53431,-256.78142 908.29419,-256.07544 C 906.70114,-256.31968 904.46038,-256.45679 902.48169,-256.20044 C 899.4341,-255.80563 897.53098,-255.55199 895.60669,-255.29419 C 893.68241,-255.0364 893.88058,-254.80066 892.66919,-254.63794 C 891.35973,-254.46204 890.922,-254.74232 887.16919,-254.16919 C 883.6449,-253.63095 878.24604,-252.47002 876.98169,-251.73169 C 875.39419,-251.93523 873.13619,-251.98642 871.16919,-251.63794 C 868.14302,-251.10182 866.2703,-250.77625 864.35669,-250.45044 C 863.70608,-250.33967 863.34298,-250.1795 863.04419,-250.07544 C 862.62352,-249.91056 862.38074,-249.74414 861.70044,-249.60669 C 860.40579,-249.3451 859.97332,-249.61289 856.26294,-248.79419 C 852.76441,-248.02224 847.41699,-246.41126 846.20044,-245.57544 C 844.63766,-245.65289 842.44286,-245.49016 840.51294,-244.98169 C 837.5405,-244.19856 835.69533,-243.7496 833.82544,-243.23169 C 831.95556,-242.71379 832.15884,-242.46441 830.98169,-242.13794 C 829.70923,-241.78504 829.28466,-242.03085 825.63794,-240.95044 C 822.21324,-239.93581 816.9885,-238.01727 815.76294,-237.10669 C 814.22411,-237.09395 812.04311,-236.83447 810.13794,-236.23169 C 807.20688,-235.30435 805.38763,-234.77327 803.54419,-234.16919 C 802.91743,-233.96381 802.55246,-233.77661 802.26294,-233.63794 C 801.85531,-233.42433 801.6096,-233.22919 800.95044,-233.01294 C 799.69598,-232.6014 799.26433,-232.8239 795.66919,-231.57544 C 792.27934,-230.39827 787.07421,-228.36174 785.88794,-227.41919 C 784.36405,-227.35952 782.23789,-227.02432 780.35669,-226.35669 C 777.4593,-225.3284 775.65761,-224.68121 773.82544,-224.04419 C 771.99327,-223.40718 772.19759,-223.19565 771.04419,-222.79419 C 769.79741,-222.36023 769.38058,-222.59447 765.82544,-221.23169 C 762.48677,-219.95189 757.33829,-217.74914 756.13794,-216.76294 C 754.63076,-216.65525 752.50225,-216.26414 750.63794,-215.54419 C 747.76976,-214.43659 746.01414,-213.76263 744.20044,-213.07544 C 743.58378,-212.84181 743.20403,-212.63341 742.91919,-212.48169 C 742.91919,-212.48169 742.91919,-211.38794 742.91919,-211.38794 C 743.03097,-211.6103 743.30518,-212.20537 743.82544,-212.48169 C 744.52341,-212.85241 748.63907,-214.47506 750.63794,-215.20044 C 752.2948,-215.80169 754.79183,-216.52912 756.60669,-216.51294 C 756.90831,-216.51025 757.19431,-216.46204 757.45044,-216.41919 C 759.29293,-216.11094 764.91919,-214.85669 764.91919,-214.85669 C 764.91918,-214.85669 758.6857,-216.50344 757.88794,-216.70044 C 757.69715,-216.74755 757.35222,-216.76916 756.91919,-216.76294 C 758.06465,-217.63265 761.68019,-219.15645 764.26294,-220.20044 C 767.10116,-221.34771 767.37975,-221.45226 769.32544,-221.85669 C 771.33374,-222.27413 772.48169,-222.35669 772.48169,-222.35669 C 772.48169,-222.35668 772.39933,-222.95783 773.45044,-223.48169 C 774.15554,-223.8331 778.33746,-225.37409 780.35669,-226.04419 C 782.30859,-226.69192 785.41409,-227.40269 787.23169,-227.04419 C 789.09492,-226.67669 794.76294,-225.23169 794.76294,-225.23169 C 794.76295,-225.23169 788.47594,-227.1028 787.66919,-227.32544 C 787.47627,-227.37869 787.13835,-227.41148 786.70044,-227.41919 C 787.85878,-228.25207 791.49488,-229.61451 794.10669,-230.57544 C 796.97685,-231.63145 797.27403,-231.73724 799.23169,-232.10669 C 801.08518,-232.45648 802.09053,-232.53217 802.26294,-232.54419 C 802.37654,-232.76143 802.64039,-233.35421 803.16919,-233.60669 C 803.87863,-233.94543 808.09526,-235.31944 810.13794,-235.91919 C 811.83111,-236.4163 814.37871,-236.95596 816.23169,-236.82544 C 816.53964,-236.80376 816.84518,-236.72818 817.10669,-236.66919 C 818.98787,-236.24487 824.70044,-234.63794 824.70044,-234.63794 C 824.70045,-234.63794 818.3587,-236.70319 817.54419,-236.95044 C 817.3494,-237.00958 816.98631,-237.05438 816.54419,-237.07544 C 817.71368,-237.87299 821.40721,-239.13166 824.04419,-240.01294 C 826.942,-240.98141 827.2772,-241.01626 829.26294,-241.29419 C 831.31259,-241.58108 832.45044,-241.60669 832.45044,-241.60669 C 832.45042,-241.60669 832.37769,-242.21366 833.45044,-242.66919 C 834.17004,-242.97476 838.44142,-244.16994 840.51294,-244.66919 C 842.51538,-245.15177 845.71143,-245.59748 847.57544,-245.07544 C 849.48622,-244.54029 855.29419,-242.57544 855.29419,-242.57544 C 855.29419,-242.57544 848.87153,-244.99895 848.04419,-245.29419 C 847.84635,-245.3648 847.46203,-245.43458 847.01294,-245.48169 C 848.20084,-246.21034 851.92821,-247.25577 854.60669,-247.98169 C 857.55011,-248.77944 857.89877,-248.75252 859.91919,-248.88794 C 861.83208,-249.01617 862.86624,-248.95903 863.04419,-248.95044 C 863.16147,-249.1541 863.43595,-249.72992 863.98169,-249.91919 C 864.71388,-250.17313 869.06021,-250.96708 871.16919,-251.29419 C 872.91732,-251.5653 875.57007,-251.77889 877.48169,-251.38794 C 877.79935,-251.32298 878.08691,-251.20243 878.35669,-251.10669 C 880.29743,-250.41796 886.20044,-248.01294 886.20044,-248.01294 C 886.20045,-248.01294 879.66573,-250.96371 878.82544,-251.32544 C 878.62447,-251.41195 878.25031,-251.49223 877.79419,-251.57544 C 879.00069,-252.20862 882.82375,-252.97104 885.54419,-253.48169 C 888.53372,-254.04288 888.84442,-254.01123 890.88794,-254.01294 C 892.9972,-254.01471 894.20044,-253.88794 894.20044,-253.88794 C 894.20044,-253.88793 894.12773,-254.51913 895.23169,-254.82544 C 895.97221,-255.03091 900.35781,-255.65931 902.48169,-255.88794 C 904.53471,-256.10893 907.80032,-256.14016 909.70044,-255.41919 C 911.64823,-254.68012 917.54419,-252.04419 917.54419,-252.04419 C 917.54421,-252.04419 910.98131,-255.22316 910.13794,-255.60669 C 909.93626,-255.69842 909.59573,-255.7929 909.13794,-255.88794 C 910.34886,-256.48982 914.12236,-257.13678 916.85669,-257.54419 C 919.86149,-257.99191 920.1822,-257.99589 922.23169,-257.95044 C 924.17214,-257.90742 925.23868,-257.75621 925.41919,-257.73169 C 925.53811,-257.92485 925.80309,-258.49752 926.35669,-258.63794 C 927.0994,-258.82632 931.51098,-259.37222 933.63794,-259.57544 C 935.40097,-259.74386 938.05803,-259.80973 939.98169,-259.32544 C 940.30137,-259.24496 940.5852,-259.12185 940.85669,-259.01294 C 942.80962,-258.22945 948.76294,-255.54419 948.76294,-255.54419 C 948.76292,-255.54419 942.17103,-258.79767 941.32544,-259.20044 C 941.12322,-259.29676 940.75318,-259.40747 940.29419,-259.51294 C 941.50833,-260.08721 945.33785,-260.63513 948.07544,-261.01294 C 951.08382,-261.42814 951.39851,-261.45557 953.45044,-261.38794 C 955.56842,-261.31813 956.76294,-261.13794 956.76294,-261.13794 C 956.76292,-261.13794 956.68569,-261.77535 957.79419,-262.04419 C 958.53781,-262.22454 962.94595,-262.70774 965.07544,-262.88794 C 967.13391,-263.06211 970.41868,-263.01226 972.32544,-262.23169 C 974.28003,-261.43153 980.20044,-258.70044 980.20044,-258.70044 C 980.20042,-258.70044 973.64051,-262.0092 972.79419,-262.41919 C 972.59182,-262.51724 972.22233,-262.62229 971.76294,-262.73169 C 972.97811,-263.29559 976.77302,-263.84599 979.51294,-264.20044 C 982.52385,-264.58996 982.83425,-264.59809 984.88794,-264.51294 C 986.83233,-264.43234 987.89457,-264.2597 988.07544,-264.23169 C 988.1946,-264.42255 988.45821,-264.977 989.01294,-265.10669 C 989.7572,-265.28069 994.16287,-265.75716 996.29419,-265.91919 C 998.06081,-266.05346 1000.7439,-266.0449 1002.6692,-265.54419 C 1002.9892,-265.46098 1003.2725,-265.34292 1003.5442,-265.23169 C 1005.4988,-264.43153 1011.4505,-261.66919 1011.4505,-261.66919 C 1011.4504,-261.66919 1004.8593,-265.0092 1004.013,-265.41919 C 1003.8106,-265.51724 1003.4411,-265.6223 1002.9817,-265.73169 C 1004.1968,-266.29559 1008.023,-266.81475 1010.763,-267.16919 C 1013.7739,-267.55872 1014.1155,-267.59809 1016.1692,-267.51294 C 1018.2889,-267.42506 1019.4817,-267.20044 1019.4817,-267.20044 C 1019.4817,-267.20044 1019.4033,-267.84946 1020.513,-268.10669 C 1021.2573,-268.27925 1025.6625,-268.73005 1027.7942,-268.88794 C 1029.8548,-269.04054 1033.1371,-268.98471 1035.0442,-268.20044 C 1036.9992,-267.39649 1042.9192,-264.70044 1042.9192,-264.70044 C 1042.9192,-264.70044 1036.3594,-267.97631 1035.513,-268.38794 C 1035.3105,-268.48638 1034.9412,-268.59016 1034.4817,-268.70044 C 1035.6971,-269.26198 1039.4936,-269.82822 1042.2317,-270.20044 C 1045.2407,-270.60949 1045.5544,-270.61602 1047.6067,-270.54419 C 1049.5498,-270.4762 1050.6139,-270.37934 1050.7942,-270.35669 C 1050.913,-270.55109 1051.1788,-271.0855 1051.7317,-271.23169 C 1052.4735,-271.42781 1056.8628,-272.06047 1058.9817,-272.32544 C 1060.7381,-272.54505 1063.387,-272.65775 1065.2942,-272.29419 C 1065.6111,-272.23378 1065.9,-272.10481 1066.1692,-272.01294 C 1068.1054,-271.35202 1074.013,-269.07544 1074.013,-269.07544 C 1074.0129,-269.07544 1067.4763,-271.88199 1066.638,-272.23169 C 1066.4375,-272.31532 1066.0618,-272.40502 1065.6067,-272.48169 C 1066.8104,-273.13215 1070.6258,-273.85364 1073.3255,-274.48169 C 1076.2922,-275.17189 1076.6144,-275.23676 1078.638,-275.35669 C 1080.7266,-275.48049 1081.9192,-275.38794 1081.9192,-275.38794 C 1081.9192,-275.38793 1081.8322,-276.01999 1082.9192,-276.41919 C 1083.6484,-276.68699 1087.9664,-277.75716 1090.0442,-278.23169 C 1092.0527,-278.69038 1095.2121,-279.26099 1097.0442,-278.85669 C 1098.9223,-278.44223 1110.6224,-275.84106 1110.6224,-275.84106 C 1110.6224,-275.84106 1098.2949,-278.86372 1097.4817,-279.10669 C 1097.2872,-279.16481 1096.9231,-279.21295 1096.4817,-279.23169 C 1097.6493,-280.03538 1099.9959,-280.91899 1102.5911,-281.93481 C 1104.2725,-282.59299 1103.5148,-282.3114 1105.367,-282.93841 C 1107.1206,-283.53207 1107.8524,-283.94912 1107.9974,-284.0514 C 1108.3435,-284.25791 1107.6414,-284.17328 1107.4532,-284.0938 z" | ||
2631 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7333);enable-background:new" | ||
2632 | sodipodi:nodetypes="czscsssscssssscsssscssssscsssscssssscsssscssssscsssscssssscsssscssccsssscscsscssscscsscsssscscsscssscscsscsssscscsscssscscsscsssscscsscssscscsscsssscscsscssscscsscsssscscsscssscscsscc" /> | ||
2633 | <path | ||
2634 | id="path8175" | ||
2635 | d="M 1082.625,-275.125 C 1084.498,-274.73152 1087.1211,-273.97945 1088.6563,-273.15625 C 1090.1915,-272.33306 1091.4785,-272.10025 1094.0313,-270.65625 C 1096.5579,-269.22699 1098.8271,-268.64929 1101,-268.125 C 1103.3476,-267.55858 1106.4354,-267.40977 1109.8438,-266.9375 C 1108.7549,-267.77725 1103.2364,-268.10995 1101.4375,-268.5 C 1099.6386,-268.89006 1097.5434,-269.51616 1094.8438,-270.8125 C 1092.1441,-272.10884 1091.3494,-272.61146 1089.0313,-273.5 C 1086.7131,-274.38854 1085.0269,-274.88314 1082.625,-275.125 z" | ||
2636 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7285);enable-background:new" /> | ||
2637 | <path | ||
2638 | id="path8177" | ||
2639 | d="M 1051.4688,-270 C 1053.3741,-269.42241 1055.9969,-268.38428 1057.5625,-267.40625 C 1059.1281,-266.42823 1060.4427,-266.04644 1063.0625,-264.28125 C 1065.6555,-262.53409 1068.0484,-261.57198 1070.3125,-260.6875 C 1072.7586,-259.73193 1075.9951,-259.03037 1079.7188,-257.625 C 1078.5292,-258.76284 1072.6557,-260.31175 1070.7813,-261 C 1068.9068,-261.68825 1066.6995,-262.5662 1063.9063,-264.28125 C 1061.113,-265.99629 1060.3327,-266.56515 1057.9688,-267.6875 C 1055.6047,-268.80984 1053.9121,-269.52205 1051.4688,-270 z" | ||
2640 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7289);enable-background:new" /> | ||
2641 | <path | ||
2642 | id="path8179" | ||
2643 | d="M 1020.2188,-266.84375 C 1022.1307,-266.20564 1024.8,-265.08839 1026.375,-264.03125 C 1027.9501,-262.9741 1029.2706,-262.52258 1031.9063,-260.625 C 1034.5149,-258.74679 1036.9347,-257.59497 1039.2188,-256.5625 C 1041.6865,-255.44705 1044.9833,-254.3892 1048.75,-252.71875 C 1047.5467,-253.94128 1041.5472,-256.03298 1039.6563,-256.84375 C 1037.7653,-257.65452 1035.5914,-258.73754 1032.7813,-260.59375 C 1029.9711,-262.44995 1029.1595,-263.07068 1026.7813,-264.3125 C 1024.403,-265.5543 1022.6706,-266.28819 1020.2188,-266.84375 z" | ||
2644 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7293);enable-background:new" /> | ||
2645 | <path | ||
2646 | id="path8181" | ||
2647 | d="M 1110.1719,-266.89063 C 1110.3227,-266.84207 1110.8599,-266.25963 1110.2813,-265.40625 C 1109.4712,-264.21166 1104.5764,-262.08196 1101.7188,-261.28125 C 1098.8739,-260.48413 1095.4287,-260.30351 1091.1563,-261.65625 C 1086.8547,-263.0182 1085.6866,-264.12497 1080.5,-265.96875 C 1085.164,-263.85358 1086.6953,-262.01642 1090.625,-260.625 C 1092.2457,-260.05113 1093.9921,-259.6854 1095.6875,-259.59375 C 1095.2424,-259.26812 1094.1572,-258.61045 1092.125,-258 C 1089.3295,-257.16031 1085.4759,-256.46622 1083.875,-256.375 C 1082.3604,-256.28868 1080.733,-256.88749 1080.4375,-257 C 1080.6042,-256.89692 1080.8107,-256.62266 1080.1875,-255.96875 C 1079.2882,-255.02512 1074.0401,-254.04575 1071.0625,-253.71875 C 1068.0982,-253.3932 1064.5409,-253.73471 1060.1563,-255.625 C 1056.1783,-257.33997 1054.8173,-258.54036 1050.75,-260.375 C 1050.75,-260.375 1050.75,-260.21875 1050.75,-260.21875 C 1054.3931,-258.12346 1056.034,-256.33548 1059.625,-254.65625 C 1061.3552,-253.84716 1063.2167,-253.24749 1065.0313,-252.9375 C 1064.4964,-252.65074 1063.4735,-252.22599 1061.5938,-251.90625 C 1058.7248,-251.41829 1054.7848,-251.09011 1053.1563,-251.15625 C 1052.3056,-251.19079 1051.4277,-251.34062 1050.75,-251.5625 C 1050.0652,-251.77738 1049.5603,-252.00717 1049.4375,-252.0625 C 1049.6069,-251.95529 1049.8686,-251.65962 1049.2188,-251.03125 C 1048.3091,-250.15163 1042.9727,-249.69487 1039.9688,-249.5625 C 1036.9783,-249.43071 1033.3799,-250.01313 1028.9688,-252.125 C 1024.5276,-254.25126 1023.3273,-255.5266 1018.0625,-257.90625 C 1022.7968,-255.30921 1024.349,-253.27715 1028.4063,-251.1875 C 1030.0796,-250.32565 1031.8915,-249.69325 1033.6563,-249.25 C 1033.193,-249.01668 1032.0669,-248.56186 1029.9688,-248.3125 C 1027.0825,-247.96952 1023.1342,-247.81962 1021.5,-247.9375 C 1019.9538,-248.049 1018.2688,-248.79446 1017.9688,-248.9375 C 1018.1379,-248.81721 1018.3826,-248.52702 1017.75,-247.9375 C 1016.8372,-247.08677 1011.5059,-246.67538 1008.5,-246.5625 C 1005.5075,-246.45013 1001.9103,-247.05293 997.5,-249.15625 C 993.49875,-251.06448 992.11197,-252.29408 988.03125,-254.25 C 988.03122,-254.25 988.03125,-254.09375 988.03125,-254.09375 C 991.68631,-251.88983 993.32546,-250.0412 996.9375,-248.1875 C 998.67779,-247.29435 1000.5745,-246.65923 1002.4063,-246.21875 C 1001.8663,-245.97045 1000.8282,-245.60342 998.9375,-245.375 C 996.05182,-245.02642 992.07145,-244.85405 990.4375,-244.96875 C 989.58405,-245.02865 988.71119,-245.22666 988.03125,-245.46875 C 987.34415,-245.70405 986.8419,-245.94101 986.71875,-246 C 986.88873,-245.88773 987.18323,-245.57775 986.53125,-244.96875 C 985.6186,-244.11625 980.25592,-243.67538 977.25,-243.5625 C 974.25754,-243.45013 970.65654,-244.09055 966.25,-246.15625 C 961.81347,-248.23603 960.60312,-249.48796 955.34375,-251.8125 C 960.07313,-249.26501 961.63449,-247.2347 965.6875,-245.1875 C 967.35905,-244.34317 969.17304,-243.72107 970.9375,-243.28125 C 970.47427,-243.04703 969.3478,-242.59718 967.25,-242.34375 C 964.36431,-241.99517 960.4138,-241.77423 958.78125,-241.875 C 957.23669,-241.97032 955.58094,-242.70385 955.28125,-242.84375 C 955.45024,-242.72522 955.66317,-242.4399 955.03125,-241.84375 C 954.11939,-240.98347 948.7846,-240.5135 945.78125,-240.375 C 942.7913,-240.2371 939.2138,-240.82568 934.8125,-242.84375 C 930.81942,-244.67464 929.44739,-245.87295 925.375,-247.75 C 925.37498,-247.75 925.375,-247.59375 925.375,-247.59375 C 929.02261,-245.46048 930.64533,-243.65888 934.25,-241.875 C 935.98675,-241.01549 937.85727,-240.42486 939.6875,-240 C 939.14803,-239.7471 938.13687,-239.35871 936.25,-239.09375 C 933.37022,-238.68939 929.41187,-238.44813 927.78125,-238.53125 C 926.92953,-238.57466 926.05355,-238.7398 925.375,-238.96875 C 924.68931,-239.19076 924.1854,-239.41214 924.0625,-239.46875 C 924.23209,-239.35976 924.4944,-239.0591 923.84375,-238.4375 C 922.93296,-237.56736 917.59354,-237.04598 914.59375,-236.875 C 911.60742,-236.70479 908.01994,-237.19077 903.625,-239.15625 C 899.20011,-241.13513 898.01904,-242.38444 892.78125,-244.53125 C 897.49122,-242.14358 899.05142,-240.14252 903.09375,-238.1875 C 904.7609,-237.38119 906.55418,-236.79092 908.3125,-236.40625 C 907.85087,-236.15755 906.7155,-235.694 904.625,-235.375 C 901.7494,-234.93624 897.8446,-234.6419 896.21875,-234.6875 C 894.68052,-234.73062 892.98595,-235.43272 892.6875,-235.5625 C 892.85583,-235.44968 893.09807,-235.14875 892.46875,-234.53125 C 891.56063,-233.64015 886.2658,-233.003 883.28125,-232.71875 C 880.31007,-232.43577 876.70783,-232.89455 872.34375,-234.65625 C 868.38441,-236.25456 867.0146,-237.45112 863,-238.96875 C 863.00003,-238.96875 863,-238.8125 863,-238.8125 C 866.5959,-237.00115 868.23831,-235.23017 871.8125,-233.65625 C 873.53457,-232.8979 875.39998,-232.3673 877.21875,-232.03125 C 876.68266,-231.75217 875.65217,-231.34362 873.78125,-230.96875 C 870.92586,-230.39665 866.99183,-229.94936 865.375,-229.9375 C 864.53049,-229.93129 863.66892,-230.01844 863,-230.1875 C 862.32409,-230.34901 861.83991,-230.51673 861.71875,-230.5625 C 861.88597,-230.46848 862.14142,-230.17902 861.5,-229.5 C 860.60213,-228.54948 855.31352,-227.58292 852.375,-227.0625 C 849.44966,-226.54441 845.94285,-226.68826 841.65625,-228.09375 C 837.34045,-229.50882 836.18348,-230.62369 831.09375,-232.0625 C 835.6706,-230.31149 837.1823,-228.50244 841.125,-227.0625 C 842.75108,-226.46861 844.49385,-226.10685 846.21875,-225.90625 C 845.7659,-225.60923 844.66397,-225.02286 842.625,-224.4375 C 839.82028,-223.63233 835.98614,-222.86167 834.40625,-222.6875 C 832.9115,-222.5227 831.29002,-223.00431 831,-223.09375 C 831.16356,-223.00368 831.39278,-222.73382 830.78125,-222.03125 C 829.89878,-221.0174 824.73673,-219.6596 821.84375,-218.96875 C 818.96373,-218.28097 815.50815,-218.20873 811.28125,-219.40625 C 807.4464,-220.4927 806.10867,-221.47862 802.21875,-222.53125 C 802.21874,-222.53125 802.21875,-222.375 802.21875,-222.375 C 805.70293,-220.98015 807.28816,-219.4556 810.75,-218.34375 C 812.41793,-217.80803 814.20578,-217.55701 815.96875,-217.46875 C 815.44911,-217.11663 814.46836,-216.55423 812.65625,-215.9375 C 809.89059,-214.99625 806.06601,-214.00213 804.5,-213.78125 C 803.68206,-213.66586 802.8669,-213.65842 802.21875,-213.75 C 801.56379,-213.83321 801.08615,-213.96827 800.96875,-214 C 801.13079,-213.92536 801.40274,-213.65956 800.78125,-212.90625 C 799.91125,-211.85172 794.77162,-210.247 791.90625,-209.46875 C 789.05372,-208.69399 785.64713,-208.51055 781.46875,-209.5625 C 777.26192,-210.62163 776.11206,-211.60416 771.125,-212.71875 C 775.60954,-211.25929 777.09435,-209.58352 780.9375,-208.46875 C 782.52254,-208.00898 784.22429,-207.8305 785.90625,-207.78125 C 785.46468,-207.44449 784.39374,-206.75352 782.40625,-206 C 779.67232,-204.96351 775.95427,-203.83731 774.40625,-203.5625 C 772.94163,-203.30248 771.34667,-203.67904 771.0625,-203.75 C 771.22275,-203.67035 771.44294,-203.42902 770.84375,-202.6875 C 769.97909,-201.61744 764.92723,-199.86935 762.09375,-199 C 759.27295,-198.13453 755.88625,-197.84369 751.75,-198.78125 C 747.99741,-199.63186 746.70215,-200.49772 742.875,-201.375 C 742.875,-201.375 742.875,-201.21875 742.875,-201.21875 C 746.30296,-199.98096 747.86241,-198.58645 751.25,-197.6875 C 752.88216,-197.25436 754.61704,-197.10449 756.34375,-197.125 C 755.83482,-196.74083 754.867,-196.10318 753.09375,-195.375 C 750.38741,-194.26366 746.65742,-193.06719 745.125,-192.75 C 744.3246,-192.58431 743.51269,-192.53138 742.875,-192.59375 C 742.875,-192.59375 742.875,-192.07823 742.875,-191.67146 C 742.875,-191.40639 742.875,-191.1875 742.875,-191.1875 C 743.10145,-191.33218 743.32391,-191.46011 743.59375,-191.5625 C 744.67427,-191.97248 745.76536,-191.77827 749.59375,-193.25 C 753.42218,-194.72174 754.81787,-195.25498 755.5,-195.65625 C 756.1796,-196.05603 757.11165,-196.53562 757.71875,-197.1875 C 759.5456,-197.32525 761.2895,-197.68073 762.65625,-198.1875 C 765.62437,-199.28802 767.53162,-199.99369 769.4375,-200.65625 C 771.34336,-201.31879 771.79159,-202.07112 772.84375,-202.4375 C 773.9353,-202.81761 775.03886,-202.60288 778.90625,-203.96875 C 782.7737,-205.33461 784.18941,-205.79583 784.875,-206.1875 C 785.57609,-206.58802 786.57581,-207.12048 787.1875,-207.78125 C 789.1583,-207.83591 791.00435,-208.16588 792.46875,-208.65625 C 795.47023,-209.66133 797.3949,-210.27796 799.3125,-210.90625 C 800.8511,-211.41035 801.48652,-211.95302 802.21875,-212.34375 C 802.44891,-212.47806 802.69449,-212.59748 802.96875,-212.6875 C 804.06698,-213.04798 805.1502,-212.76887 809.0625,-214 C 812.97483,-215.23113 814.42855,-215.67295 815.125,-216.03125 C 815.81888,-216.38822 816.75515,-216.82386 817.375,-217.4375 C 819.24021,-217.46016 821.01081,-217.70433 822.40625,-218.125 C 825.43668,-219.03854 827.39863,-219.5551 829.34375,-220.09375 C 831.28886,-220.63239 831.76993,-221.35827 832.84375,-221.65625 C 833.95776,-221.9654 835.06369,-221.64886 839.03125,-222.6875 C 842.99886,-223.72613 844.44883,-224.12023 845.15625,-224.4375 C 845.89112,-224.76709 846.97008,-225.19122 847.59375,-225.8125 C 849.59149,-225.6965 851.45118,-225.83259 852.9375,-226.1875 C 856.01561,-226.9225 858.02094,-227.28844 860,-227.6875 C 861.58792,-228.00768 862.24429,-228.47805 863,-228.78125 C 863.23757,-228.88805 863.46695,-228.97401 863.75,-229.03125 C 864.88347,-229.26044 866.05448,-228.82232 870.09375,-229.53125 C 874.13308,-230.24018 875.594,-230.45834 876.3125,-230.71875 C 877.02836,-230.97819 878.01678,-231.28599 878.65625,-231.8125 C 880.58052,-231.57301 882.40413,-231.58797 883.84375,-231.8125 C 886.97008,-232.30012 888.9983,-232.51317 891,-232.78125 C 893.00171,-233.04932 893.48869,-233.72639 894.59375,-233.875 C 895.74014,-234.02918 896.86967,-233.57343 900.9375,-234.09375 C 905.00534,-234.61407 906.49763,-234.78948 907.21875,-235.03125 C 907.95585,-235.27839 909.01684,-235.61748 909.65625,-236.15625 C 911.70632,-235.82072 913.63003,-235.75829 915.15625,-235.9375 C 918.29856,-236.30646 920.33619,-236.49686 922.34375,-236.71875 C 923.95451,-236.89677 924.60842,-237.32695 925.375,-237.5625 C 925.61594,-237.64802 925.86912,-237.7181 926.15625,-237.75 C 927.30603,-237.87772 928.45754,-237.40335 932.53125,-237.875 C 936.60499,-238.34665 938.09034,-238.4856 938.8125,-238.71875 C 939.53196,-238.95102 940.51274,-239.19221 941.15625,-239.6875 C 943.09262,-239.35404 944.92631,-239.28326 946.375,-239.4375 C 949.52102,-239.77245 951.55256,-239.95609 953.5625,-240.15625 C 955.57246,-240.35639 956.04664,-240.98264 957.15625,-241.09375 C 958.30739,-241.20903 959.45268,-240.72869 963.53125,-241.15625 C 967.60986,-241.58381 969.12011,-241.71834 969.84375,-241.9375 C 970.5829,-242.16136 971.63947,-242.45075 972.28125,-242.96875 C 974.33835,-242.57008 976.28312,-242.47535 977.8125,-242.625 C 980.96123,-242.9331 982.98834,-243.09825 985,-243.28125 C 986.61407,-243.42807 987.2631,-243.8418 988.03125,-244.0625 C 988.27267,-244.14336 988.52478,-244.19241 988.8125,-244.21875 C 989.96461,-244.3242 991.10546,-243.826 995.1875,-244.21875 C 999.26958,-244.6115 1000.7764,-244.74959 1001.5,-244.96875 C 1002.2209,-245.18708 1003.1997,-245.41645 1003.8438,-245.90625 C 1005.7818,-245.55626 1007.6126,-245.45187 1009.0625,-245.59375 C 1012.2112,-245.90185 1014.2383,-246.067 1016.25,-246.25 C 1018.2616,-246.43299 1018.7642,-247.08802 1019.875,-247.1875 C 1021.0273,-247.29073 1022.1672,-246.80267 1026.25,-247.1875 C 1030.3329,-247.57232 1031.8387,-247.6885 1032.5625,-247.90625 C 1033.3018,-248.12868 1034.3581,-248.42074 1035,-248.9375 C 1037.0574,-248.53573 1039.0029,-248.43417 1040.5313,-248.59375 C 1043.6779,-248.92227 1045.7084,-249.11645 1047.7188,-249.3125 C 1049.3318,-249.46979 1049.9844,-249.94398 1050.75,-250.1875 C 1050.9907,-250.27554 1051.2132,-250.30887 1051.5,-250.34375 C 1052.6483,-250.48345 1053.8167,-250.00384 1057.875,-250.59375 C 1061.9333,-251.18367 1063.4368,-251.37089 1064.1563,-251.625 C 1064.873,-251.87816 1065.8308,-252.18307 1066.4688,-252.71875 C 1068.3885,-252.50681 1070.1887,-252.56734 1071.625,-252.8125 C 1074.7441,-253.3449 1076.7366,-253.74111 1078.7188,-254.125 C 1080.7009,-254.50887 1081.1931,-255.16465 1082.2813,-255.40625 C 1083.4101,-255.65691 1084.5516,-255.28996 1088.5313,-256.28125 C 1092.5109,-257.27253 1093.9609,-257.70055 1094.6563,-258.0625 C 1095.3786,-258.43851 1096.4182,-258.93308 1097.0313,-259.59375 C 1098.9943,-259.6058 1100.825,-259.8848 1102.25,-260.4375 C 1105.2012,-261.58211 1107.1232,-262.30692 1108.9375,-263.1875 C 1110.3932,-263.89403 1111.2723,-264.87391 1111.4844,-265.17188 C 1111.6966,-265.46984 1111.5962,-265.91718 1111.6223,-265.93863 C 1111.6652,-265.97387 1111.9416,-266.0236 1112.1013,-266.36707 C 1112.9602,-268.21415 1114.4223,-272.01166 1114.5365,-272.69652 C 1114.6502,-273.37868 1114.7003,-274.04426 1114.751,-274.44149 C 1114.7804,-274.67101 1114.6043,-275.30693 1114.6264,-275.36553 C 1114.6573,-275.44759 1114.9309,-275.63081 1114.9863,-275.88024 C 1115.2526,-277.07857 1115.0752,-278.07153 1114.8612,-279.48917 C 1114.6472,-280.90681 1113.8775,-284.11131 1113.2243,-284.96543 C 1112.5654,-285.82715 1112.0014,-285.9766 1111.4764,-285.96609 C 1111.2678,-285.69633 1111.6132,-285.703 1111.639,-285.65348 C 1112.3196,-285.60269 1112.573,-285.28484 1113.0582,-284.75686 C 1113.5434,-284.22888 1114.28,-280.90569 1114.4166,-279.4553 C 1114.5532,-278.00491 1114.6066,-276.5951 1114.3286,-275.98666 C 1114.0505,-275.37821 1113.6054,-275.46963 1113.313,-275.40375 C 1113.844,-275.21786 1113.9828,-275.27892 1114.0444,-274.43446 C 1114.1037,-273.62108 1113.9112,-272.79477 1113.5246,-271.62884 C 1113.1334,-270.44883 1111.6794,-267.27886 1111.2389,-267.03007 C 1110.7866,-266.77456 1110.5075,-266.75969 1110.1719,-266.89063 z" | ||
2648 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7337);enable-background:new" | ||
2649 | sodipodi:nodetypes="cssscscsscsssccscssssssscscsscsssscscssssssscscsscsssscscssssssscscsscsssscscssssssscscsscsssscscssssssscscsscsssccscsscscssscssssscsssssscssssscsssssscssssscsssssscssssscsssssscssssscsssssscssssscsszsszssszzcczzzczzzc" /> | ||
2650 | <path | ||
2651 | id="path8183" | ||
2652 | d="M 988.75,-263.84375 C 990.66161,-263.20935 993.30027,-262.08534 994.875,-261.03125 C 996.44977,-259.97716 997.7711,-259.54873 1000.4063,-257.65625 C 1003.0145,-255.78311 1005.4332,-254.64103 1007.7188,-253.59375 C 1010.1881,-252.46228 1013.4709,-251.43901 1017.25,-249.65625 C 1016.0428,-250.91465 1010.111,-253.0207 1008.2188,-253.84375 C 1006.3266,-254.66679 1004.0908,-255.77424 1001.2813,-257.625 C 998.47169,-259.47575 997.65906,-260.10654 995.28125,-261.34375 C 992.90343,-262.58094 991.20137,-263.29295 988.75,-263.84375 z" | ||
2653 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7297);enable-background:new" /> | ||
2654 | <path | ||
2655 | id="path8185" | ||
2656 | d="M 957.5,-260.78125 C 959.41,-260.16315 962.08288,-259.07191 963.65625,-258.03125 C 965.22964,-256.99059 966.55233,-256.54873 969.1875,-254.65625 C 971.79573,-252.7831 974.21442,-251.64104 976.5,-250.59375 C 978.96931,-249.46228 982.25213,-248.439 986.03125,-246.65625 C 984.82397,-247.91465 978.82971,-250.05195 976.9375,-250.875 C 975.04533,-251.69804 972.84084,-252.8055 970.03125,-254.65625 C 967.22167,-256.507 966.4383,-257.09557 964.0625,-258.3125 C 961.68672,-259.52941 959.94929,-260.25135 957.5,-260.78125 z" | ||
2657 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7301);enable-background:new" /> | ||
2658 | <path | ||
2659 | id="path8187" | ||
2660 | d="M 926.09375,-257.375 C 928.00147,-256.77755 930.64723,-255.71116 932.21875,-254.6875 C 933.79025,-253.66385 935.08897,-253.24779 937.71875,-251.40625 C 940.32166,-249.58352 942.74762,-248.43405 945.03125,-247.40625 C 947.49845,-246.29584 950.7866,-245.31302 954.5625,-243.5625 C 953.35627,-244.8106 947.3906,-246.88059 945.5,-247.6875 C 943.60942,-248.4944 941.39758,-249.57854 938.59375,-251.375 C 935.7899,-253.17144 934.96671,-253.77751 932.59375,-254.96875 C 930.22078,-256.15999 928.54013,-256.87158 926.09375,-257.375 z" | ||
2661 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7305);enable-background:new" /> | ||
2662 | <path | ||
2663 | id="path8189" | ||
2664 | d="M 894.90625,-253.5625 C 896.80838,-253.00895 899.49326,-251.97363 901.0625,-250.96875 C 902.63173,-249.96388 903.93651,-249.56011 906.5625,-247.75 C 909.16162,-245.95836 911.56284,-244.87811 913.84375,-243.875 C 916.30803,-242.79126 919.60359,-241.83471 923.375,-240.125 C 922.1702,-241.36007 916.20084,-243.36978 914.3125,-244.15625 C 912.42418,-244.94272 910.2373,-245.98705 907.4375,-247.75 C 904.63773,-249.51294 903.83831,-250.11836 901.46875,-251.28125 C 899.09918,-252.44413 897.3455,-253.11537 894.90625,-253.5625 z" | ||
2665 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7309);enable-background:new" /> | ||
2666 | <path | ||
2667 | id="path8191" | ||
2668 | d="M 863.71875,-248.65625 C 865.59937,-248.22716 868.22302,-247.27587 869.78125,-246.34375 C 871.33948,-245.41164 872.63358,-245.08599 875.25,-243.34375 C 877.83971,-241.61931 880.23067,-240.63573 882.5,-239.71875 C 884.95176,-238.72806 888.23959,-237.84168 892,-236.21875 C 890.79869,-237.42609 884.84751,-239.28484 882.96875,-240 C 881.09,-240.71517 878.88335,-241.68442 876.09375,-243.375 C 873.30412,-245.06557 872.50914,-245.60322 870.15625,-246.65625 C 867.80333,-247.70926 866.13041,-248.36873 863.71875,-248.65625 z" | ||
2669 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7313);enable-background:new" /> | ||
2670 | <path | ||
2671 | id="path8193" | ||
2672 | d="M 833.15625,-241.375 C 835.00461,-241.07856 837.6257,-240.39868 839.15625,-239.59375 C 840.68683,-238.78882 841.96999,-238.53802 844.53125,-237.0625 C 847.06629,-235.60204 849.42193,-234.73741 851.65625,-234 C 854.07024,-233.20332 857.31336,-232.53311 861.03125,-231.15625 C 859.84354,-232.28498 853.94353,-233.746 852.09375,-234.3125 C 850.24398,-234.879 848.09033,-235.68642 845.34375,-237.15625 C 842.59718,-238.62608 841.84239,-239.07653 839.53125,-239.9375 C 837.2201,-240.79845 835.52654,-241.25759 833.15625,-241.375 z" | ||
2673 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7317);enable-background:new" /> | ||
2674 | <path | ||
2675 | id="path8195" | ||
2676 | d="M 802.90625,-232.3125 C 804.72845,-232.10123 807.27201,-231.51193 808.78125,-230.78125 C 810.2905,-230.05059 811.53693,-229.85127 814.0625,-228.5 C 816.56226,-227.16254 818.89404,-226.45157 821.09375,-225.84375 C 823.47028,-225.18708 826.65839,-224.77087 830.3125,-223.65625 C 829.14515,-224.70121 823.38362,-225.75954 821.5625,-226.21875 C 819.74139,-226.67796 817.61025,-227.34571 814.90625,-228.65625 C 812.20222,-229.96677 811.43519,-230.37615 809.15625,-231.125 C 806.8773,-231.87383 805.243,-232.30431 802.90625,-232.3125 z" | ||
2677 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7321);enable-background:new" /> | ||
2678 | <path | ||
2679 | id="path8197" | ||
2680 | d="M 773.1875,-222.1875 C 774.99859,-222.0088 777.50809,-221.52244 779,-220.84375 C 780.49194,-220.16506 781.7534,-220.04553 784.25,-218.78125 C 786.72107,-217.52987 789.04005,-216.88511 791.21875,-216.34375 C 793.57262,-215.75887 796.71009,-215.44623 800.3125,-214.5 C 799.16166,-215.49116 793.45999,-216.2833 791.65625,-216.6875 C 789.85253,-217.0917 787.74072,-217.70866 785.0625,-218.9375 C 782.38432,-220.16634 781.65905,-220.54839 779.40625,-221.21875 C 777.15346,-221.88909 775.50998,-222.22107 773.1875,-222.1875 z" | ||
2681 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7329);enable-background:new" /> | ||
2682 | <path | ||
2683 | id="path8199" | ||
2684 | d="M 743.5625,-211.1875 C 745.35531,-211.05839 747.83563,-210.63785 749.3125,-210 C 750.7894,-209.36215 752.0286,-209.25844 754.5,-208.0625 C 756.94618,-206.87878 759.22054,-206.31584 761.375,-205.84375 C 763.70267,-205.33372 766.7946,-205.16311 770.375,-204.28125 C 769.23121,-205.25185 763.62741,-205.8719 761.84375,-206.21875 C 760.06008,-206.56559 757.9609,-207.10631 755.3125,-208.25 C 752.66409,-209.39368 751.91755,-209.76631 749.6875,-210.375 C 747.45742,-210.98368 745.86156,-211.28466 743.5625,-211.1875 z" | ||
2685 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;filter:url(#filter7325);enable-background:new" /> | ||
2686 | </g> | ||
2687 | </g> | ||
2688 | <path | ||
2689 | style="opacity:1;fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2690 | d="M 863.87812,475.6679 C 865.52024,472.4499 867.39593,469.93261 868.73948,465.81892 C 869.5382,462.16103 872.05152,463.78819 875.99995,457.42202 C 877.40188,455.18252 881.47648,457.81338 884.96505,455.02291 C 886.23577,454.21972 887.84993,454.6186 889.44761,454.95978 C 893.213,456.27874 895.27337,458.66333 897.78137,460.76815 C 903.92043,466.73838 918.31551,468.71142 921.26741,467.08161 C 922.70146,464.17687 929.14869,461.67273 933.64178,455.96993 C 934.38989,454.84726 945.37114,447.22547 948.28899,449.40394" | ||
2691 | id="path8201" | ||
2692 | sodipodi:nodetypes="ccccccccc" /> | ||
2693 | <path | ||
2694 | style="opacity:1;fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2695 | d="M 888.50059,465.25071 C 895.864,462.01774 902.31149,456.34231 909.20872,451.86619 C 912.51929,449.89665 916.07855,455.0822 920.00472,455.46485 C 922.30245,455.24672 923.71762,456.66744 925.68683,457.10635 C 930.84319,458.42414 928.08476,460.97123 935.66209,463.54607 C 941.8177,465.26647 944.56949,456.7476 950.56184,456.22247 C 955.43923,455.71948 958.66076,455.90644 962.17859,455.96993 C 966.10555,456.10882 966.25714,452.47233 968.23951,450.66663 C 971.22007,447.86141 975.39512,448.81691 978.38436,445.92573 C 979.4019,444.54105 980.33894,442.91488 981.11895,440.81764 C 982.00096,438.8173 984.15901,441.12362 985.91718,442.08033" | ||
2696 | id="path8203" | ||
2697 | sodipodi:nodetypes="ccccccccccc" /> | ||
2698 | </g> | ||
2699 | <g | ||
2700 | inkscape:groupmode="layer" | ||
2701 | id="layer15" | ||
2702 | inkscape:label="Feet" | ||
2703 | style="display:inline"> | ||
2704 | <path | ||
2705 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter9048);enable-background:accumulate" | ||
2706 | d="M 403.27922,1056.3058 L 459.84776,1013.8794 L 531.97265,1028.0215 L 485.30361,1080.3474 L 431.56349,1087.4185 L 403.27922,1056.3058 z" | ||
2707 | id="path8994" /> | ||
2708 | <path | ||
2709 | style="opacity:1;fill:#ada469;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2710 | d="M 542.27183,1060.5719 C 540.86456,1079.3731 541.12693,1093.3229 544.35357,1109.8752 C 547.58023,1126.4275 560.75966,1155.7825 564.68798,1173.0589 C 568.61419,1190.326 567.38211,1211.3686 552.22854,1224.2072 C 536.91093,1237.1846 510.17726,1245.8061 484.39623,1239.9409 C 458.61518,1234.0757 414.84716,1190.7175 395.80604,1169.7126 C 376.6939,1148.6293 332.04518,1075.862 317.86751,1045.4368 C 303.68984,1015.0117 305.2079,1008.7182 309.74779,999.90708 C 300.38107,975.38658 297.33408,949.84027 276.03534,924.33044 C 306.36081,927.44488 319.91562,951.28677 336.16102,971.47019 C 330.63113,923.39416 318.10631,907.05369 307.78707,880.74589 C 337.78137,886.82754 358.36643,912.61828 371.76686,953.45839 C 381.32101,949.54048 390.00462,944.08545 401.95427,944.39719 C 390.65677,902.70139 384.00481,874.48135 365.26702,843.32725 C 418.70898,848.99758 448.92404,923.96657 444.23844,931.28805 C 454.21641,929.04406 463.24409,924.75767 474.67497,925.63638 C 463.426,887.28936 453.62716,848.76848 471.01526,806.98819 C 471.01526,806.98819 519.30204,872.42507 525.40492,892.79397 C 531.50779,913.16287 526.92373,931.49448 526.92373,931.49448 C 526.92373,931.49448 543.8833,962.57978 547.21765,982.58862 C 550.59075,1002.83 543.68496,1041.6919 542.27183,1060.5719 z" | ||
2711 | id="path4189" | ||
2712 | sodipodi:nodetypes="czzzzzzcccccccccczczz" /> | ||
2713 | <path | ||
2714 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter3587);enable-background:accumulate" | ||
2715 | d="M 719.5,738.69519 L 737.81177,754.12715 L 782.2228,738.73894 L 805.5,713.19519 L 816.96397,732.41584 L 847.63558,745.19938 L 872.73295,750.92775 L 892,723.19519 L 908.02309,747.02126 L 947,752.19519 L 957.24541,745.99667 L 964.00012,754.69487 L 989.5,765.69519 L 991.5,725.19519 L 955.94866,710.6576 L 923.45591,689.1305 L 883.0038,677.66492 L 861.69668,662.13148 L 840,685.19519 L 755.02878,638.61208 L 722,676.69519 L 719.5,738.69519 z" | ||
2716 | id="path4191" | ||
2717 | sodipodi:nodetypes="cccccccccccccccccccccc" | ||
2718 | clip-path="url(#clipPath3631)" | ||
2719 | transform="matrix(-0.9045327,0.2506626,0.2506626,0.9045327,995.28646,23.53493)" /> | ||
2720 | <path | ||
2721 | style="opacity:0.58775509;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:20.79999924;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline;filter:url(#filter3898);enable-background:new" | ||
2722 | d="M 584,696.5 L 577.4375,713.65625 C 577.4375,713.65625 569.62598,734.02113 561.75,757.3125 C 557.81201,768.95818 553.86698,781.35395 550.8125,792.4375 C 547.75802,803.52105 545.47664,812.81736 545.3125,820.71875 C 544.91443,839.88071 551.05903,855.60705 554.25,862.46875 C 553.47847,866.02398 552.25863,871.92307 550.90625,880.5625 C 548.98583,892.83071 547.18798,907.71691 548.53125,920.4375 C 549.91334,933.52585 555.34347,948.62515 561.125,963.46875 C 566.90653,978.31235 573.17935,992.69586 576.34375,1001.5 C 582.97581,1019.9519 586.33671,1033.0763 587.65625,1050 C 588.2376,1057.4561 587.41398,1070.336 586.40625,1083.375 C 585.39852,1096.414 584.21964,1109.6764 584.71875,1120.3438 C 585.70786,1141.4836 594.04673,1167.1785 618.09375,1178.2812 C 640.86858,1188.7966 673.42057,1189.9834 701.53125,1174.8438 C 717.69117,1166.1404 731.60759,1147.7462 744.90625,1127.9375 C 758.20491,1108.1288 769.87542,1086.8841 776.84375,1073.0312 C 792.19667,1042.51 816.23728,957.56702 822.46875,920.3125 C 825.48734,902.26597 826.39041,891.24695 825.09375,882.28125 C 824.11522,875.51521 821.26556,870.13385 818.21875,866.0625 C 820.26149,838.55459 817.48668,814.69372 830.1875,786.65625 L 840.75,763.375 L 816.9375,772.6875 C 799.44775,779.52503 788.03586,791.73286 780.34375,804.75 C 780.02124,805.29577 779.78061,805.85776 779.46875,806.40625 C 779.69078,783.89104 783.87659,768.76866 786.0625,747.71875 L 788.03125,728.71875 L 771,737.375 C 740.40551,752.93071 725.30511,785.56821 721.28125,827.59375 C 717.03593,826.96828 712.44985,826.5741 707.46875,826.75 C 707.17726,787.56964 707.07246,759.71315 716.0625,727.375 L 721.65625,707.25 L 702.21875,714.90625 C 671.30938,727.11019 654.35921,756.83698 645.59375,783.28125 C 641.21102,796.50339 638.84793,809.08246 638,819.21875 C 637.76797,821.99248 637.68894,824.53007 637.6875,826.9375 C 634.44563,826.90109 631.26698,827.07339 627.625,827.4375 C 627.66662,788.43277 624.14076,747.68335 595.34375,710.9375 L 584,696.5 z M 589.8125,740.3125 C 606.61941,770.95633 607.28701,804.27978 606.75,840.0625 L 606.53125,855.125 L 618.56618,848.58579 C 627.22823,845.45277 638.12676,848.35827 650.5,847.75 L 665.17465,857.1066 L 658.84375,831.3125 C 658.7541,831.08253 658.62329,830.89581 658.59375,830.59375 C 658.39424,828.55389 658.37143,825.12068 658.71875,820.96875 C 659.41339,812.66489 661.50832,801.38351 665.34375,789.8125 C 670.49907,774.25956 678.83176,758.62002 690.46875,747.28125 C 685.78494,775.91923 687.25316,807.54059 687.45711,843.08639 L 684.69118,856.34803 L 700.1875,848.75 C 709.2169,845.99229 717.37647,848.40004 729.46875,849.84375 L 742.71507,859.28798 L 741.09375,840 C 742.54168,809.02823 749.31524,786.32192 761.8125,771.125 C 758.82562,790.90384 756.38207,812.9098 762.125,849.46875 L 763.19052,855.84193 L 760.25237,867.35878 L 770.86948,859.1906 L 780.05921,869.41258 L 778.51093,858.94898 L 781.9375,852 C 787.63852,838.78851 792.11032,825.78663 798.28125,815.34375 C 799.24111,813.71941 800.31278,812.27939 801.34375,810.78125 C 797.66309,831.9366 798.91659,850.9894 797.25,868.5625 L 792.56986,876.36948 L 799.96875,876.59375 C 803.1888,880.07736 803.83625,880.44443 804.53125,885.25 C 805.22625,890.05557 804.84987,899.65035 801.96875,916.875 C 796.40076,950.16292 770.12313,994.71481 758.22835,1018.3614 C 751.62344,1031.4918 739.70002,1075.8473 727.105,1094.6079 C 714.50998,1113.3684 698.57363,1134.3752 689.93296,1139.0288 C 668.44244,1150.603 645.37702,1164.5347 629.31407,1157.1183 C 614.93921,1150.4813 606.27438,1135.9256 605.5,1119.375 C 605.11689,1111.187 606.11279,1098.0658 607.125,1084.9688 C 608.13721,1071.8717 618.41391,1062.398 622.54839,1048.4062 C 627.92068,1030.2254 621.10152,1011.8118 610.04839,994.46875 C 603.56184,984.29097 586.07159,970.21085 580.5,955.90625 C 574.92841,941.60165 570.13249,926.9031 569.21875,918.25 C 568.29254,909.47887 569.64125,895.22498 571.4375,883.75 C 573.23375,872.27503 575.28125,863.46875 575.28125,863.46875 L 584.70403,859.85355 L 574.21875,855.96875 C 574.21875,855.96875 565.71986,840.65865 566.125,821.15625 C 566.19611,817.73309 567.96126,808.4282 570.84375,797.96875 C 573.72624,787.5093 577.60841,775.41604 581.46875,764 C 584.51314,754.99692 587.24938,747.39655 589.8125,740.3125 z" | ||
2723 | id="path4193" | ||
2724 | clip-path="url(#clipPath3677)" | ||
2725 | sodipodi:nodetypes="ccssscsssssssssssssccccscccccccccsscccccccccccssscccccccccccccccsccccssssssssssssscccsssc" | ||
2726 | transform="matrix(-0.9045327,0.2506626,0.2506626,0.9045327,822.28931,10.93589)" /> | ||
2727 | <g | ||
2728 | id="g3617" | ||
2729 | clip-path="url(#clipPath3622)" | ||
2730 | transform="translate(276,136)"> | ||
2731 | <path | ||
2732 | transform="matrix(-0.9045327,0.2506626,0.2506626,0.9045327,-52.200498,74.09707)" | ||
2733 | id="path4195" | ||
2734 | d="M -15.66751,843.48852 L -65.16499,827.93217 L -92.03504,880.25807 L -51.02285,925.51291 L -1.52538,887.32914 L -15.66751,843.48852 z" | ||
2735 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter9024);enable-background:accumulate" /> | ||
2736 | <path | ||
2737 | sodipodi:nodetypes="ccccccccccccc" | ||
2738 | transform="matrix(-0.9045327,0.2506626,0.2506626,0.9045327,-46.92842,75.511284)" | ||
2739 | id="path4197" | ||
2740 | d="M 118.70648,859.93048 L 63.552152,813.26144 L 19.711532,850.03099 L 53.652662,903.7711 L 40.055848,989.23313 L 0.61048221,1017.5253 L -40.401718,1028.839 L -43.230138,1075.508 L 13.338402,1100.9639 L 32.282389,1031.3139 L 55.738939,972.45727 L 102.08648,899.84236 L 118.70648,859.93048 z" | ||
2741 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter9020);enable-background:accumulate" /> | ||
2742 | </g> | ||
2743 | <path | ||
2744 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter9044);enable-background:accumulate" | ||
2745 | d="M -70.82184,932.58397 L -10.01066,905.71392 L 90.3985,936.82662 L 26.75889,967.93931 L -55.26549,950.96875 L -70.82184,932.58397 z" | ||
2746 | id="path4199" | ||
2747 | transform="matrix(-0.9045327,0.2506626,0.2506626,0.9045327,229.07158,211.51128)" /> | ||
2748 | <path | ||
2749 | style="opacity:0.58775509;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:20.79999924;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline;filter:url(#filter4105);enable-background:new" | ||
2750 | d="M 583.0625,715.75 C 570.95641,750.19974 556.348,784.28333 551.3125,820.59375 C 550.48042,835.52242 555.90165,849.75318 560.15625,863.65625 C 554.24001,890.85751 550.01944,920.5562 561.3125,946.78125 C 574.82967,984.9421 596.31397,1022.4634 593.73529,1064.2495 C 592.78699,1093.5437 584.72085,1125.2436 599.125,1152.5312 C 609.32364,1171.866 632.26456,1179.8429 653.09285,1180.1988 C 680.95504,1181.3729 709.55546,1168.5772 725.09375,1144.9375 C 747.68924,1115.5658 766.89426,1083.4402 780.3324,1048.8777 C 797.22293,1003.3717 810.0042,956.31698 818.26642,908.4788 C 820.09082,895.53774 821.3675,881.00895 813.6875,869.65625 C 810.25635,862.31993 813.72957,854.09611 813.00293,846.34648 C 813.67693,821.35182 817.01525,795.68272 829.65625,773.75 C 811.92312,780.1946 794.58357,790.30971 785.65318,807.61425 C 781.7181,814.3238 778.04836,821.18838 774.28125,828 C 770.73126,797.98592 778.00088,768.35172 781.0625,738.71875 C 760.89646,747.77338 744.18578,764.37397 736.88755,785.40075 C 730.58292,800.98078 728.08533,817.71793 726.625,834.4375 C 718.37166,832.91825 709.94053,832.33595 701.5625,832.9375 C 700.59942,794.23963 701.09554,753.53035 712.53125,717.03125 C 693.85012,723.24901 677.36504,735.76676 666.90322,752.41848 C 653.05068,773.29827 645.64182,798.17243 643.84375,823.03125 C 644.42909,827.35579 643.78249,834.87134 637.5,832.90625 C 632.16882,832.9238 626.87092,833.58508 621.5625,834 C 622.71034,794.61852 618.22106,752.3718 594.5,719.78125 C 591.43929,716.14408 588.86315,712.09687 585.875,708.4375 C 584.9375,710.875 584,713.3125 583.0625,715.75 z M 590.8125,729.59375 C 609.37777,758.89004 613.295,794.41387 612.9375,828.46875 C 613.14159,833.64401 612.42094,840.29795 613.0625,844.53125 C 625.38106,838.4285 639.80162,842.09135 652.84375,842.34375 C 655.16087,843.567 656.03585,843.99618 654.75,840.9375 C 650.58545,826.98465 652.90172,812.3245 656.55504,798.52986 C 662.92191,772.23922 677.18332,747.44188 699.375,731.5 C 690.75791,768.73706 693.65842,808.06161 693.28125,845.46875 C 705.53469,838.55885 720.56004,842.02262 733.3125,845.21875 C 736.70472,848.75355 735.60185,844.48927 735.5,841.40625 C 735.01691,820.03567 739.63133,798.33662 749.1875,779.25 C 755.15016,768.56273 763.43088,759.44621 771.625,750.375 C 763.75344,784.2131 762.4221,819.71093 768.90625,853.875 C 770.6311,852.46382 773.51306,853.42086 774.5625,853.5 C 784.24619,832.26318 790.91362,808.11938 809.45266,792.75815 C 811.32595,792.38693 808.00448,801.2831 807.96875,804.65625 C 804.43387,826.50206 800.79359,848.79859 799.18454,870.87536 C 790.40075,873.21707 802.03289,873.1989 802.65329,874.93786 C 810.5764,885.50366 807.31628,899.34258 806.28494,911.2912 C 799.22089,956.32475 784.14263,998.65314 770.33139,1041.971 C 758.25663,1074.9203 742.95719,1100.8235 722.44331,1129.1725 C 711.49074,1142.7239 699.19859,1157.0238 681.59956,1161.6725 C 661.44355,1167.9138 637.3928,1172.5494 619,1161.7188 C 601.71034,1149.3774 597.97607,1126.0099 599.73774,1106.0324 C 599.78653,1090.2062 604.6766,1077.5203 604.14834,1062.5406 C 603.6101,1047.2777 601.85699,1031.9759 597.60573,1015.6743 C 593.35447,999.37268 588.56248,990.75636 581.48667,974.10092 C 574.24556,957.05636 566.41652,937.35229 563.28125,917.8125 C 561.53177,899.18536 566.17296,880.68988 569.0625,862.5625 C 572.35873,859.72554 567.46451,857.36591 566.75,854.375 C 559.14887,837.35992 558.34253,817.6001 564.00766,799.81502 C 571.13786,774.74272 579.76853,750.18261 588.6875,725.6875 C 589.39583,726.98958 590.10417,728.29167 590.8125,729.59375 z" | ||
2751 | id="path4201" | ||
2752 | sodipodi:nodetypes="ccccccccccccccccccccccccccccccccccccccccccccccccccczzzcccccc" | ||
2753 | clip-path="url(#clipPath4177)" | ||
2754 | transform="matrix(-0.9045327,0.2506626,0.2506626,0.9045327,822.28931,10.93589)" /> | ||
2755 | <path | ||
2756 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter4130);enable-background:accumulate" | ||
2757 | d="M 735.05635,733.03834 L 737.81177,754.12715 L 782.2228,738.73894 L 787.07343,716.34919 L 783.13726,694.29697 L 760.68563,657.70396 L 752.40559,688.0089 L 735.05635,733.03834 z" | ||
2758 | id="path4203" | ||
2759 | sodipodi:nodetypes="cccccccc" | ||
2760 | clip-path="url(#clipPath3631)" | ||
2761 | transform="matrix(-0.9045327,0.2506626,0.2506626,0.9045327,995.28646,23.53493)" /> | ||
2762 | <path | ||
2763 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter4141);enable-background:accumulate" | ||
2764 | d="M 831.81321,730.29452 L 847.63558,745.19938 L 868.49031,748.09932 L 866.90002,708.17334 L 875.22563,677.66492 L 868.06064,671.32386 L 846.36395,692.26626 L 831.81321,730.29452 z" | ||
2765 | id="path4205" | ||
2766 | sodipodi:nodetypes="cccccccc" | ||
2767 | clip-path="url(#clipPath3631)" | ||
2768 | transform="matrix(-0.9045327,0.2506626,0.2506626,0.9045327,995.28646,23.53493)" /> | ||
2769 | <g | ||
2770 | id="g8317" | ||
2771 | style="filter:url(#filter8333)" | ||
2772 | clip-path="url(#clipPath8338)" | ||
2773 | transform="translate(276,136)"> | ||
2774 | <path | ||
2775 | transform="matrix(-0.9045327,0.2506626,0.2506626,0.9045327,719.28646,-112.46507)" | ||
2776 | clip-path="none" | ||
2777 | sodipodi:nodetypes="ccccc" | ||
2778 | id="path4209" | ||
2779 | d="M 964.00012,754.69487 L 982.42893,762.15966 L 991.5,725.19519 L 976.62969,730.03405 L 964.00012,754.69487 z" | ||
2780 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
2781 | <rect | ||
2782 | y="757.19519" | ||
2783 | x="-55" | ||
2784 | height="177" | ||
2785 | width="182" | ||
2786 | id="rect8315" | ||
2787 | style="opacity:1;fill:none;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:25;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
2788 | </g> | ||
2789 | <g | ||
2790 | id="g8346" | ||
2791 | style="filter:url(#filter8354)" | ||
2792 | clip-path="url(#clipPath8359)" | ||
2793 | transform="translate(276,136)"> | ||
2794 | <path | ||
2795 | transform="matrix(-0.9045327,0.2506626,0.2506626,0.9045327,719.28646,-112.46507)" | ||
2796 | clip-path="none" | ||
2797 | sodipodi:nodetypes="ccccccc" | ||
2798 | id="path4207" | ||
2799 | d="M 910.14441,746.31415 L 942.75736,751.48808 L 942.39617,727.61189 L 949.5847,697.92968 L 941.13358,692.66603 L 919.31164,719.1768 L 910.14441,746.31415 z" | ||
2800 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
2801 | <rect | ||
2802 | y="696.19519" | ||
2803 | x="-22" | ||
2804 | height="176" | ||
2805 | width="165" | ||
2806 | id="rect8344" | ||
2807 | style="opacity:1;fill:none;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:25;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
2808 | </g> | ||
2809 | </g> | ||
2810 | <g | ||
2811 | inkscape:groupmode="layer" | ||
2812 | id="layer16" | ||
2813 | inkscape:label="Left Foot" | ||
2814 | style="display:inline"> | ||
2815 | <path | ||
2816 | style="opacity:1;fill:#ada469;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline;enable-background:new" | ||
2817 | d="M 1036.164,1071.8338 C 1042.9581,1090.7366 1046.6577,1105.1335 1048.0543,1123.0457 C 1049.4509,1140.958 1044.2716,1174.8465 1045.1538,1193.7018 C 1046.0356,1212.547 1053.2875,1233.8008 1072.4984,1242.6707 C 1091.9173,1251.6365 1121.8177,1252.882 1146.6183,1239.5251 C 1171.4189,1226.1681 1204.0193,1169.1996 1217.5925,1142.2164 C 1231.2164,1115.1325 1256.3536,1027.719 1262.2533,992.44781 C 1268.1531,957.1766 1264.8039,951.14704 1257.6359,943.39232 C 1260.2762,915.55217 1256.1361,888.45689 1270.7455,856.20614 C 1240.4965,868.03184 1233.3632,896.36684 1222.4266,921.71122 C 1214.4257,870.77829 1222.6358,850.43803 1225.7455,820.49186 C 1196.6808,835.26977 1182.884,867.60588 1180.7455,913.349 C 1169.8216,912.0448 1159.3541,908.91477 1147.1741,912.63471 C 1146.9101,866.61137 1145.7106,835.7453 1156.0847,798.42822 C 1102.8293,819.45508 1093.1375,905.02232 1100.0312,911.20614 C 1089.1484,911.74114 1078.6602,909.90884 1067.1741,914.06329 C 1067.813,871.49194 1066.9136,829.15468 1037.1741,791.20614 C 1037.1741,791.20614 1006.2161,872.12848 1005.7455,894.77757 C 1005.275,917.42666 1015.1971,934.94345 1015.1971,934.94345 C 1015.1971,934.94345 1006.6291,971.68396 1008.8985,993.17568 C 1011.1944,1014.9171 1029.3414,1052.8519 1036.164,1071.8338 z" | ||
2818 | id="path8848" | ||
2819 | sodipodi:nodetypes="czzzzzzcccccccccczczz" /> | ||
2820 | <path | ||
2821 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter3587);enable-background:accumulate" | ||
2822 | d="M 719.5,738.69519 L 737.81177,754.12715 L 782.2228,738.73894 L 805.5,713.19519 L 816.96397,732.41584 L 847.63558,745.19938 L 872.73295,750.92775 L 892,723.19519 L 908.02309,747.02126 L 947,752.19519 L 957.24541,745.99667 L 964.00012,754.69487 L 989.5,765.69519 L 991.5,725.19519 L 955.94866,710.6576 L 923.45591,689.1305 L 883.0038,677.66492 L 861.69668,662.13148 L 840,685.19519 L 755.02878,638.61208 L 722,676.69519 L 719.5,738.69519 z" | ||
2823 | id="path3635" | ||
2824 | sodipodi:nodetypes="cccccccccccccccccccccc" | ||
2825 | clip-path="url(#clipPath3631)" | ||
2826 | transform="translate(276,136)" /> | ||
2827 | <path | ||
2828 | transform="translate(450.03125,73.843964)" | ||
2829 | style="opacity:0.58775509;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:20.79999924;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline;filter:url(#filter3898);enable-background:new" | ||
2830 | d="M 584,696.5 L 577.4375,713.65625 C 577.4375,713.65625 569.62598,734.02113 561.75,757.3125 C 557.81201,768.95818 553.86698,781.35395 550.8125,792.4375 C 547.75802,803.52105 545.47664,812.81736 545.3125,820.71875 C 544.91443,839.88071 551.05903,855.60705 554.25,862.46875 C 553.47847,866.02398 552.25863,871.92307 550.90625,880.5625 C 548.98583,892.83071 547.18798,907.71691 548.53125,920.4375 C 549.91334,933.52585 555.34347,948.62515 561.125,963.46875 C 566.90653,978.31235 573.17935,992.69586 576.34375,1001.5 C 582.97581,1019.9519 586.33671,1033.0763 587.65625,1050 C 588.2376,1057.4561 587.41398,1070.336 586.40625,1083.375 C 585.39852,1096.414 584.21964,1109.6764 584.71875,1120.3438 C 585.70786,1141.4836 594.04673,1167.1785 618.09375,1178.2812 C 640.86858,1188.7966 673.42057,1189.9834 701.53125,1174.8438 C 717.69117,1166.1404 731.60759,1147.7462 744.90625,1127.9375 C 758.20491,1108.1288 769.87542,1086.8841 776.84375,1073.0312 C 792.19667,1042.51 816.23728,957.56702 822.46875,920.3125 C 825.48734,902.26597 826.39041,891.24695 825.09375,882.28125 C 824.11522,875.51521 821.26556,870.13385 818.21875,866.0625 C 820.26149,838.55459 817.48668,814.69372 830.1875,786.65625 L 840.75,763.375 L 816.9375,772.6875 C 799.44775,779.52503 788.03586,791.73286 780.34375,804.75 C 780.02124,805.29577 779.78061,805.85776 779.46875,806.40625 C 779.69078,783.89104 783.87659,768.76866 786.0625,747.71875 L 788.03125,728.71875 L 771,737.375 C 740.40551,752.93071 725.30511,785.56821 721.28125,827.59375 C 717.03593,826.96828 712.44985,826.5741 707.46875,826.75 C 707.17726,787.56964 707.07246,759.71315 716.0625,727.375 L 721.65625,707.25 L 702.21875,714.90625 C 671.30938,727.11019 654.35921,756.83698 645.59375,783.28125 C 641.21102,796.50339 638.84793,809.08246 638,819.21875 C 637.76797,821.99248 637.68894,824.53007 637.6875,826.9375 C 634.44563,826.90109 631.26698,827.07339 627.625,827.4375 C 627.66662,788.43277 624.14076,747.68335 595.34375,710.9375 L 584,696.5 z M 589.8125,740.3125 C 606.61941,770.95633 607.28701,804.27978 606.75,840.0625 L 606.53125,855.125 L 618.56618,848.58579 C 627.22823,845.45277 638.12676,848.35827 650.5,847.75 L 665.17465,857.1066 L 658.84375,831.3125 C 658.7541,831.08253 658.62329,830.89581 658.59375,830.59375 C 658.39424,828.55389 658.37143,825.12068 658.71875,820.96875 C 659.41339,812.66489 661.50832,801.38351 665.34375,789.8125 C 670.49907,774.25956 678.83176,758.62002 690.46875,747.28125 C 685.78494,775.91923 687.25316,807.54059 687.45711,843.08639 L 684.69118,856.34803 L 700.1875,848.75 C 709.2169,845.99229 717.37647,848.40004 729.46875,849.84375 L 742.71507,859.28798 L 741.09375,840 C 742.54168,809.02823 749.31524,786.32192 761.8125,771.125 C 758.82562,790.90384 756.38207,812.9098 762.125,849.46875 L 763.19052,855.84193 L 760.25237,867.35878 L 770.86948,859.1906 L 780.05921,869.41258 L 778.51093,858.94898 L 781.9375,852 C 787.63852,838.78851 792.11032,825.78663 798.28125,815.34375 C 799.24111,813.71941 800.31278,812.27939 801.34375,810.78125 C 797.66309,831.9366 798.91659,850.9894 797.25,868.5625 L 792.56986,876.36948 L 799.96875,876.59375 C 803.1888,880.07736 803.83625,880.44443 804.53125,885.25 C 805.22625,890.05557 804.84987,899.65035 801.96875,916.875 C 796.40076,950.16292 770.17603,1040.0409 758.28125,1063.6875 C 751.67634,1076.8179 740.25127,1097.5832 727.65625,1116.3438 C 715.06123,1135.1043 700.29692,1151.8776 691.65625,1156.5312 C 670.16573,1168.1054 642.87545,1166.7914 626.8125,1159.375 C 612.43764,1152.738 606.27438,1135.9256 605.5,1119.375 C 605.11689,1111.187 606.11279,1098.0658 607.125,1084.9688 C 608.13721,1071.8717 618.41391,1062.398 622.54839,1048.4062 C 627.92068,1030.2254 621.10152,1011.8118 610.04839,994.46875 C 603.56184,984.29097 586.07159,970.21085 580.5,955.90625 C 574.92841,941.60165 570.13249,926.9031 569.21875,918.25 C 568.29254,909.47887 569.64125,895.22498 571.4375,883.75 C 573.23375,872.27503 575.28125,863.46875 575.28125,863.46875 L 584.70403,859.85355 L 574.21875,855.96875 C 574.21875,855.96875 565.71986,840.65865 566.125,821.15625 C 566.19611,817.73309 567.96126,808.4282 570.84375,797.96875 C 573.72624,787.5093 577.60841,775.41604 581.46875,764 C 584.51314,754.99692 587.24938,747.39655 589.8125,740.3125 z" | ||
2831 | id="path3669" | ||
2832 | clip-path="url(#clipPath3677)" | ||
2833 | sodipodi:nodetypes="ccssscsssssssssssssccccscccccccccsscccccccccccssscccccccccccccccsccccssssssssssssscccsssc" /> | ||
2834 | <g | ||
2835 | id="g3628" | ||
2836 | clip-path="url(#clipPath3636)" | ||
2837 | transform="translate(276,136)"> | ||
2838 | <path | ||
2839 | id="path8988" | ||
2840 | d="M 824.48651,818.48242 L 774.98903,802.92607 L 748.11898,855.25197 L 789.13117,900.50681 L 838.62864,862.32304 L 824.48651,818.48242 z" | ||
2841 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter9024);enable-background:accumulate" /> | ||
2842 | <path | ||
2843 | id="path8990" | ||
2844 | d="M 964.49365,855.25197 L 909.33932,808.58293 L 865.4987,845.35248 L 899.43983,899.09259 L 906.51089,965.56063 L 855.59921,1000.916 L 814.58701,1012.2297 L 811.75859,1058.8987 L 868.32713,1084.3546 L 931.96674,1007.987 L 956.00837,913.23473 L 964.49365,855.25197 z" | ||
2845 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter9020);enable-background:accumulate" /> | ||
2846 | </g> | ||
2847 | <path | ||
2848 | style="opacity:0.25;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter9044);enable-background:accumulate" | ||
2849 | d="M 1045.3322,1043.5779 L 1106.1434,1016.7078 L 1206.5525,1047.8205 L 1142.9129,1078.9332 L 1060.8885,1061.9626 L 1045.3322,1043.5779 z" | ||
2850 | id="path8992" /> | ||
2851 | <path | ||
2852 | transform="translate(450.03125,73.843964)" | ||
2853 | style="opacity:0.58775509;fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:20.79999924;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;display:inline;filter:url(#filter4185);enable-background:new" | ||
2854 | d="M 583.0625,715.75 C 570.95641,750.19974 556.348,784.28333 551.3125,820.59375 C 550.48042,835.52242 555.90165,849.75318 560.15625,863.65625 C 554.24001,890.85751 550.01944,920.5562 561.3125,946.78125 C 574.82967,984.9421 596.31397,1022.4634 593.73529,1064.2495 C 592.78699,1093.5437 584.72085,1125.2436 599.125,1152.5312 C 609.32364,1171.866 632.26456,1179.8429 653.09285,1180.1988 C 680.95504,1181.3729 709.55546,1168.5772 725.09375,1144.9375 C 747.68924,1115.5658 766.89426,1083.4402 780.3324,1048.8777 C 797.22293,1003.3717 810.0042,956.31698 818.26642,908.4788 C 820.09082,895.53774 821.3675,881.00895 813.6875,869.65625 C 810.25635,862.31993 813.72957,854.09611 813.00293,846.34648 C 813.67693,821.35182 817.01525,795.68272 829.65625,773.75 C 811.92312,780.1946 794.58357,790.30971 785.65318,807.61425 C 781.7181,814.3238 778.04836,821.18838 774.28125,828 C 770.73126,797.98592 778.00088,768.35172 781.0625,738.71875 C 760.89646,747.77338 744.18578,764.37397 736.88755,785.40075 C 730.58292,800.98078 728.08533,817.71793 726.625,834.4375 C 718.37166,832.91825 709.94053,832.33595 701.5625,832.9375 C 700.59942,794.23963 701.09554,753.53035 712.53125,717.03125 C 693.85012,723.24901 677.36504,735.76676 666.90322,752.41848 C 653.05068,773.29827 645.64182,798.17243 643.84375,823.03125 C 644.42909,827.35579 643.78249,834.87134 637.5,832.90625 C 632.16882,832.9238 626.87092,833.58508 621.5625,834 C 622.71034,794.61852 618.22106,752.3718 594.5,719.78125 C 591.43929,716.14408 588.86315,712.09687 585.875,708.4375 C 584.9375,710.875 584,713.3125 583.0625,715.75 z M 590.8125,729.59375 C 609.37777,758.89004 613.295,794.41387 612.9375,828.46875 C 613.14159,833.64401 612.42094,840.29795 613.0625,844.53125 C 625.38106,838.4285 639.80162,842.09135 652.84375,842.34375 C 655.16087,843.567 656.03585,843.99618 654.75,840.9375 C 650.58545,826.98465 652.90172,812.3245 656.55504,798.52986 C 662.92191,772.23922 677.18332,747.44188 699.375,731.5 C 690.75791,768.73706 693.65842,808.06161 693.28125,845.46875 C 705.53469,838.55885 720.56004,842.02262 733.3125,845.21875 C 736.70472,848.75355 735.60185,844.48927 735.5,841.40625 C 735.01691,820.03567 739.63133,798.33662 749.1875,779.25 C 755.15016,768.56273 763.43088,759.44621 771.625,750.375 C 763.75344,784.2131 762.4221,819.71093 768.90625,853.875 C 770.6311,852.46382 773.51306,853.42086 774.5625,853.5 C 784.24619,832.26318 790.91362,808.11938 809.45266,792.75815 C 811.32595,792.38693 808.00448,801.2831 807.96875,804.65625 C 804.43387,826.50206 804.67155,848.82948 803.0625,870.90625 C 801.75012,872.28304 805.91085,873.22979 806.53125,874.96875 C 814.45436,885.53455 809.65419,899.80024 808.62285,911.74886 C 801.5588,956.78241 786.85732,1000.1282 773.04608,1043.446 C 760.97132,1076.3953 742.32638,1106.526 721.8125,1134.875 C 710.85993,1148.4264 698.56778,1162.7263 680.96875,1167.375 C 660.81274,1173.6163 637.3928,1172.5494 619,1161.7188 C 601.71034,1149.3774 597.97607,1126.0099 599.73774,1106.0324 C 599.78653,1090.2062 602.10985,1078.2316 607.65521,1063.2271 C 613.20056,1048.2226 610.12626,1031.8954 605.875,1015.5938 C 601.62374,999.2922 593.69597,989.33378 584.05342,973.38963 C 574.41087,957.44548 566.41652,937.35229 563.28125,917.8125 C 561.53177,899.18536 566.17296,880.68988 569.0625,862.5625 C 572.35873,859.72554 567.46451,857.36591 566.75,854.375 C 559.14887,837.35992 558.34253,817.6001 564.00766,799.81502 C 571.13786,774.74272 579.76853,750.18261 588.6875,725.6875 C 589.39583,726.98958 590.10417,728.29167 590.8125,729.59375 z" | ||
2855 | id="path4149" | ||
2856 | sodipodi:nodetypes="ccccccccccccccccccccccccccccccccccccccccccccccccccczzzcccccc" | ||
2857 | clip-path="url(#clipPath4177)" /> | ||
2858 | <path | ||
2859 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter4130);enable-background:accumulate" | ||
2860 | d="M 735.05635,733.03834 L 737.81177,754.12715 L 782.2228,738.73894 L 787.07343,716.34919 L 783.13726,694.29697 L 760.68563,657.70396 L 752.40559,688.0089 L 735.05635,733.03834 z" | ||
2861 | id="path3902" | ||
2862 | sodipodi:nodetypes="cccccccc" | ||
2863 | clip-path="url(#clipPath3631)" | ||
2864 | transform="translate(276,136)" /> | ||
2865 | <path | ||
2866 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;filter:url(#filter4141);enable-background:accumulate" | ||
2867 | d="M 831.81321,730.29452 L 847.63558,745.19938 L 868.49031,748.09932 L 866.90002,708.17334 L 875.22563,677.66492 L 868.06064,671.32386 L 846.36395,692.26626 L 831.81321,730.29452 z" | ||
2868 | id="path4135" | ||
2869 | sodipodi:nodetypes="cccccccc" | ||
2870 | clip-path="url(#clipPath3631)" | ||
2871 | transform="translate(276,136)" /> | ||
2872 | <g | ||
2873 | id="g8367" | ||
2874 | style="filter:url(#filter8379)" | ||
2875 | clip-path="url(#clipPath8392)" | ||
2876 | transform="translate(276,136)"> | ||
2877 | <path | ||
2878 | clip-path="none" | ||
2879 | sodipodi:nodetypes="ccccccc" | ||
2880 | id="path4145" | ||
2881 | d="M 910.14441,746.31415 L 942.75736,751.48808 L 942.39617,727.61189 L 949.5847,697.92968 L 941.13358,692.66603 L 919.31164,719.1768 L 910.14441,746.31415 z" | ||
2882 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
2883 | <rect | ||
2884 | y="650.19098" | ||
2885 | x="877.51953" | ||
2886 | height="172.53406" | ||
2887 | width="123.03658" | ||
2888 | id="rect8365" | ||
2889 | style="opacity:1;fill:none;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:25;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
2890 | </g> | ||
2891 | <g | ||
2892 | id="g8400" | ||
2893 | style="filter:url(#filter8404)" | ||
2894 | clip-path="url(#clipPath8417)" | ||
2895 | transform="translate(276,136)"> | ||
2896 | <path | ||
2897 | clip-path="none" | ||
2898 | sodipodi:nodetypes="ccccc" | ||
2899 | id="path4147" | ||
2900 | d="M 964.00012,754.69487 L 982.42893,762.15966 L 991.5,725.19519 L 976.62969,730.03405 L 964.00012,754.69487 z" | ||
2901 | style="opacity:1;fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
2902 | <rect | ||
2903 | y="677.06104" | ||
2904 | x="924.89569" | ||
2905 | height="125.1579" | ||
2906 | width="142.12846" | ||
2907 | id="rect8398" | ||
2908 | style="opacity:1;fill:none;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:25;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" /> | ||
2909 | </g> | ||
2910 | </g> | ||
2911 | </svg> | ||
diff --git a/Documentation/logo.txt b/Documentation/logo.txt index 296f0f7f67eb..a2e62445e28e 100644 --- a/Documentation/logo.txt +++ b/Documentation/logo.txt | |||
@@ -1,13 +1,4 @@ | |||
1 | This is the full-colour version of the currently unofficial Linux logo | 1 | Tux is taking a three month sabbatical to work as a barber, so Tuz is |
2 | ("currently unofficial" just means that there has been no paperwork and | 2 | standing in. He's taken pains to ensure you'll hardly notice. |
3 | that I have not really announced it yet). It was created by Larry Ewing, | ||
4 | and is freely usable as long as you acknowledge Larry as the original | ||
5 | artist. | ||
6 | |||
7 | Note that there are black-and-white versions of this available that | ||
8 | scale down to smaller sizes and are better for letterheads or whatever | ||
9 | you want to use it for: for the full range of logos take a look at | ||
10 | Larry's web-page: | ||
11 | |||
12 | http://www.isc.tamu.edu/~lewing/linux/ | ||
13 | 3 | ||
4 | Image by Andrew McGown and Josh Bush. Image is licensed CC BY-SA. | ||
diff --git a/Documentation/md.txt b/Documentation/md.txt index 1da9d1b1793f..4edd39ec7db9 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt | |||
@@ -164,15 +164,19 @@ All md devices contain: | |||
164 | raid_disks | 164 | raid_disks |
165 | a text file with a simple number indicating the number of devices | 165 | a text file with a simple number indicating the number of devices |
166 | in a fully functional array. If this is not yet known, the file | 166 | in a fully functional array. If this is not yet known, the file |
167 | will be empty. If an array is being resized (not currently | 167 | will be empty. If an array is being resized this will contain |
168 | possible) this will contain the larger of the old and new sizes. | 168 | the new number of devices. |
169 | Some raid level (RAID1) allow this value to be set while the | 169 | Some raid levels allow this value to be set while the array is |
170 | array is active. This will reconfigure the array. Otherwise | 170 | active. This will reconfigure the array. Otherwise it can only |
171 | it can only be set while assembling an array. | 171 | be set while assembling an array. |
172 | A change to this attribute will not be permitted if it would | ||
173 | reduce the size of the array. To reduce the number of drives | ||
174 | in an e.g. raid5, the array size must first be reduced by | ||
175 | setting the 'array_size' attribute. | ||
172 | 176 | ||
173 | chunk_size | 177 | chunk_size |
174 | This is the size if bytes for 'chunks' and is only relevant to | 178 | This is the size in bytes for 'chunks' and is only relevant to |
175 | raid levels that involve striping (1,4,5,6,10). The address space | 179 | raid levels that involve striping (0,4,5,6,10). The address space |
176 | of the array is conceptually divided into chunks and consecutive | 180 | of the array is conceptually divided into chunks and consecutive |
177 | chunks are striped onto neighbouring devices. | 181 | chunks are striped onto neighbouring devices. |
178 | The size should be at least PAGE_SIZE (4k) and should be a power | 182 | The size should be at least PAGE_SIZE (4k) and should be a power |
@@ -183,6 +187,20 @@ All md devices contain: | |||
183 | simply a number that is interpretted differently by different | 187 | simply a number that is interpretted differently by different |
184 | levels. It can be written while assembling an array. | 188 | levels. It can be written while assembling an array. |
185 | 189 | ||
190 | array_size | ||
191 | This can be used to artificially constrain the available space in | ||
192 | the array to be less than is actually available on the combined | ||
193 | devices. Writing a number (in Kilobytes) which is less than | ||
194 | the available size will set the size. Any reconfiguration of the | ||
195 | array (e.g. adding devices) will not cause the size to change. | ||
196 | Writing the word 'default' will cause the effective size of the | ||
197 | array to be whatever size is actually available based on | ||
198 | 'level', 'chunk_size' and 'component_size'. | ||
199 | |||
200 | This can be used to reduce the size of the array before reducing | ||
201 | the number of devices in a raid4/5/6, or to support external | ||
202 | metadata formats which mandate such clipping. | ||
203 | |||
186 | reshape_position | 204 | reshape_position |
187 | This is either "none" or a sector number within the devices of | 205 | This is either "none" or a sector number within the devices of |
188 | the array where "reshape" is up to. If this is set, the three | 206 | the array where "reshape" is up to. If this is set, the three |
@@ -207,6 +225,11 @@ All md devices contain: | |||
207 | about the array. It can be 0.90 (traditional format), 1.0, 1.1, | 225 | about the array. It can be 0.90 (traditional format), 1.0, 1.1, |
208 | 1.2 (newer format in varying locations) or "none" indicating that | 226 | 1.2 (newer format in varying locations) or "none" indicating that |
209 | the kernel isn't managing metadata at all. | 227 | the kernel isn't managing metadata at all. |
228 | Alternately it can be "external:" followed by a string which | ||
229 | is set by user-space. This indicates that metadata is managed | ||
230 | by a user-space program. Any device failure or other event that | ||
231 | requires a metadata update will cause array activity to be | ||
232 | suspended until the event is acknowledged. | ||
210 | 233 | ||
211 | resync_start | 234 | resync_start |
212 | The point at which resync should start. If no resync is needed, | 235 | The point at which resync should start. If no resync is needed, |
diff --git a/Documentation/misc-devices/isl29003 b/Documentation/misc-devices/isl29003 new file mode 100644 index 000000000000..c4ff5f38e010 --- /dev/null +++ b/Documentation/misc-devices/isl29003 | |||
@@ -0,0 +1,62 @@ | |||
1 | Kernel driver isl29003 | ||
2 | ===================== | ||
3 | |||
4 | Supported chips: | ||
5 | * Intersil ISL29003 | ||
6 | Prefix: 'isl29003' | ||
7 | Addresses scanned: none | ||
8 | Datasheet: | ||
9 | http://www.intersil.com/data/fn/fn7464.pdf | ||
10 | |||
11 | Author: Daniel Mack <daniel@caiaq.de> | ||
12 | |||
13 | |||
14 | Description | ||
15 | ----------- | ||
16 | The ISL29003 is an integrated light sensor with a 16-bit integrating type | ||
17 | ADC, I2C user programmable lux range select for optimized counts/lux, and | ||
18 | I2C multi-function control and monitoring capabilities. The internal ADC | ||
19 | provides 16-bit resolution while rejecting 50Hz and 60Hz flicker caused by | ||
20 | artificial light sources. | ||
21 | |||
22 | The driver allows to set the lux range, the bit resolution, the operational | ||
23 | mode (see below) and the power state of device and can read the current lux | ||
24 | value, of course. | ||
25 | |||
26 | |||
27 | Detection | ||
28 | --------- | ||
29 | |||
30 | The ISL29003 does not have an ID register which could be used to identify | ||
31 | it, so the detection routine will just try to read from the configured I2C | ||
32 | addess and consider the device to be present as soon as it ACKs the | ||
33 | transfer. | ||
34 | |||
35 | |||
36 | Sysfs entries | ||
37 | ------------- | ||
38 | |||
39 | range: | ||
40 | 0: 0 lux to 1000 lux (default) | ||
41 | 1: 0 lux to 4000 lux | ||
42 | 2: 0 lux to 16,000 lux | ||
43 | 3: 0 lux to 64,000 lux | ||
44 | |||
45 | resolution: | ||
46 | 0: 2^16 cycles (default) | ||
47 | 1: 2^12 cycles | ||
48 | 2: 2^8 cycles | ||
49 | 3: 2^4 cycles | ||
50 | |||
51 | mode: | ||
52 | 0: diode1's current (unsigned 16bit) (default) | ||
53 | 1: diode1's current (unsigned 16bit) | ||
54 | 2: difference between diodes (l1 - l2, signed 15bit) | ||
55 | |||
56 | power_state: | ||
57 | 0: device is disabled (default) | ||
58 | 1: device is enabled | ||
59 | |||
60 | lux (read only): | ||
61 | returns the value from the last sensor reading | ||
62 | |||
diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt index 7a3bb1abb830..b132e4a3cf0f 100644 --- a/Documentation/networking/dccp.txt +++ b/Documentation/networking/dccp.txt | |||
@@ -141,7 +141,8 @@ rx_ccid = 2 | |||
141 | Default CCID for the receiver-sender half-connection; see tx_ccid. | 141 | Default CCID for the receiver-sender half-connection; see tx_ccid. |
142 | 142 | ||
143 | seq_window = 100 | 143 | seq_window = 100 |
144 | The initial sequence window (sec. 7.5.2). | 144 | The initial sequence window (sec. 7.5.2) of the sender. This influences |
145 | the local ackno validity and the remote seqno validity windows (7.5.1). | ||
145 | 146 | ||
146 | tx_qlen = 5 | 147 | tx_qlen = 5 |
147 | The size of the transmit buffer in packets. A value of 0 corresponds | 148 | The size of the transmit buffer in packets. A value of 0 corresponds |
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index c7712787933c..ec5de02f543f 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt | |||
@@ -2,7 +2,7 @@ | |||
2 | 2 | ||
3 | ip_forward - BOOLEAN | 3 | ip_forward - BOOLEAN |
4 | 0 - disabled (default) | 4 | 0 - disabled (default) |
5 | not 0 - enabled | 5 | not 0 - enabled |
6 | 6 | ||
7 | Forward Packets between interfaces. | 7 | Forward Packets between interfaces. |
8 | 8 | ||
@@ -36,49 +36,49 @@ rt_cache_rebuild_count - INTEGER | |||
36 | IP Fragmentation: | 36 | IP Fragmentation: |
37 | 37 | ||
38 | ipfrag_high_thresh - INTEGER | 38 | ipfrag_high_thresh - INTEGER |
39 | Maximum memory used to reassemble IP fragments. When | 39 | Maximum memory used to reassemble IP fragments. When |
40 | ipfrag_high_thresh bytes of memory is allocated for this purpose, | 40 | ipfrag_high_thresh bytes of memory is allocated for this purpose, |
41 | the fragment handler will toss packets until ipfrag_low_thresh | 41 | the fragment handler will toss packets until ipfrag_low_thresh |
42 | is reached. | 42 | is reached. |
43 | 43 | ||
44 | ipfrag_low_thresh - INTEGER | 44 | ipfrag_low_thresh - INTEGER |
45 | See ipfrag_high_thresh | 45 | See ipfrag_high_thresh |
46 | 46 | ||
47 | ipfrag_time - INTEGER | 47 | ipfrag_time - INTEGER |
48 | Time in seconds to keep an IP fragment in memory. | 48 | Time in seconds to keep an IP fragment in memory. |
49 | 49 | ||
50 | ipfrag_secret_interval - INTEGER | 50 | ipfrag_secret_interval - INTEGER |
51 | Regeneration interval (in seconds) of the hash secret (or lifetime | 51 | Regeneration interval (in seconds) of the hash secret (or lifetime |
52 | for the hash secret) for IP fragments. | 52 | for the hash secret) for IP fragments. |
53 | Default: 600 | 53 | Default: 600 |
54 | 54 | ||
55 | ipfrag_max_dist - INTEGER | 55 | ipfrag_max_dist - INTEGER |
56 | ipfrag_max_dist is a non-negative integer value which defines the | 56 | ipfrag_max_dist is a non-negative integer value which defines the |
57 | maximum "disorder" which is allowed among fragments which share a | 57 | maximum "disorder" which is allowed among fragments which share a |
58 | common IP source address. Note that reordering of packets is | 58 | common IP source address. Note that reordering of packets is |
59 | not unusual, but if a large number of fragments arrive from a source | 59 | not unusual, but if a large number of fragments arrive from a source |
60 | IP address while a particular fragment queue remains incomplete, it | 60 | IP address while a particular fragment queue remains incomplete, it |
61 | probably indicates that one or more fragments belonging to that queue | 61 | probably indicates that one or more fragments belonging to that queue |
62 | have been lost. When ipfrag_max_dist is positive, an additional check | 62 | have been lost. When ipfrag_max_dist is positive, an additional check |
63 | is done on fragments before they are added to a reassembly queue - if | 63 | is done on fragments before they are added to a reassembly queue - if |
64 | ipfrag_max_dist (or more) fragments have arrived from a particular IP | 64 | ipfrag_max_dist (or more) fragments have arrived from a particular IP |
65 | address between additions to any IP fragment queue using that source | 65 | address between additions to any IP fragment queue using that source |
66 | address, it's presumed that one or more fragments in the queue are | 66 | address, it's presumed that one or more fragments in the queue are |
67 | lost. The existing fragment queue will be dropped, and a new one | 67 | lost. The existing fragment queue will be dropped, and a new one |
68 | started. An ipfrag_max_dist value of zero disables this check. | 68 | started. An ipfrag_max_dist value of zero disables this check. |
69 | 69 | ||
70 | Using a very small value, e.g. 1 or 2, for ipfrag_max_dist can | 70 | Using a very small value, e.g. 1 or 2, for ipfrag_max_dist can |
71 | result in unnecessarily dropping fragment queues when normal | 71 | result in unnecessarily dropping fragment queues when normal |
72 | reordering of packets occurs, which could lead to poor application | 72 | reordering of packets occurs, which could lead to poor application |
73 | performance. Using a very large value, e.g. 50000, increases the | 73 | performance. Using a very large value, e.g. 50000, increases the |
74 | likelihood of incorrectly reassembling IP fragments that originate | 74 | likelihood of incorrectly reassembling IP fragments that originate |
75 | from different IP datagrams, which could result in data corruption. | 75 | from different IP datagrams, which could result in data corruption. |
76 | Default: 64 | 76 | Default: 64 |
77 | 77 | ||
78 | INET peer storage: | 78 | INET peer storage: |
79 | 79 | ||
80 | inet_peer_threshold - INTEGER | 80 | inet_peer_threshold - INTEGER |
81 | The approximate size of the storage. Starting from this threshold | 81 | The approximate size of the storage. Starting from this threshold |
82 | entries will be thrown aggressively. This threshold also determines | 82 | entries will be thrown aggressively. This threshold also determines |
83 | entries' time-to-live and time intervals between garbage collection | 83 | entries' time-to-live and time intervals between garbage collection |
84 | passes. More entries, less time-to-live, less GC interval. | 84 | passes. More entries, less time-to-live, less GC interval. |
@@ -105,7 +105,7 @@ inet_peer_gc_maxtime - INTEGER | |||
105 | in effect under low (or absent) memory pressure on the pool. | 105 | in effect under low (or absent) memory pressure on the pool. |
106 | Measured in seconds. | 106 | Measured in seconds. |
107 | 107 | ||
108 | TCP variables: | 108 | TCP variables: |
109 | 109 | ||
110 | somaxconn - INTEGER | 110 | somaxconn - INTEGER |
111 | Limit of socket listen() backlog, known in userspace as SOMAXCONN. | 111 | Limit of socket listen() backlog, known in userspace as SOMAXCONN. |
@@ -310,7 +310,7 @@ tcp_orphan_retries - INTEGER | |||
310 | 310 | ||
311 | tcp_reordering - INTEGER | 311 | tcp_reordering - INTEGER |
312 | Maximal reordering of packets in a TCP stream. | 312 | Maximal reordering of packets in a TCP stream. |
313 | Default: 3 | 313 | Default: 3 |
314 | 314 | ||
315 | tcp_retrans_collapse - BOOLEAN | 315 | tcp_retrans_collapse - BOOLEAN |
316 | Bug-to-bug compatibility with some broken printers. | 316 | Bug-to-bug compatibility with some broken printers. |
@@ -521,7 +521,7 @@ IP Variables: | |||
521 | 521 | ||
522 | ip_local_port_range - 2 INTEGERS | 522 | ip_local_port_range - 2 INTEGERS |
523 | Defines the local port range that is used by TCP and UDP to | 523 | Defines the local port range that is used by TCP and UDP to |
524 | choose the local port. The first number is the first, the | 524 | choose the local port. The first number is the first, the |
525 | second the last local port number. Default value depends on | 525 | second the last local port number. Default value depends on |
526 | amount of memory available on the system: | 526 | amount of memory available on the system: |
527 | > 128Mb 32768-61000 | 527 | > 128Mb 32768-61000 |
@@ -594,12 +594,12 @@ icmp_errors_use_inbound_ifaddr - BOOLEAN | |||
594 | 594 | ||
595 | If zero, icmp error messages are sent with the primary address of | 595 | If zero, icmp error messages are sent with the primary address of |
596 | the exiting interface. | 596 | the exiting interface. |
597 | 597 | ||
598 | If non-zero, the message will be sent with the primary address of | 598 | If non-zero, the message will be sent with the primary address of |
599 | the interface that received the packet that caused the icmp error. | 599 | the interface that received the packet that caused the icmp error. |
600 | This is the behaviour network many administrators will expect from | 600 | This is the behaviour network many administrators will expect from |
601 | a router. And it can make debugging complicated network layouts | 601 | a router. And it can make debugging complicated network layouts |
602 | much easier. | 602 | much easier. |
603 | 603 | ||
604 | Note that if no primary address exists for the interface selected, | 604 | Note that if no primary address exists for the interface selected, |
605 | then the primary address of the first non-loopback interface that | 605 | then the primary address of the first non-loopback interface that |
@@ -611,7 +611,7 @@ igmp_max_memberships - INTEGER | |||
611 | Change the maximum number of multicast groups we can subscribe to. | 611 | Change the maximum number of multicast groups we can subscribe to. |
612 | Default: 20 | 612 | Default: 20 |
613 | 613 | ||
614 | conf/interface/* changes special settings per interface (where "interface" is | 614 | conf/interface/* changes special settings per interface (where "interface" is |
615 | the name of your network interface) | 615 | the name of your network interface) |
616 | conf/all/* is special, changes the settings for all interfaces | 616 | conf/all/* is special, changes the settings for all interfaces |
617 | 617 | ||
@@ -625,11 +625,11 @@ log_martians - BOOLEAN | |||
625 | accept_redirects - BOOLEAN | 625 | accept_redirects - BOOLEAN |
626 | Accept ICMP redirect messages. | 626 | Accept ICMP redirect messages. |
627 | accept_redirects for the interface will be enabled if: | 627 | accept_redirects for the interface will be enabled if: |
628 | - both conf/{all,interface}/accept_redirects are TRUE in the case forwarding | 628 | - both conf/{all,interface}/accept_redirects are TRUE in the case |
629 | for the interface is enabled | 629 | forwarding for the interface is enabled |
630 | or | 630 | or |
631 | - at least one of conf/{all,interface}/accept_redirects is TRUE in the case | 631 | - at least one of conf/{all,interface}/accept_redirects is TRUE in the |
632 | forwarding for the interface is disabled | 632 | case forwarding for the interface is disabled |
633 | accept_redirects for the interface will be disabled otherwise | 633 | accept_redirects for the interface will be disabled otherwise |
634 | default TRUE (host) | 634 | default TRUE (host) |
635 | FALSE (router) | 635 | FALSE (router) |
@@ -640,8 +640,8 @@ forwarding - BOOLEAN | |||
640 | mc_forwarding - BOOLEAN | 640 | mc_forwarding - BOOLEAN |
641 | Do multicast routing. The kernel needs to be compiled with CONFIG_MROUTE | 641 | Do multicast routing. The kernel needs to be compiled with CONFIG_MROUTE |
642 | and a multicast routing daemon is required. | 642 | and a multicast routing daemon is required. |
643 | conf/all/mc_forwarding must also be set to TRUE to enable multicast routing | 643 | conf/all/mc_forwarding must also be set to TRUE to enable multicast |
644 | for the interface | 644 | routing for the interface |
645 | 645 | ||
646 | medium_id - INTEGER | 646 | medium_id - INTEGER |
647 | Integer value used to differentiate the devices by the medium they | 647 | Integer value used to differentiate the devices by the medium they |
@@ -649,7 +649,7 @@ medium_id - INTEGER | |||
649 | the broadcast packets are received only on one of them. | 649 | the broadcast packets are received only on one of them. |
650 | The default value 0 means that the device is the only interface | 650 | The default value 0 means that the device is the only interface |
651 | to its medium, value of -1 means that medium is not known. | 651 | to its medium, value of -1 means that medium is not known. |
652 | 652 | ||
653 | Currently, it is used to change the proxy_arp behavior: | 653 | Currently, it is used to change the proxy_arp behavior: |
654 | the proxy_arp feature is enabled for packets forwarded between | 654 | the proxy_arp feature is enabled for packets forwarded between |
655 | two devices attached to different media. | 655 | two devices attached to different media. |
@@ -699,16 +699,22 @@ accept_source_route - BOOLEAN | |||
699 | default TRUE (router) | 699 | default TRUE (router) |
700 | FALSE (host) | 700 | FALSE (host) |
701 | 701 | ||
702 | rp_filter - BOOLEAN | 702 | rp_filter - INTEGER |
703 | 1 - do source validation by reversed path, as specified in RFC1812 | ||
704 | Recommended option for single homed hosts and stub network | ||
705 | routers. Could cause troubles for complicated (not loop free) | ||
706 | networks running a slow unreliable protocol (sort of RIP), | ||
707 | or using static routes. | ||
708 | |||
709 | 0 - No source validation. | 703 | 0 - No source validation. |
710 | 704 | 1 - Strict mode as defined in RFC3704 Strict Reverse Path | |
711 | conf/all/rp_filter must also be set to TRUE to do source validation | 705 | Each incoming packet is tested against the FIB and if the interface |
706 | is not the best reverse path the packet check will fail. | ||
707 | By default failed packets are discarded. | ||
708 | 2 - Loose mode as defined in RFC3704 Loose Reverse Path | ||
709 | Each incoming packet's source address is also tested against the FIB | ||
710 | and if the source address is not reachable via any interface | ||
711 | the packet check will fail. | ||
712 | |||
713 | Current recommended practice in RFC3704 is to enable strict mode | ||
714 | to prevent IP spoofing from DDos attacks. If using asymmetric routing | ||
715 | or other complicated routing, then loose mode is recommended. | ||
716 | |||
717 | conf/all/rp_filter must also be set to non-zero to do source validation | ||
712 | on the interface | 718 | on the interface |
713 | 719 | ||
714 | Default value is 0. Note that some distributions enable it | 720 | Default value is 0. Note that some distributions enable it |
@@ -782,6 +788,12 @@ arp_ignore - INTEGER | |||
782 | The max value from conf/{all,interface}/arp_ignore is used | 788 | The max value from conf/{all,interface}/arp_ignore is used |
783 | when ARP request is received on the {interface} | 789 | when ARP request is received on the {interface} |
784 | 790 | ||
791 | arp_notify - BOOLEAN | ||
792 | Define mode for notification of address and device changes. | ||
793 | 0 - (default): do nothing | ||
794 | 1 - Generate gratuitous arp replies when device is brought up | ||
795 | or hardware address changes. | ||
796 | |||
785 | arp_accept - BOOLEAN | 797 | arp_accept - BOOLEAN |
786 | Define behavior when gratuitous arp replies are received: | 798 | Define behavior when gratuitous arp replies are received: |
787 | 0 - drop gratuitous arp frames | 799 | 0 - drop gratuitous arp frames |
@@ -823,7 +835,7 @@ apply to IPv6 [XXX?]. | |||
823 | 835 | ||
824 | bindv6only - BOOLEAN | 836 | bindv6only - BOOLEAN |
825 | Default value for IPV6_V6ONLY socket option, | 837 | Default value for IPV6_V6ONLY socket option, |
826 | which restricts use of the IPv6 socket to IPv6 communication | 838 | which restricts use of the IPv6 socket to IPv6 communication |
827 | only. | 839 | only. |
828 | TRUE: disable IPv4-mapped address feature | 840 | TRUE: disable IPv4-mapped address feature |
829 | FALSE: enable IPv4-mapped address feature | 841 | FALSE: enable IPv4-mapped address feature |
@@ -833,19 +845,19 @@ bindv6only - BOOLEAN | |||
833 | IPv6 Fragmentation: | 845 | IPv6 Fragmentation: |
834 | 846 | ||
835 | ip6frag_high_thresh - INTEGER | 847 | ip6frag_high_thresh - INTEGER |
836 | Maximum memory used to reassemble IPv6 fragments. When | 848 | Maximum memory used to reassemble IPv6 fragments. When |
837 | ip6frag_high_thresh bytes of memory is allocated for this purpose, | 849 | ip6frag_high_thresh bytes of memory is allocated for this purpose, |
838 | the fragment handler will toss packets until ip6frag_low_thresh | 850 | the fragment handler will toss packets until ip6frag_low_thresh |
839 | is reached. | 851 | is reached. |
840 | 852 | ||
841 | ip6frag_low_thresh - INTEGER | 853 | ip6frag_low_thresh - INTEGER |
842 | See ip6frag_high_thresh | 854 | See ip6frag_high_thresh |
843 | 855 | ||
844 | ip6frag_time - INTEGER | 856 | ip6frag_time - INTEGER |
845 | Time in seconds to keep an IPv6 fragment in memory. | 857 | Time in seconds to keep an IPv6 fragment in memory. |
846 | 858 | ||
847 | ip6frag_secret_interval - INTEGER | 859 | ip6frag_secret_interval - INTEGER |
848 | Regeneration interval (in seconds) of the hash secret (or lifetime | 860 | Regeneration interval (in seconds) of the hash secret (or lifetime |
849 | for the hash secret) for IPv6 fragments. | 861 | for the hash secret) for IPv6 fragments. |
850 | Default: 600 | 862 | Default: 600 |
851 | 863 | ||
@@ -854,17 +866,17 @@ conf/default/*: | |||
854 | 866 | ||
855 | 867 | ||
856 | conf/all/*: | 868 | conf/all/*: |
857 | Change all the interface-specific settings. | 869 | Change all the interface-specific settings. |
858 | 870 | ||
859 | [XXX: Other special features than forwarding?] | 871 | [XXX: Other special features than forwarding?] |
860 | 872 | ||
861 | conf/all/forwarding - BOOLEAN | 873 | conf/all/forwarding - BOOLEAN |
862 | Enable global IPv6 forwarding between all interfaces. | 874 | Enable global IPv6 forwarding between all interfaces. |
863 | 875 | ||
864 | IPv4 and IPv6 work differently here; e.g. netfilter must be used | 876 | IPv4 and IPv6 work differently here; e.g. netfilter must be used |
865 | to control which interfaces may forward packets and which not. | 877 | to control which interfaces may forward packets and which not. |
866 | 878 | ||
867 | This also sets all interfaces' Host/Router setting | 879 | This also sets all interfaces' Host/Router setting |
868 | 'forwarding' to the specified value. See below for details. | 880 | 'forwarding' to the specified value. See below for details. |
869 | 881 | ||
870 | This referred to as global forwarding. | 882 | This referred to as global forwarding. |
@@ -875,12 +887,12 @@ proxy_ndp - BOOLEAN | |||
875 | conf/interface/*: | 887 | conf/interface/*: |
876 | Change special settings per interface. | 888 | Change special settings per interface. |
877 | 889 | ||
878 | The functional behaviour for certain settings is different | 890 | The functional behaviour for certain settings is different |
879 | depending on whether local forwarding is enabled or not. | 891 | depending on whether local forwarding is enabled or not. |
880 | 892 | ||
881 | accept_ra - BOOLEAN | 893 | accept_ra - BOOLEAN |
882 | Accept Router Advertisements; autoconfigure using them. | 894 | Accept Router Advertisements; autoconfigure using them. |
883 | 895 | ||
884 | Functional default: enabled if local forwarding is disabled. | 896 | Functional default: enabled if local forwarding is disabled. |
885 | disabled if local forwarding is enabled. | 897 | disabled if local forwarding is enabled. |
886 | 898 | ||
@@ -926,7 +938,7 @@ accept_source_route - INTEGER | |||
926 | Default: 0 | 938 | Default: 0 |
927 | 939 | ||
928 | autoconf - BOOLEAN | 940 | autoconf - BOOLEAN |
929 | Autoconfigure addresses using Prefix Information in Router | 941 | Autoconfigure addresses using Prefix Information in Router |
930 | Advertisements. | 942 | Advertisements. |
931 | 943 | ||
932 | Functional default: enabled if accept_ra_pinfo is enabled. | 944 | Functional default: enabled if accept_ra_pinfo is enabled. |
@@ -935,11 +947,11 @@ autoconf - BOOLEAN | |||
935 | dad_transmits - INTEGER | 947 | dad_transmits - INTEGER |
936 | The amount of Duplicate Address Detection probes to send. | 948 | The amount of Duplicate Address Detection probes to send. |
937 | Default: 1 | 949 | Default: 1 |
938 | 950 | ||
939 | forwarding - BOOLEAN | 951 | forwarding - BOOLEAN |
940 | Configure interface-specific Host/Router behaviour. | 952 | Configure interface-specific Host/Router behaviour. |
941 | 953 | ||
942 | Note: It is recommended to have the same setting on all | 954 | Note: It is recommended to have the same setting on all |
943 | interfaces; mixed router/host scenarios are rather uncommon. | 955 | interfaces; mixed router/host scenarios are rather uncommon. |
944 | 956 | ||
945 | FALSE: | 957 | FALSE: |
@@ -948,13 +960,13 @@ forwarding - BOOLEAN | |||
948 | 960 | ||
949 | 1. IsRouter flag is not set in Neighbour Advertisements. | 961 | 1. IsRouter flag is not set in Neighbour Advertisements. |
950 | 2. Router Solicitations are being sent when necessary. | 962 | 2. Router Solicitations are being sent when necessary. |
951 | 3. If accept_ra is TRUE (default), accept Router | 963 | 3. If accept_ra is TRUE (default), accept Router |
952 | Advertisements (and do autoconfiguration). | 964 | Advertisements (and do autoconfiguration). |
953 | 4. If accept_redirects is TRUE (default), accept Redirects. | 965 | 4. If accept_redirects is TRUE (default), accept Redirects. |
954 | 966 | ||
955 | TRUE: | 967 | TRUE: |
956 | 968 | ||
957 | If local forwarding is enabled, Router behaviour is assumed. | 969 | If local forwarding is enabled, Router behaviour is assumed. |
958 | This means exactly the reverse from the above: | 970 | This means exactly the reverse from the above: |
959 | 971 | ||
960 | 1. IsRouter flag is set in Neighbour Advertisements. | 972 | 1. IsRouter flag is set in Neighbour Advertisements. |
@@ -989,7 +1001,7 @@ router_solicitation_interval - INTEGER | |||
989 | Default: 4 | 1001 | Default: 4 |
990 | 1002 | ||
991 | router_solicitations - INTEGER | 1003 | router_solicitations - INTEGER |
992 | Number of Router Solicitations to send until assuming no | 1004 | Number of Router Solicitations to send until assuming no |
993 | routers are present. | 1005 | routers are present. |
994 | Default: 3 | 1006 | Default: 3 |
995 | 1007 | ||
@@ -1013,11 +1025,11 @@ temp_prefered_lft - INTEGER | |||
1013 | 1025 | ||
1014 | max_desync_factor - INTEGER | 1026 | max_desync_factor - INTEGER |
1015 | Maximum value for DESYNC_FACTOR, which is a random value | 1027 | Maximum value for DESYNC_FACTOR, which is a random value |
1016 | that ensures that clients don't synchronize with each | 1028 | that ensures that clients don't synchronize with each |
1017 | other and generate new addresses at exactly the same time. | 1029 | other and generate new addresses at exactly the same time. |
1018 | value is in seconds. | 1030 | value is in seconds. |
1019 | Default: 600 | 1031 | Default: 600 |
1020 | 1032 | ||
1021 | regen_max_retry - INTEGER | 1033 | regen_max_retry - INTEGER |
1022 | Number of attempts before give up attempting to generate | 1034 | Number of attempts before give up attempting to generate |
1023 | valid temporary addresses. | 1035 | valid temporary addresses. |
@@ -1025,13 +1037,15 @@ regen_max_retry - INTEGER | |||
1025 | 1037 | ||
1026 | max_addresses - INTEGER | 1038 | max_addresses - INTEGER |
1027 | Number of maximum addresses per interface. 0 disables limitation. | 1039 | Number of maximum addresses per interface. 0 disables limitation. |
1028 | It is recommended not set too large value (or 0) because it would | 1040 | It is recommended not set too large value (or 0) because it would |
1029 | be too easy way to crash kernel to allow to create too much of | 1041 | be too easy way to crash kernel to allow to create too much of |
1030 | autoconfigured addresses. | 1042 | autoconfigured addresses. |
1031 | Default: 16 | 1043 | Default: 16 |
1032 | 1044 | ||
1033 | disable_ipv6 - BOOLEAN | 1045 | disable_ipv6 - BOOLEAN |
1034 | Disable IPv6 operation. | 1046 | Disable IPv6 operation. If accept_dad is set to 2, this value |
1047 | will be dynamically set to TRUE if DAD fails for the link-local | ||
1048 | address. | ||
1035 | Default: FALSE (enable IPv6 operation) | 1049 | Default: FALSE (enable IPv6 operation) |
1036 | 1050 | ||
1037 | accept_dad - INTEGER | 1051 | accept_dad - INTEGER |
diff --git a/Documentation/networking/ipv6.txt b/Documentation/networking/ipv6.txt new file mode 100644 index 000000000000..268e5c103dd8 --- /dev/null +++ b/Documentation/networking/ipv6.txt | |||
@@ -0,0 +1,35 @@ | |||
1 | |||
2 | Options for the ipv6 module are supplied as parameters at load time. | ||
3 | |||
4 | Module options may be given as command line arguments to the insmod | ||
5 | or modprobe command, but are usually specified in either the | ||
6 | /etc/modules.conf or /etc/modprobe.conf configuration file, or in a | ||
7 | distro-specific configuration file. | ||
8 | |||
9 | The available ipv6 module parameters are listed below. If a parameter | ||
10 | is not specified the default value is used. | ||
11 | |||
12 | The parameters are as follows: | ||
13 | |||
14 | disable | ||
15 | |||
16 | Specifies whether to load the IPv6 module, but disable all | ||
17 | its functionality. This might be used when another module | ||
18 | has a dependency on the IPv6 module being loaded, but no | ||
19 | IPv6 addresses or operations are desired. | ||
20 | |||
21 | The possible values and their effects are: | ||
22 | |||
23 | 0 | ||
24 | IPv6 is enabled. | ||
25 | |||
26 | This is the default value. | ||
27 | |||
28 | 1 | ||
29 | IPv6 is disabled. | ||
30 | |||
31 | No IPv6 addresses will be added to interfaces, and | ||
32 | it will not be possible to open an IPv6 socket. | ||
33 | |||
34 | A reboot is required to enable IPv6. | ||
35 | |||
diff --git a/Documentation/networking/ixgbe.txt b/Documentation/networking/ixgbe.txt new file mode 100644 index 000000000000..eeb68685c788 --- /dev/null +++ b/Documentation/networking/ixgbe.txt | |||
@@ -0,0 +1,199 @@ | |||
1 | Linux Base Driver for 10 Gigabit PCI Express Intel(R) Network Connection | ||
2 | ======================================================================== | ||
3 | |||
4 | March 10, 2009 | ||
5 | |||
6 | |||
7 | Contents | ||
8 | ======== | ||
9 | |||
10 | - In This Release | ||
11 | - Identifying Your Adapter | ||
12 | - Building and Installation | ||
13 | - Additional Configurations | ||
14 | - Support | ||
15 | |||
16 | |||
17 | |||
18 | In This Release | ||
19 | =============== | ||
20 | |||
21 | This file describes the ixgbe Linux Base Driver for the 10 Gigabit PCI | ||
22 | Express Intel(R) Network Connection. This driver includes support for | ||
23 | Itanium(R)2-based systems. | ||
24 | |||
25 | For questions related to hardware requirements, refer to the documentation | ||
26 | supplied with your 10 Gigabit adapter. All hardware requirements listed apply | ||
27 | to use with Linux. | ||
28 | |||
29 | The following features are available in this kernel: | ||
30 | - Native VLANs | ||
31 | - Channel Bonding (teaming) | ||
32 | - SNMP | ||
33 | - Generic Receive Offload | ||
34 | - Data Center Bridging | ||
35 | |||
36 | Channel Bonding documentation can be found in the Linux kernel source: | ||
37 | /Documentation/networking/bonding.txt | ||
38 | |||
39 | Ethtool, lspci, and ifconfig can be used to display device and driver | ||
40 | specific information. | ||
41 | |||
42 | |||
43 | Identifying Your Adapter | ||
44 | ======================== | ||
45 | |||
46 | This driver supports devices based on the 82598 controller and the 82599 | ||
47 | controller. | ||
48 | |||
49 | For specific information on identifying which adapter you have, please visit: | ||
50 | |||
51 | http://support.intel.com/support/network/sb/CS-008441.htm | ||
52 | |||
53 | |||
54 | Building and Installation | ||
55 | ========================= | ||
56 | |||
57 | select m for "Intel(R) 10GbE PCI Express adapters support" located at: | ||
58 | Location: | ||
59 | -> Device Drivers | ||
60 | -> Network device support (NETDEVICES [=y]) | ||
61 | -> Ethernet (10000 Mbit) (NETDEV_10000 [=y]) | ||
62 | |||
63 | 1. make modules & make modules_install | ||
64 | |||
65 | 2. Load the module: | ||
66 | |||
67 | # modprobe ixgbe | ||
68 | |||
69 | The insmod command can be used if the full | ||
70 | path to the driver module is specified. For example: | ||
71 | |||
72 | insmod /lib/modules/<KERNEL VERSION>/kernel/drivers/net/ixgbe/ixgbe.ko | ||
73 | |||
74 | With 2.6 based kernels also make sure that older ixgbe drivers are | ||
75 | removed from the kernel, before loading the new module: | ||
76 | |||
77 | rmmod ixgbe; modprobe ixgbe | ||
78 | |||
79 | 3. Assign an IP address to the interface by entering the following, where | ||
80 | x is the interface number: | ||
81 | |||
82 | ifconfig ethx <IP_address> | ||
83 | |||
84 | 4. Verify that the interface works. Enter the following, where <IP_address> | ||
85 | is the IP address for another machine on the same subnet as the interface | ||
86 | that is being tested: | ||
87 | |||
88 | ping <IP_address> | ||
89 | |||
90 | |||
91 | Additional Configurations | ||
92 | ========================= | ||
93 | |||
94 | Viewing Link Messages | ||
95 | --------------------- | ||
96 | Link messages will not be displayed to the console if the distribution is | ||
97 | restricting system messages. In order to see network driver link messages on | ||
98 | your console, set dmesg to eight by entering the following: | ||
99 | |||
100 | dmesg -n 8 | ||
101 | |||
102 | NOTE: This setting is not saved across reboots. | ||
103 | |||
104 | |||
105 | Jumbo Frames | ||
106 | ------------ | ||
107 | The driver supports Jumbo Frames for all adapters. Jumbo Frames support is | ||
108 | enabled by changing the MTU to a value larger than the default of 1500. | ||
109 | The maximum value for the MTU is 16110. Use the ifconfig command to | ||
110 | increase the MTU size. For example: | ||
111 | |||
112 | ifconfig ethx mtu 9000 up | ||
113 | |||
114 | The maximum MTU setting for Jumbo Frames is 16110. This value coincides | ||
115 | with the maximum Jumbo Frames size of 16128. | ||
116 | |||
117 | Generic Receive Offload, aka GRO | ||
118 | -------------------------------- | ||
119 | The driver supports the in-kernel software implementation of GRO. GRO has | ||
120 | shown that by coalescing Rx traffic into larger chunks of data, CPU | ||
121 | utilization can be significantly reduced when under large Rx load. GRO is an | ||
122 | evolution of the previously-used LRO interface. GRO is able to coalesce | ||
123 | other protocols besides TCP. It's also safe to use with configurations that | ||
124 | are problematic for LRO, namely bridging and iSCSI. | ||
125 | |||
126 | GRO is enabled by default in the driver. Future versions of ethtool will | ||
127 | support disabling and re-enabling GRO on the fly. | ||
128 | |||
129 | |||
130 | Data Center Bridging, aka DCB | ||
131 | ----------------------------- | ||
132 | |||
133 | DCB is a configuration Quality of Service implementation in hardware. | ||
134 | It uses the VLAN priority tag (802.1p) to filter traffic. That means | ||
135 | that there are 8 different priorities that traffic can be filtered into. | ||
136 | It also enables priority flow control which can limit or eliminate the | ||
137 | number of dropped packets during network stress. Bandwidth can be | ||
138 | allocated to each of these priorities, which is enforced at the hardware | ||
139 | level. | ||
140 | |||
141 | To enable DCB support in ixgbe, you must enable the DCB netlink layer to | ||
142 | allow the userspace tools (see below) to communicate with the driver. | ||
143 | This can be found in the kernel configuration here: | ||
144 | |||
145 | -> Networking support | ||
146 | -> Networking options | ||
147 | -> Data Center Bridging support | ||
148 | |||
149 | Once this is selected, DCB support must be selected for ixgbe. This can | ||
150 | be found here: | ||
151 | |||
152 | -> Device Drivers | ||
153 | -> Network device support (NETDEVICES [=y]) | ||
154 | -> Ethernet (10000 Mbit) (NETDEV_10000 [=y]) | ||
155 | -> Intel(R) 10GbE PCI Express adapters support | ||
156 | -> Data Center Bridging (DCB) Support | ||
157 | |||
158 | After these options are selected, you must rebuild your kernel and your | ||
159 | modules. | ||
160 | |||
161 | In order to use DCB, userspace tools must be downloaded and installed. | ||
162 | The dcbd tools can be found at: | ||
163 | |||
164 | http://e1000.sf.net | ||
165 | |||
166 | |||
167 | Ethtool | ||
168 | ------- | ||
169 | The driver utilizes the ethtool interface for driver configuration and | ||
170 | diagnostics, as well as displaying statistical information. Ethtool | ||
171 | version 3.0 or later is required for this functionality. | ||
172 | |||
173 | The latest release of ethtool can be found from | ||
174 | http://sourceforge.net/projects/gkernel. | ||
175 | |||
176 | |||
177 | NAPI | ||
178 | ---- | ||
179 | |||
180 | NAPI (Rx polling mode) is supported in the ixgbe driver. NAPI is enabled | ||
181 | by default in the driver. | ||
182 | |||
183 | See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI. | ||
184 | |||
185 | |||
186 | Support | ||
187 | ======= | ||
188 | |||
189 | For general information, go to the Intel support website at: | ||
190 | |||
191 | http://support.intel.com | ||
192 | |||
193 | or the Intel Wired Networking project hosted by Sourceforge at: | ||
194 | |||
195 | http://e1000.sourceforge.net | ||
196 | |||
197 | If an issue is identified with the released source code on the supported | ||
198 | kernel with a supported adapter, email the specific information related | ||
199 | to the issue to e1000-devel@lists.sf.net | ||
diff --git a/Documentation/networking/rds.txt b/Documentation/networking/rds.txt new file mode 100644 index 000000000000..c67077cbeb80 --- /dev/null +++ b/Documentation/networking/rds.txt | |||
@@ -0,0 +1,356 @@ | |||
1 | |||
2 | Overview | ||
3 | ======== | ||
4 | |||
5 | This readme tries to provide some background on the hows and whys of RDS, | ||
6 | and will hopefully help you find your way around the code. | ||
7 | |||
8 | In addition, please see this email about RDS origins: | ||
9 | http://oss.oracle.com/pipermail/rds-devel/2007-November/000228.html | ||
10 | |||
11 | RDS Architecture | ||
12 | ================ | ||
13 | |||
14 | RDS provides reliable, ordered datagram delivery by using a single | ||
15 | reliable connection between any two nodes in the cluster. This allows | ||
16 | applications to use a single socket to talk to any other process in the | ||
17 | cluster - so in a cluster with N processes you need N sockets, in contrast | ||
18 | to N*N if you use a connection-oriented socket transport like TCP. | ||
19 | |||
20 | RDS is not Infiniband-specific; it was designed to support different | ||
21 | transports. The current implementation used to support RDS over TCP as well | ||
22 | as IB. Work is in progress to support RDS over iWARP, and using DCE to | ||
23 | guarantee no dropped packets on Ethernet, it may be possible to use RDS over | ||
24 | UDP in the future. | ||
25 | |||
26 | The high-level semantics of RDS from the application's point of view are | ||
27 | |||
28 | * Addressing | ||
29 | RDS uses IPv4 addresses and 16bit port numbers to identify | ||
30 | the end point of a connection. All socket operations that involve | ||
31 | passing addresses between kernel and user space generally | ||
32 | use a struct sockaddr_in. | ||
33 | |||
34 | The fact that IPv4 addresses are used does not mean the underlying | ||
35 | transport has to be IP-based. In fact, RDS over IB uses a | ||
36 | reliable IB connection; the IP address is used exclusively to | ||
37 | locate the remote node's GID (by ARPing for the given IP). | ||
38 | |||
39 | The port space is entirely independent of UDP, TCP or any other | ||
40 | protocol. | ||
41 | |||
42 | * Socket interface | ||
43 | RDS sockets work *mostly* as you would expect from a BSD | ||
44 | socket. The next section will cover the details. At any rate, | ||
45 | all I/O is performed through the standard BSD socket API. | ||
46 | Some additions like zerocopy support are implemented through | ||
47 | control messages, while other extensions use the getsockopt/ | ||
48 | setsockopt calls. | ||
49 | |||
50 | Sockets must be bound before you can send or receive data. | ||
51 | This is needed because binding also selects a transport and | ||
52 | attaches it to the socket. Once bound, the transport assignment | ||
53 | does not change. RDS will tolerate IPs moving around (eg in | ||
54 | a active-active HA scenario), but only as long as the address | ||
55 | doesn't move to a different transport. | ||
56 | |||
57 | * sysctls | ||
58 | RDS supports a number of sysctls in /proc/sys/net/rds | ||
59 | |||
60 | |||
61 | Socket Interface | ||
62 | ================ | ||
63 | |||
64 | AF_RDS, PF_RDS, SOL_RDS | ||
65 | These constants haven't been assigned yet, because RDS isn't in | ||
66 | mainline yet. Currently, the kernel module assigns some constant | ||
67 | and publishes it to user space through two sysctl files | ||
68 | /proc/sys/net/rds/pf_rds | ||
69 | /proc/sys/net/rds/sol_rds | ||
70 | |||
71 | fd = socket(PF_RDS, SOCK_SEQPACKET, 0); | ||
72 | This creates a new, unbound RDS socket. | ||
73 | |||
74 | setsockopt(SOL_SOCKET): send and receive buffer size | ||
75 | RDS honors the send and receive buffer size socket options. | ||
76 | You are not allowed to queue more than SO_SNDSIZE bytes to | ||
77 | a socket. A message is queued when sendmsg is called, and | ||
78 | it leaves the queue when the remote system acknowledges | ||
79 | its arrival. | ||
80 | |||
81 | The SO_RCVSIZE option controls the maximum receive queue length. | ||
82 | This is a soft limit rather than a hard limit - RDS will | ||
83 | continue to accept and queue incoming messages, even if that | ||
84 | takes the queue length over the limit. However, it will also | ||
85 | mark the port as "congested" and send a congestion update to | ||
86 | the source node. The source node is supposed to throttle any | ||
87 | processes sending to this congested port. | ||
88 | |||
89 | bind(fd, &sockaddr_in, ...) | ||
90 | This binds the socket to a local IP address and port, and a | ||
91 | transport. | ||
92 | |||
93 | sendmsg(fd, ...) | ||
94 | Sends a message to the indicated recipient. The kernel will | ||
95 | transparently establish the underlying reliable connection | ||
96 | if it isn't up yet. | ||
97 | |||
98 | An attempt to send a message that exceeds SO_SNDSIZE will | ||
99 | return with -EMSGSIZE | ||
100 | |||
101 | An attempt to send a message that would take the total number | ||
102 | of queued bytes over the SO_SNDSIZE threshold will return | ||
103 | EAGAIN. | ||
104 | |||
105 | An attempt to send a message to a destination that is marked | ||
106 | as "congested" will return ENOBUFS. | ||
107 | |||
108 | recvmsg(fd, ...) | ||
109 | Receives a message that was queued to this socket. The sockets | ||
110 | recv queue accounting is adjusted, and if the queue length | ||
111 | drops below SO_SNDSIZE, the port is marked uncongested, and | ||
112 | a congestion update is sent to all peers. | ||
113 | |||
114 | Applications can ask the RDS kernel module to receive | ||
115 | notifications via control messages (for instance, there is a | ||
116 | notification when a congestion update arrived, or when a RDMA | ||
117 | operation completes). These notifications are received through | ||
118 | the msg.msg_control buffer of struct msghdr. The format of the | ||
119 | messages is described in manpages. | ||
120 | |||
121 | poll(fd) | ||
122 | RDS supports the poll interface to allow the application | ||
123 | to implement async I/O. | ||
124 | |||
125 | POLLIN handling is pretty straightforward. When there's an | ||
126 | incoming message queued to the socket, or a pending notification, | ||
127 | we signal POLLIN. | ||
128 | |||
129 | POLLOUT is a little harder. Since you can essentially send | ||
130 | to any destination, RDS will always signal POLLOUT as long as | ||
131 | there's room on the send queue (ie the number of bytes queued | ||
132 | is less than the sendbuf size). | ||
133 | |||
134 | However, the kernel will refuse to accept messages to | ||
135 | a destination marked congested - in this case you will loop | ||
136 | forever if you rely on poll to tell you what to do. | ||
137 | This isn't a trivial problem, but applications can deal with | ||
138 | this - by using congestion notifications, and by checking for | ||
139 | ENOBUFS errors returned by sendmsg. | ||
140 | |||
141 | setsockopt(SOL_RDS, RDS_CANCEL_SENT_TO, &sockaddr_in) | ||
142 | This allows the application to discard all messages queued to a | ||
143 | specific destination on this particular socket. | ||
144 | |||
145 | This allows the application to cancel outstanding messages if | ||
146 | it detects a timeout. For instance, if it tried to send a message, | ||
147 | and the remote host is unreachable, RDS will keep trying forever. | ||
148 | The application may decide it's not worth it, and cancel the | ||
149 | operation. In this case, it would use RDS_CANCEL_SENT_TO to | ||
150 | nuke any pending messages. | ||
151 | |||
152 | |||
153 | RDMA for RDS | ||
154 | ============ | ||
155 | |||
156 | see rds-rdma(7) manpage (available in rds-tools) | ||
157 | |||
158 | |||
159 | Congestion Notifications | ||
160 | ======================== | ||
161 | |||
162 | see rds(7) manpage | ||
163 | |||
164 | |||
165 | RDS Protocol | ||
166 | ============ | ||
167 | |||
168 | Message header | ||
169 | |||
170 | The message header is a 'struct rds_header' (see rds.h): | ||
171 | Fields: | ||
172 | h_sequence: | ||
173 | per-packet sequence number | ||
174 | h_ack: | ||
175 | piggybacked acknowledgment of last packet received | ||
176 | h_len: | ||
177 | length of data, not including header | ||
178 | h_sport: | ||
179 | source port | ||
180 | h_dport: | ||
181 | destination port | ||
182 | h_flags: | ||
183 | CONG_BITMAP - this is a congestion update bitmap | ||
184 | ACK_REQUIRED - receiver must ack this packet | ||
185 | RETRANSMITTED - packet has previously been sent | ||
186 | h_credit: | ||
187 | indicate to other end of connection that | ||
188 | it has more credits available (i.e. there is | ||
189 | more send room) | ||
190 | h_padding[4]: | ||
191 | unused, for future use | ||
192 | h_csum: | ||
193 | header checksum | ||
194 | h_exthdr: | ||
195 | optional data can be passed here. This is currently used for | ||
196 | passing RDMA-related information. | ||
197 | |||
198 | ACK and retransmit handling | ||
199 | |||
200 | One might think that with reliable IB connections you wouldn't need | ||
201 | to ack messages that have been received. The problem is that IB | ||
202 | hardware generates an ack message before it has DMAed the message | ||
203 | into memory. This creates a potential message loss if the HCA is | ||
204 | disabled for any reason between when it sends the ack and before | ||
205 | the message is DMAed and processed. This is only a potential issue | ||
206 | if another HCA is available for fail-over. | ||
207 | |||
208 | Sending an ack immediately would allow the sender to free the sent | ||
209 | message from their send queue quickly, but could cause excessive | ||
210 | traffic to be used for acks. RDS piggybacks acks on sent data | ||
211 | packets. Ack-only packets are reduced by only allowing one to be | ||
212 | in flight at a time, and by the sender only asking for acks when | ||
213 | its send buffers start to fill up. All retransmissions are also | ||
214 | acked. | ||
215 | |||
216 | Flow Control | ||
217 | |||
218 | RDS's IB transport uses a credit-based mechanism to verify that | ||
219 | there is space in the peer's receive buffers for more data. This | ||
220 | eliminates the need for hardware retries on the connection. | ||
221 | |||
222 | Congestion | ||
223 | |||
224 | Messages waiting in the receive queue on the receiving socket | ||
225 | are accounted against the sockets SO_RCVBUF option value. Only | ||
226 | the payload bytes in the message are accounted for. If the | ||
227 | number of bytes queued equals or exceeds rcvbuf then the socket | ||
228 | is congested. All sends attempted to this socket's address | ||
229 | should return block or return -EWOULDBLOCK. | ||
230 | |||
231 | Applications are expected to be reasonably tuned such that this | ||
232 | situation very rarely occurs. An application encountering this | ||
233 | "back-pressure" is considered a bug. | ||
234 | |||
235 | This is implemented by having each node maintain bitmaps which | ||
236 | indicate which ports on bound addresses are congested. As the | ||
237 | bitmap changes it is sent through all the connections which | ||
238 | terminate in the local address of the bitmap which changed. | ||
239 | |||
240 | The bitmaps are allocated as connections are brought up. This | ||
241 | avoids allocation in the interrupt handling path which queues | ||
242 | sages on sockets. The dense bitmaps let transports send the | ||
243 | entire bitmap on any bitmap change reasonably efficiently. This | ||
244 | is much easier to implement than some finer-grained | ||
245 | communication of per-port congestion. The sender does a very | ||
246 | inexpensive bit test to test if the port it's about to send to | ||
247 | is congested or not. | ||
248 | |||
249 | |||
250 | RDS Transport Layer | ||
251 | ================== | ||
252 | |||
253 | As mentioned above, RDS is not IB-specific. Its code is divided | ||
254 | into a general RDS layer and a transport layer. | ||
255 | |||
256 | The general layer handles the socket API, congestion handling, | ||
257 | loopback, stats, usermem pinning, and the connection state machine. | ||
258 | |||
259 | The transport layer handles the details of the transport. The IB | ||
260 | transport, for example, handles all the queue pairs, work requests, | ||
261 | CM event handlers, and other Infiniband details. | ||
262 | |||
263 | |||
264 | RDS Kernel Structures | ||
265 | ===================== | ||
266 | |||
267 | struct rds_message | ||
268 | aka possibly "rds_outgoing", the generic RDS layer copies data to | ||
269 | be sent and sets header fields as needed, based on the socket API. | ||
270 | This is then queued for the individual connection and sent by the | ||
271 | connection's transport. | ||
272 | struct rds_incoming | ||
273 | a generic struct referring to incoming data that can be handed from | ||
274 | the transport to the general code and queued by the general code | ||
275 | while the socket is awoken. It is then passed back to the transport | ||
276 | code to handle the actual copy-to-user. | ||
277 | struct rds_socket | ||
278 | per-socket information | ||
279 | struct rds_connection | ||
280 | per-connection information | ||
281 | struct rds_transport | ||
282 | pointers to transport-specific functions | ||
283 | struct rds_statistics | ||
284 | non-transport-specific statistics | ||
285 | struct rds_cong_map | ||
286 | wraps the raw congestion bitmap, contains rbnode, waitq, etc. | ||
287 | |||
288 | Connection management | ||
289 | ===================== | ||
290 | |||
291 | Connections may be in UP, DOWN, CONNECTING, DISCONNECTING, and | ||
292 | ERROR states. | ||
293 | |||
294 | The first time an attempt is made by an RDS socket to send data to | ||
295 | a node, a connection is allocated and connected. That connection is | ||
296 | then maintained forever -- if there are transport errors, the | ||
297 | connection will be dropped and re-established. | ||
298 | |||
299 | Dropping a connection while packets are queued will cause queued or | ||
300 | partially-sent datagrams to be retransmitted when the connection is | ||
301 | re-established. | ||
302 | |||
303 | |||
304 | The send path | ||
305 | ============= | ||
306 | |||
307 | rds_sendmsg() | ||
308 | struct rds_message built from incoming data | ||
309 | CMSGs parsed (e.g. RDMA ops) | ||
310 | transport connection alloced and connected if not already | ||
311 | rds_message placed on send queue | ||
312 | send worker awoken | ||
313 | rds_send_worker() | ||
314 | calls rds_send_xmit() until queue is empty | ||
315 | rds_send_xmit() | ||
316 | transmits congestion map if one is pending | ||
317 | may set ACK_REQUIRED | ||
318 | calls transport to send either non-RDMA or RDMA message | ||
319 | (RDMA ops never retransmitted) | ||
320 | rds_ib_xmit() | ||
321 | allocs work requests from send ring | ||
322 | adds any new send credits available to peer (h_credits) | ||
323 | maps the rds_message's sg list | ||
324 | piggybacks ack | ||
325 | populates work requests | ||
326 | post send to connection's queue pair | ||
327 | |||
328 | The recv path | ||
329 | ============= | ||
330 | |||
331 | rds_ib_recv_cq_comp_handler() | ||
332 | looks at write completions | ||
333 | unmaps recv buffer from device | ||
334 | no errors, call rds_ib_process_recv() | ||
335 | refill recv ring | ||
336 | rds_ib_process_recv() | ||
337 | validate header checksum | ||
338 | copy header to rds_ib_incoming struct if start of a new datagram | ||
339 | add to ibinc's fraglist | ||
340 | if competed datagram: | ||
341 | update cong map if datagram was cong update | ||
342 | call rds_recv_incoming() otherwise | ||
343 | note if ack is required | ||
344 | rds_recv_incoming() | ||
345 | drop duplicate packets | ||
346 | respond to pings | ||
347 | find the sock associated with this datagram | ||
348 | add to sock queue | ||
349 | wake up sock | ||
350 | do some congestion calculations | ||
351 | rds_recvmsg | ||
352 | copy data into user iovec | ||
353 | handle CMSGs | ||
354 | return to application | ||
355 | |||
356 | |||
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt new file mode 100644 index 000000000000..0e58b4539176 --- /dev/null +++ b/Documentation/networking/timestamping.txt | |||
@@ -0,0 +1,180 @@ | |||
1 | The existing interfaces for getting network packages time stamped are: | ||
2 | |||
3 | * SO_TIMESTAMP | ||
4 | Generate time stamp for each incoming packet using the (not necessarily | ||
5 | monotonous!) system time. Result is returned via recv_msg() in a | ||
6 | control message as timeval (usec resolution). | ||
7 | |||
8 | * SO_TIMESTAMPNS | ||
9 | Same time stamping mechanism as SO_TIMESTAMP, but returns result as | ||
10 | timespec (nsec resolution). | ||
11 | |||
12 | * IP_MULTICAST_LOOP + SO_TIMESTAMP[NS] | ||
13 | Only for multicasts: approximate send time stamp by receiving the looped | ||
14 | packet and using its receive time stamp. | ||
15 | |||
16 | The following interface complements the existing ones: receive time | ||
17 | stamps can be generated and returned for arbitrary packets and much | ||
18 | closer to the point where the packet is really sent. Time stamps can | ||
19 | be generated in software (as before) or in hardware (if the hardware | ||
20 | has such a feature). | ||
21 | |||
22 | SO_TIMESTAMPING: | ||
23 | |||
24 | Instructs the socket layer which kind of information is wanted. The | ||
25 | parameter is an integer with some of the following bits set. Setting | ||
26 | other bits is an error and doesn't change the current state. | ||
27 | |||
28 | SOF_TIMESTAMPING_TX_HARDWARE: try to obtain send time stamp in hardware | ||
29 | SOF_TIMESTAMPING_TX_SOFTWARE: if SOF_TIMESTAMPING_TX_HARDWARE is off or | ||
30 | fails, then do it in software | ||
31 | SOF_TIMESTAMPING_RX_HARDWARE: return the original, unmodified time stamp | ||
32 | as generated by the hardware | ||
33 | SOF_TIMESTAMPING_RX_SOFTWARE: if SOF_TIMESTAMPING_RX_HARDWARE is off or | ||
34 | fails, then do it in software | ||
35 | SOF_TIMESTAMPING_RAW_HARDWARE: return original raw hardware time stamp | ||
36 | SOF_TIMESTAMPING_SYS_HARDWARE: return hardware time stamp transformed to | ||
37 | the system time base | ||
38 | SOF_TIMESTAMPING_SOFTWARE: return system time stamp generated in | ||
39 | software | ||
40 | |||
41 | SOF_TIMESTAMPING_TX/RX determine how time stamps are generated. | ||
42 | SOF_TIMESTAMPING_RAW/SYS determine how they are reported in the | ||
43 | following control message: | ||
44 | struct scm_timestamping { | ||
45 | struct timespec systime; | ||
46 | struct timespec hwtimetrans; | ||
47 | struct timespec hwtimeraw; | ||
48 | }; | ||
49 | |||
50 | recvmsg() can be used to get this control message for regular incoming | ||
51 | packets. For send time stamps the outgoing packet is looped back to | ||
52 | the socket's error queue with the send time stamp(s) attached. It can | ||
53 | be received with recvmsg(flags=MSG_ERRQUEUE). The call returns the | ||
54 | original outgoing packet data including all headers preprended down to | ||
55 | and including the link layer, the scm_timestamping control message and | ||
56 | a sock_extended_err control message with ee_errno==ENOMSG and | ||
57 | ee_origin==SO_EE_ORIGIN_TIMESTAMPING. A socket with such a pending | ||
58 | bounced packet is ready for reading as far as select() is concerned. | ||
59 | If the outgoing packet has to be fragmented, then only the first | ||
60 | fragment is time stamped and returned to the sending socket. | ||
61 | |||
62 | All three values correspond to the same event in time, but were | ||
63 | generated in different ways. Each of these values may be empty (= all | ||
64 | zero), in which case no such value was available. If the application | ||
65 | is not interested in some of these values, they can be left blank to | ||
66 | avoid the potential overhead of calculating them. | ||
67 | |||
68 | systime is the value of the system time at that moment. This | ||
69 | corresponds to the value also returned via SO_TIMESTAMP[NS]. If the | ||
70 | time stamp was generated by hardware, then this field is | ||
71 | empty. Otherwise it is filled in if SOF_TIMESTAMPING_SOFTWARE is | ||
72 | set. | ||
73 | |||
74 | hwtimeraw is the original hardware time stamp. Filled in if | ||
75 | SOF_TIMESTAMPING_RAW_HARDWARE is set. No assumptions about its | ||
76 | relation to system time should be made. | ||
77 | |||
78 | hwtimetrans is the hardware time stamp transformed so that it | ||
79 | corresponds as good as possible to system time. This correlation is | ||
80 | not perfect; as a consequence, sorting packets received via different | ||
81 | NICs by their hwtimetrans may differ from the order in which they were | ||
82 | received. hwtimetrans may be non-monotonic even for the same NIC. | ||
83 | Filled in if SOF_TIMESTAMPING_SYS_HARDWARE is set. Requires support | ||
84 | by the network device and will be empty without that support. | ||
85 | |||
86 | |||
87 | SIOCSHWTSTAMP: | ||
88 | |||
89 | Hardware time stamping must also be initialized for each device driver | ||
90 | that is expected to do hardware time stamping. The parameter is: | ||
91 | |||
92 | struct hwtstamp_config { | ||
93 | int flags; /* no flags defined right now, must be zero */ | ||
94 | int tx_type; /* HWTSTAMP_TX_* */ | ||
95 | int rx_filter; /* HWTSTAMP_FILTER_* */ | ||
96 | }; | ||
97 | |||
98 | Desired behavior is passed into the kernel and to a specific device by | ||
99 | calling ioctl(SIOCSHWTSTAMP) with a pointer to a struct ifreq whose | ||
100 | ifr_data points to a struct hwtstamp_config. The tx_type and | ||
101 | rx_filter are hints to the driver what it is expected to do. If | ||
102 | the requested fine-grained filtering for incoming packets is not | ||
103 | supported, the driver may time stamp more than just the requested types | ||
104 | of packets. | ||
105 | |||
106 | A driver which supports hardware time stamping shall update the struct | ||
107 | with the actual, possibly more permissive configuration. If the | ||
108 | requested packets cannot be time stamped, then nothing should be | ||
109 | changed and ERANGE shall be returned (in contrast to EINVAL, which | ||
110 | indicates that SIOCSHWTSTAMP is not supported at all). | ||
111 | |||
112 | Only a processes with admin rights may change the configuration. User | ||
113 | space is responsible to ensure that multiple processes don't interfere | ||
114 | with each other and that the settings are reset. | ||
115 | |||
116 | /* possible values for hwtstamp_config->tx_type */ | ||
117 | enum { | ||
118 | /* | ||
119 | * no outgoing packet will need hardware time stamping; | ||
120 | * should a packet arrive which asks for it, no hardware | ||
121 | * time stamping will be done | ||
122 | */ | ||
123 | HWTSTAMP_TX_OFF, | ||
124 | |||
125 | /* | ||
126 | * enables hardware time stamping for outgoing packets; | ||
127 | * the sender of the packet decides which are to be | ||
128 | * time stamped by setting SOF_TIMESTAMPING_TX_SOFTWARE | ||
129 | * before sending the packet | ||
130 | */ | ||
131 | HWTSTAMP_TX_ON, | ||
132 | }; | ||
133 | |||
134 | /* possible values for hwtstamp_config->rx_filter */ | ||
135 | enum { | ||
136 | /* time stamp no incoming packet at all */ | ||
137 | HWTSTAMP_FILTER_NONE, | ||
138 | |||
139 | /* time stamp any incoming packet */ | ||
140 | HWTSTAMP_FILTER_ALL, | ||
141 | |||
142 | /* return value: time stamp all packets requested plus some others */ | ||
143 | HWTSTAMP_FILTER_SOME, | ||
144 | |||
145 | /* PTP v1, UDP, any kind of event packet */ | ||
146 | HWTSTAMP_FILTER_PTP_V1_L4_EVENT, | ||
147 | |||
148 | ... | ||
149 | }; | ||
150 | |||
151 | |||
152 | DEVICE IMPLEMENTATION | ||
153 | |||
154 | A driver which supports hardware time stamping must support the | ||
155 | SIOCSHWTSTAMP ioctl. Time stamps for received packets must be stored | ||
156 | in the skb with skb_hwtstamp_set(). | ||
157 | |||
158 | Time stamps for outgoing packets are to be generated as follows: | ||
159 | - In hard_start_xmit(), check if skb_hwtstamp_check_tx_hardware() | ||
160 | returns non-zero. If yes, then the driver is expected | ||
161 | to do hardware time stamping. | ||
162 | - If this is possible for the skb and requested, then declare | ||
163 | that the driver is doing the time stamping by calling | ||
164 | skb_hwtstamp_tx_in_progress(). A driver not supporting | ||
165 | hardware time stamping doesn't do that. A driver must never | ||
166 | touch sk_buff::tstamp! It is used to store how time stamping | ||
167 | for an outgoing packets is to be done. | ||
168 | - As soon as the driver has sent the packet and/or obtained a | ||
169 | hardware time stamp for it, it passes the time stamp back by | ||
170 | calling skb_hwtstamp_tx() with the original skb, the raw | ||
171 | hardware time stamp and a handle to the device (necessary | ||
172 | to convert the hardware time stamp to system time). If obtaining | ||
173 | the hardware time stamp somehow fails, then the driver should | ||
174 | not fall back to software time stamping. The rationale is that | ||
175 | this would occur at a later time in the processing pipeline | ||
176 | than other software time stamping and therefore could lead | ||
177 | to unexpected deltas between time stamps. | ||
178 | - If the driver did not call skb_hwtstamp_tx_in_progress(), then | ||
179 | dev_hard_start_xmit() checks whether software time stamping | ||
180 | is wanted as fallback and potentially generates the time stamp. | ||
diff --git a/Documentation/networking/timestamping/.gitignore b/Documentation/networking/timestamping/.gitignore new file mode 100644 index 000000000000..71e81eb2e22f --- /dev/null +++ b/Documentation/networking/timestamping/.gitignore | |||
@@ -0,0 +1 @@ | |||
timestamping | |||
diff --git a/Documentation/networking/timestamping/Makefile b/Documentation/networking/timestamping/Makefile new file mode 100644 index 000000000000..2a1489fdc036 --- /dev/null +++ b/Documentation/networking/timestamping/Makefile | |||
@@ -0,0 +1,6 @@ | |||
1 | CPPFLAGS = -I../../../include | ||
2 | |||
3 | timestamping: timestamping.c | ||
4 | |||
5 | clean: | ||
6 | rm -f timestamping | ||
diff --git a/Documentation/networking/timestamping/timestamping.c b/Documentation/networking/timestamping/timestamping.c new file mode 100644 index 000000000000..43d143104210 --- /dev/null +++ b/Documentation/networking/timestamping/timestamping.c | |||
@@ -0,0 +1,533 @@ | |||
1 | /* | ||
2 | * This program demonstrates how the various time stamping features in | ||
3 | * the Linux kernel work. It emulates the behavior of a PTP | ||
4 | * implementation in stand-alone master mode by sending PTPv1 Sync | ||
5 | * multicasts once every second. It looks for similar packets, but | ||
6 | * beyond that doesn't actually implement PTP. | ||
7 | * | ||
8 | * Outgoing packets are time stamped with SO_TIMESTAMPING with or | ||
9 | * without hardware support. | ||
10 | * | ||
11 | * Incoming packets are time stamped with SO_TIMESTAMPING with or | ||
12 | * without hardware support, SIOCGSTAMP[NS] (per-socket time stamp) and | ||
13 | * SO_TIMESTAMP[NS]. | ||
14 | * | ||
15 | * Copyright (C) 2009 Intel Corporation. | ||
16 | * Author: Patrick Ohly <patrick.ohly@intel.com> | ||
17 | * | ||
18 | * This program is free software; you can redistribute it and/or modify it | ||
19 | * under the terms and conditions of the GNU General Public License, | ||
20 | * version 2, as published by the Free Software Foundation. | ||
21 | * | ||
22 | * This program is distributed in the hope it will be useful, but WITHOUT | ||
23 | * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or | ||
24 | * FITNESS FOR A PARTICULAR PURPOSE. * See the GNU General Public License for | ||
25 | * more details. | ||
26 | * | ||
27 | * You should have received a copy of the GNU General Public License along with | ||
28 | * this program; if not, write to the Free Software Foundation, Inc., | ||
29 | * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. | ||
30 | */ | ||
31 | |||
32 | #include <stdio.h> | ||
33 | #include <stdlib.h> | ||
34 | #include <errno.h> | ||
35 | #include <string.h> | ||
36 | |||
37 | #include <sys/time.h> | ||
38 | #include <sys/socket.h> | ||
39 | #include <sys/select.h> | ||
40 | #include <sys/ioctl.h> | ||
41 | #include <arpa/inet.h> | ||
42 | #include <net/if.h> | ||
43 | |||
44 | #include "asm/types.h" | ||
45 | #include "linux/net_tstamp.h" | ||
46 | #include "linux/errqueue.h" | ||
47 | |||
48 | #ifndef SO_TIMESTAMPING | ||
49 | # define SO_TIMESTAMPING 37 | ||
50 | # define SCM_TIMESTAMPING SO_TIMESTAMPING | ||
51 | #endif | ||
52 | |||
53 | #ifndef SO_TIMESTAMPNS | ||
54 | # define SO_TIMESTAMPNS 35 | ||
55 | #endif | ||
56 | |||
57 | #ifndef SIOCGSTAMPNS | ||
58 | # define SIOCGSTAMPNS 0x8907 | ||
59 | #endif | ||
60 | |||
61 | #ifndef SIOCSHWTSTAMP | ||
62 | # define SIOCSHWTSTAMP 0x89b0 | ||
63 | #endif | ||
64 | |||
65 | static void usage(const char *error) | ||
66 | { | ||
67 | if (error) | ||
68 | printf("invalid option: %s\n", error); | ||
69 | printf("timestamping interface option*\n\n" | ||
70 | "Options:\n" | ||
71 | " IP_MULTICAST_LOOP - looping outgoing multicasts\n" | ||
72 | " SO_TIMESTAMP - normal software time stamping, ms resolution\n" | ||
73 | " SO_TIMESTAMPNS - more accurate software time stamping\n" | ||
74 | " SOF_TIMESTAMPING_TX_HARDWARE - hardware time stamping of outgoing packets\n" | ||
75 | " SOF_TIMESTAMPING_TX_SOFTWARE - software fallback for outgoing packets\n" | ||
76 | " SOF_TIMESTAMPING_RX_HARDWARE - hardware time stamping of incoming packets\n" | ||
77 | " SOF_TIMESTAMPING_RX_SOFTWARE - software fallback for incoming packets\n" | ||
78 | " SOF_TIMESTAMPING_SOFTWARE - request reporting of software time stamps\n" | ||
79 | " SOF_TIMESTAMPING_SYS_HARDWARE - request reporting of transformed HW time stamps\n" | ||
80 | " SOF_TIMESTAMPING_RAW_HARDWARE - request reporting of raw HW time stamps\n" | ||
81 | " SIOCGSTAMP - check last socket time stamp\n" | ||
82 | " SIOCGSTAMPNS - more accurate socket time stamp\n"); | ||
83 | exit(1); | ||
84 | } | ||
85 | |||
86 | static void bail(const char *error) | ||
87 | { | ||
88 | printf("%s: %s\n", error, strerror(errno)); | ||
89 | exit(1); | ||
90 | } | ||
91 | |||
92 | static const unsigned char sync[] = { | ||
93 | 0x00, 0x01, 0x00, 0x01, | ||
94 | 0x5f, 0x44, 0x46, 0x4c, | ||
95 | 0x54, 0x00, 0x00, 0x00, | ||
96 | 0x00, 0x00, 0x00, 0x00, | ||
97 | 0x00, 0x00, 0x00, 0x00, | ||
98 | 0x01, 0x01, | ||
99 | |||
100 | /* fake uuid */ | ||
101 | 0x00, 0x01, | ||
102 | 0x02, 0x03, 0x04, 0x05, | ||
103 | |||
104 | 0x00, 0x01, 0x00, 0x37, | ||
105 | 0x00, 0x00, 0x00, 0x08, | ||
106 | 0x00, 0x00, 0x00, 0x00, | ||
107 | 0x49, 0x05, 0xcd, 0x01, | ||
108 | 0x29, 0xb1, 0x8d, 0xb0, | ||
109 | 0x00, 0x00, 0x00, 0x00, | ||
110 | 0x00, 0x01, | ||
111 | |||
112 | /* fake uuid */ | ||
113 | 0x00, 0x01, | ||
114 | 0x02, 0x03, 0x04, 0x05, | ||
115 | |||
116 | 0x00, 0x00, 0x00, 0x37, | ||
117 | 0x00, 0x00, 0x00, 0x04, | ||
118 | 0x44, 0x46, 0x4c, 0x54, | ||
119 | 0x00, 0x00, 0xf0, 0x60, | ||
120 | 0x00, 0x01, 0x00, 0x00, | ||
121 | 0x00, 0x00, 0x00, 0x01, | ||
122 | 0x00, 0x00, 0xf0, 0x60, | ||
123 | 0x00, 0x00, 0x00, 0x00, | ||
124 | 0x00, 0x00, 0x00, 0x04, | ||
125 | 0x44, 0x46, 0x4c, 0x54, | ||
126 | 0x00, 0x01, | ||
127 | |||
128 | /* fake uuid */ | ||
129 | 0x00, 0x01, | ||
130 | 0x02, 0x03, 0x04, 0x05, | ||
131 | |||
132 | 0x00, 0x00, 0x00, 0x00, | ||
133 | 0x00, 0x00, 0x00, 0x00, | ||
134 | 0x00, 0x00, 0x00, 0x00, | ||
135 | 0x00, 0x00, 0x00, 0x00 | ||
136 | }; | ||
137 | |||
138 | static void sendpacket(int sock, struct sockaddr *addr, socklen_t addr_len) | ||
139 | { | ||
140 | struct timeval now; | ||
141 | int res; | ||
142 | |||
143 | res = sendto(sock, sync, sizeof(sync), 0, | ||
144 | addr, addr_len); | ||
145 | gettimeofday(&now, 0); | ||
146 | if (res < 0) | ||
147 | printf("%s: %s\n", "send", strerror(errno)); | ||
148 | else | ||
149 | printf("%ld.%06ld: sent %d bytes\n", | ||
150 | (long)now.tv_sec, (long)now.tv_usec, | ||
151 | res); | ||
152 | } | ||
153 | |||
154 | static void printpacket(struct msghdr *msg, int res, | ||
155 | char *data, | ||
156 | int sock, int recvmsg_flags, | ||
157 | int siocgstamp, int siocgstampns) | ||
158 | { | ||
159 | struct sockaddr_in *from_addr = (struct sockaddr_in *)msg->msg_name; | ||
160 | struct cmsghdr *cmsg; | ||
161 | struct timeval tv; | ||
162 | struct timespec ts; | ||
163 | struct timeval now; | ||
164 | |||
165 | gettimeofday(&now, 0); | ||
166 | |||
167 | printf("%ld.%06ld: received %s data, %d bytes from %s, %d bytes control messages\n", | ||
168 | (long)now.tv_sec, (long)now.tv_usec, | ||
169 | (recvmsg_flags & MSG_ERRQUEUE) ? "error" : "regular", | ||
170 | res, | ||
171 | inet_ntoa(from_addr->sin_addr), | ||
172 | msg->msg_controllen); | ||
173 | for (cmsg = CMSG_FIRSTHDR(msg); | ||
174 | cmsg; | ||
175 | cmsg = CMSG_NXTHDR(msg, cmsg)) { | ||
176 | printf(" cmsg len %d: ", cmsg->cmsg_len); | ||
177 | switch (cmsg->cmsg_level) { | ||
178 | case SOL_SOCKET: | ||
179 | printf("SOL_SOCKET "); | ||
180 | switch (cmsg->cmsg_type) { | ||
181 | case SO_TIMESTAMP: { | ||
182 | struct timeval *stamp = | ||
183 | (struct timeval *)CMSG_DATA(cmsg); | ||
184 | printf("SO_TIMESTAMP %ld.%06ld", | ||
185 | (long)stamp->tv_sec, | ||
186 | (long)stamp->tv_usec); | ||
187 | break; | ||
188 | } | ||
189 | case SO_TIMESTAMPNS: { | ||
190 | struct timespec *stamp = | ||
191 | (struct timespec *)CMSG_DATA(cmsg); | ||
192 | printf("SO_TIMESTAMPNS %ld.%09ld", | ||
193 | (long)stamp->tv_sec, | ||
194 | (long)stamp->tv_nsec); | ||
195 | break; | ||
196 | } | ||
197 | case SO_TIMESTAMPING: { | ||
198 | struct timespec *stamp = | ||
199 | (struct timespec *)CMSG_DATA(cmsg); | ||
200 | printf("SO_TIMESTAMPING "); | ||
201 | printf("SW %ld.%09ld ", | ||
202 | (long)stamp->tv_sec, | ||
203 | (long)stamp->tv_nsec); | ||
204 | stamp++; | ||
205 | printf("HW transformed %ld.%09ld ", | ||
206 | (long)stamp->tv_sec, | ||
207 | (long)stamp->tv_nsec); | ||
208 | stamp++; | ||
209 | printf("HW raw %ld.%09ld", | ||
210 | (long)stamp->tv_sec, | ||
211 | (long)stamp->tv_nsec); | ||
212 | break; | ||
213 | } | ||
214 | default: | ||
215 | printf("type %d", cmsg->cmsg_type); | ||
216 | break; | ||
217 | } | ||
218 | break; | ||
219 | case IPPROTO_IP: | ||
220 | printf("IPPROTO_IP "); | ||
221 | switch (cmsg->cmsg_type) { | ||
222 | case IP_RECVERR: { | ||
223 | struct sock_extended_err *err = | ||
224 | (struct sock_extended_err *)CMSG_DATA(cmsg); | ||
225 | printf("IP_RECVERR ee_errno '%s' ee_origin %d => %s", | ||
226 | strerror(err->ee_errno), | ||
227 | err->ee_origin, | ||
228 | #ifdef SO_EE_ORIGIN_TIMESTAMPING | ||
229 | err->ee_origin == SO_EE_ORIGIN_TIMESTAMPING ? | ||
230 | "bounced packet" : "unexpected origin" | ||
231 | #else | ||
232 | "probably SO_EE_ORIGIN_TIMESTAMPING" | ||
233 | #endif | ||
234 | ); | ||
235 | if (res < sizeof(sync)) | ||
236 | printf(" => truncated data?!"); | ||
237 | else if (!memcmp(sync, data + res - sizeof(sync), | ||
238 | sizeof(sync))) | ||
239 | printf(" => GOT OUR DATA BACK (HURRAY!)"); | ||
240 | break; | ||
241 | } | ||
242 | case IP_PKTINFO: { | ||
243 | struct in_pktinfo *pktinfo = | ||
244 | (struct in_pktinfo *)CMSG_DATA(cmsg); | ||
245 | printf("IP_PKTINFO interface index %u", | ||
246 | pktinfo->ipi_ifindex); | ||
247 | break; | ||
248 | } | ||
249 | default: | ||
250 | printf("type %d", cmsg->cmsg_type); | ||
251 | break; | ||
252 | } | ||
253 | break; | ||
254 | default: | ||
255 | printf("level %d type %d", | ||
256 | cmsg->cmsg_level, | ||
257 | cmsg->cmsg_type); | ||
258 | break; | ||
259 | } | ||
260 | printf("\n"); | ||
261 | } | ||
262 | |||
263 | if (siocgstamp) { | ||
264 | if (ioctl(sock, SIOCGSTAMP, &tv)) | ||
265 | printf(" %s: %s\n", "SIOCGSTAMP", strerror(errno)); | ||
266 | else | ||
267 | printf("SIOCGSTAMP %ld.%06ld\n", | ||
268 | (long)tv.tv_sec, | ||
269 | (long)tv.tv_usec); | ||
270 | } | ||
271 | if (siocgstampns) { | ||
272 | if (ioctl(sock, SIOCGSTAMPNS, &ts)) | ||
273 | printf(" %s: %s\n", "SIOCGSTAMPNS", strerror(errno)); | ||
274 | else | ||
275 | printf("SIOCGSTAMPNS %ld.%09ld\n", | ||
276 | (long)ts.tv_sec, | ||
277 | (long)ts.tv_nsec); | ||
278 | } | ||
279 | } | ||
280 | |||
281 | static void recvpacket(int sock, int recvmsg_flags, | ||
282 | int siocgstamp, int siocgstampns) | ||
283 | { | ||
284 | char data[256]; | ||
285 | struct msghdr msg; | ||
286 | struct iovec entry; | ||
287 | struct sockaddr_in from_addr; | ||
288 | struct { | ||
289 | struct cmsghdr cm; | ||
290 | char control[512]; | ||
291 | } control; | ||
292 | int res; | ||
293 | |||
294 | memset(&msg, 0, sizeof(msg)); | ||
295 | msg.msg_iov = &entry; | ||
296 | msg.msg_iovlen = 1; | ||
297 | entry.iov_base = data; | ||
298 | entry.iov_len = sizeof(data); | ||
299 | msg.msg_name = (caddr_t)&from_addr; | ||
300 | msg.msg_namelen = sizeof(from_addr); | ||
301 | msg.msg_control = &control; | ||
302 | msg.msg_controllen = sizeof(control); | ||
303 | |||
304 | res = recvmsg(sock, &msg, recvmsg_flags|MSG_DONTWAIT); | ||
305 | if (res < 0) { | ||
306 | printf("%s %s: %s\n", | ||
307 | "recvmsg", | ||
308 | (recvmsg_flags & MSG_ERRQUEUE) ? "error" : "regular", | ||
309 | strerror(errno)); | ||
310 | } else { | ||
311 | printpacket(&msg, res, data, | ||
312 | sock, recvmsg_flags, | ||
313 | siocgstamp, siocgstampns); | ||
314 | } | ||
315 | } | ||
316 | |||
317 | int main(int argc, char **argv) | ||
318 | { | ||
319 | int so_timestamping_flags = 0; | ||
320 | int so_timestamp = 0; | ||
321 | int so_timestampns = 0; | ||
322 | int siocgstamp = 0; | ||
323 | int siocgstampns = 0; | ||
324 | int ip_multicast_loop = 0; | ||
325 | char *interface; | ||
326 | int i; | ||
327 | int enabled = 1; | ||
328 | int sock; | ||
329 | struct ifreq device; | ||
330 | struct ifreq hwtstamp; | ||
331 | struct hwtstamp_config hwconfig, hwconfig_requested; | ||
332 | struct sockaddr_in addr; | ||
333 | struct ip_mreq imr; | ||
334 | struct in_addr iaddr; | ||
335 | int val; | ||
336 | socklen_t len; | ||
337 | struct timeval next; | ||
338 | |||
339 | if (argc < 2) | ||
340 | usage(0); | ||
341 | interface = argv[1]; | ||
342 | |||
343 | for (i = 2; i < argc; i++) { | ||
344 | if (!strcasecmp(argv[i], "SO_TIMESTAMP")) | ||
345 | so_timestamp = 1; | ||
346 | else if (!strcasecmp(argv[i], "SO_TIMESTAMPNS")) | ||
347 | so_timestampns = 1; | ||
348 | else if (!strcasecmp(argv[i], "SIOCGSTAMP")) | ||
349 | siocgstamp = 1; | ||
350 | else if (!strcasecmp(argv[i], "SIOCGSTAMPNS")) | ||
351 | siocgstampns = 1; | ||
352 | else if (!strcasecmp(argv[i], "IP_MULTICAST_LOOP")) | ||
353 | ip_multicast_loop = 1; | ||
354 | else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_TX_HARDWARE")) | ||
355 | so_timestamping_flags |= SOF_TIMESTAMPING_TX_HARDWARE; | ||
356 | else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_TX_SOFTWARE")) | ||
357 | so_timestamping_flags |= SOF_TIMESTAMPING_TX_SOFTWARE; | ||
358 | else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_RX_HARDWARE")) | ||
359 | so_timestamping_flags |= SOF_TIMESTAMPING_RX_HARDWARE; | ||
360 | else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_RX_SOFTWARE")) | ||
361 | so_timestamping_flags |= SOF_TIMESTAMPING_RX_SOFTWARE; | ||
362 | else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_SOFTWARE")) | ||
363 | so_timestamping_flags |= SOF_TIMESTAMPING_SOFTWARE; | ||
364 | else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_SYS_HARDWARE")) | ||
365 | so_timestamping_flags |= SOF_TIMESTAMPING_SYS_HARDWARE; | ||
366 | else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_RAW_HARDWARE")) | ||
367 | so_timestamping_flags |= SOF_TIMESTAMPING_RAW_HARDWARE; | ||
368 | else | ||
369 | usage(argv[i]); | ||
370 | } | ||
371 | |||
372 | sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP); | ||
373 | if (socket < 0) | ||
374 | bail("socket"); | ||
375 | |||
376 | memset(&device, 0, sizeof(device)); | ||
377 | strncpy(device.ifr_name, interface, sizeof(device.ifr_name)); | ||
378 | if (ioctl(sock, SIOCGIFADDR, &device) < 0) | ||
379 | bail("getting interface IP address"); | ||
380 | |||
381 | memset(&hwtstamp, 0, sizeof(hwtstamp)); | ||
382 | strncpy(hwtstamp.ifr_name, interface, sizeof(hwtstamp.ifr_name)); | ||
383 | hwtstamp.ifr_data = (void *)&hwconfig; | ||
384 | memset(&hwconfig, 0, sizeof(&hwconfig)); | ||
385 | hwconfig.tx_type = | ||
386 | (so_timestamping_flags & SOF_TIMESTAMPING_TX_HARDWARE) ? | ||
387 | HWTSTAMP_TX_ON : HWTSTAMP_TX_OFF; | ||
388 | hwconfig.rx_filter = | ||
389 | (so_timestamping_flags & SOF_TIMESTAMPING_RX_HARDWARE) ? | ||
390 | HWTSTAMP_FILTER_PTP_V1_L4_SYNC : HWTSTAMP_FILTER_NONE; | ||
391 | hwconfig_requested = hwconfig; | ||
392 | if (ioctl(sock, SIOCSHWTSTAMP, &hwtstamp) < 0) { | ||
393 | if ((errno == EINVAL || errno == ENOTSUP) && | ||
394 | hwconfig_requested.tx_type == HWTSTAMP_TX_OFF && | ||
395 | hwconfig_requested.rx_filter == HWTSTAMP_FILTER_NONE) | ||
396 | printf("SIOCSHWTSTAMP: disabling hardware time stamping not possible\n"); | ||
397 | else | ||
398 | bail("SIOCSHWTSTAMP"); | ||
399 | } | ||
400 | printf("SIOCSHWTSTAMP: tx_type %d requested, got %d; rx_filter %d requested, got %d\n", | ||
401 | hwconfig_requested.tx_type, hwconfig.tx_type, | ||
402 | hwconfig_requested.rx_filter, hwconfig.rx_filter); | ||
403 | |||
404 | /* bind to PTP port */ | ||
405 | addr.sin_family = AF_INET; | ||
406 | addr.sin_addr.s_addr = htonl(INADDR_ANY); | ||
407 | addr.sin_port = htons(319 /* PTP event port */); | ||
408 | if (bind(sock, | ||
409 | (struct sockaddr *)&addr, | ||
410 | sizeof(struct sockaddr_in)) < 0) | ||
411 | bail("bind"); | ||
412 | |||
413 | /* set multicast group for outgoing packets */ | ||
414 | inet_aton("224.0.1.130", &iaddr); /* alternate PTP domain 1 */ | ||
415 | addr.sin_addr = iaddr; | ||
416 | imr.imr_multiaddr.s_addr = iaddr.s_addr; | ||
417 | imr.imr_interface.s_addr = | ||
418 | ((struct sockaddr_in *)&device.ifr_addr)->sin_addr.s_addr; | ||
419 | if (setsockopt(sock, IPPROTO_IP, IP_MULTICAST_IF, | ||
420 | &imr.imr_interface.s_addr, sizeof(struct in_addr)) < 0) | ||
421 | bail("set multicast"); | ||
422 | |||
423 | /* join multicast group, loop our own packet */ | ||
424 | if (setsockopt(sock, IPPROTO_IP, IP_ADD_MEMBERSHIP, | ||
425 | &imr, sizeof(struct ip_mreq)) < 0) | ||
426 | bail("join multicast group"); | ||
427 | |||
428 | if (setsockopt(sock, IPPROTO_IP, IP_MULTICAST_LOOP, | ||
429 | &ip_multicast_loop, sizeof(enabled)) < 0) { | ||
430 | bail("loop multicast"); | ||
431 | } | ||
432 | |||
433 | /* set socket options for time stamping */ | ||
434 | if (so_timestamp && | ||
435 | setsockopt(sock, SOL_SOCKET, SO_TIMESTAMP, | ||
436 | &enabled, sizeof(enabled)) < 0) | ||
437 | bail("setsockopt SO_TIMESTAMP"); | ||
438 | |||
439 | if (so_timestampns && | ||
440 | setsockopt(sock, SOL_SOCKET, SO_TIMESTAMPNS, | ||
441 | &enabled, sizeof(enabled)) < 0) | ||
442 | bail("setsockopt SO_TIMESTAMPNS"); | ||
443 | |||
444 | if (so_timestamping_flags && | ||
445 | setsockopt(sock, SOL_SOCKET, SO_TIMESTAMPING, | ||
446 | &so_timestamping_flags, | ||
447 | sizeof(so_timestamping_flags)) < 0) | ||
448 | bail("setsockopt SO_TIMESTAMPING"); | ||
449 | |||
450 | /* request IP_PKTINFO for debugging purposes */ | ||
451 | if (setsockopt(sock, SOL_IP, IP_PKTINFO, | ||
452 | &enabled, sizeof(enabled)) < 0) | ||
453 | printf("%s: %s\n", "setsockopt IP_PKTINFO", strerror(errno)); | ||
454 | |||
455 | /* verify socket options */ | ||
456 | len = sizeof(val); | ||
457 | if (getsockopt(sock, SOL_SOCKET, SO_TIMESTAMP, &val, &len) < 0) | ||
458 | printf("%s: %s\n", "getsockopt SO_TIMESTAMP", strerror(errno)); | ||
459 | else | ||
460 | printf("SO_TIMESTAMP %d\n", val); | ||
461 | |||
462 | if (getsockopt(sock, SOL_SOCKET, SO_TIMESTAMPNS, &val, &len) < 0) | ||
463 | printf("%s: %s\n", "getsockopt SO_TIMESTAMPNS", | ||
464 | strerror(errno)); | ||
465 | else | ||
466 | printf("SO_TIMESTAMPNS %d\n", val); | ||
467 | |||
468 | if (getsockopt(sock, SOL_SOCKET, SO_TIMESTAMPING, &val, &len) < 0) { | ||
469 | printf("%s: %s\n", "getsockopt SO_TIMESTAMPING", | ||
470 | strerror(errno)); | ||
471 | } else { | ||
472 | printf("SO_TIMESTAMPING %d\n", val); | ||
473 | if (val != so_timestamping_flags) | ||
474 | printf(" not the expected value %d\n", | ||
475 | so_timestamping_flags); | ||
476 | } | ||
477 | |||
478 | /* send packets forever every five seconds */ | ||
479 | gettimeofday(&next, 0); | ||
480 | next.tv_sec = (next.tv_sec + 1) / 5 * 5; | ||
481 | next.tv_usec = 0; | ||
482 | while (1) { | ||
483 | struct timeval now; | ||
484 | struct timeval delta; | ||
485 | long delta_us; | ||
486 | int res; | ||
487 | fd_set readfs, errorfs; | ||
488 | |||
489 | gettimeofday(&now, 0); | ||
490 | delta_us = (long)(next.tv_sec - now.tv_sec) * 1000000 + | ||
491 | (long)(next.tv_usec - now.tv_usec); | ||
492 | if (delta_us > 0) { | ||
493 | /* continue waiting for timeout or data */ | ||
494 | delta.tv_sec = delta_us / 1000000; | ||
495 | delta.tv_usec = delta_us % 1000000; | ||
496 | |||
497 | FD_ZERO(&readfs); | ||
498 | FD_ZERO(&errorfs); | ||
499 | FD_SET(sock, &readfs); | ||
500 | FD_SET(sock, &errorfs); | ||
501 | printf("%ld.%06ld: select %ldus\n", | ||
502 | (long)now.tv_sec, (long)now.tv_usec, | ||
503 | delta_us); | ||
504 | res = select(sock + 1, &readfs, 0, &errorfs, &delta); | ||
505 | gettimeofday(&now, 0); | ||
506 | printf("%ld.%06ld: select returned: %d, %s\n", | ||
507 | (long)now.tv_sec, (long)now.tv_usec, | ||
508 | res, | ||
509 | res < 0 ? strerror(errno) : "success"); | ||
510 | if (res > 0) { | ||
511 | if (FD_ISSET(sock, &readfs)) | ||
512 | printf("ready for reading\n"); | ||
513 | if (FD_ISSET(sock, &errorfs)) | ||
514 | printf("has error\n"); | ||
515 | recvpacket(sock, 0, | ||
516 | siocgstamp, | ||
517 | siocgstampns); | ||
518 | recvpacket(sock, MSG_ERRQUEUE, | ||
519 | siocgstamp, | ||
520 | siocgstampns); | ||
521 | } | ||
522 | } else { | ||
523 | /* write one packet */ | ||
524 | sendpacket(sock, | ||
525 | (struct sockaddr *)&addr, | ||
526 | sizeof(addr)); | ||
527 | next.tv_sec += 5; | ||
528 | continue; | ||
529 | } | ||
530 | } | ||
531 | |||
532 | return 0; | ||
533 | } | ||
diff --git a/Documentation/networking/vxge.txt b/Documentation/networking/vxge.txt new file mode 100644 index 000000000000..d2e2997e6fa0 --- /dev/null +++ b/Documentation/networking/vxge.txt | |||
@@ -0,0 +1,100 @@ | |||
1 | Neterion's (Formerly S2io) X3100 Series 10GbE PCIe Server Adapter Linux driver | ||
2 | ============================================================================== | ||
3 | |||
4 | Contents | ||
5 | -------- | ||
6 | |||
7 | 1) Introduction | ||
8 | 2) Features supported | ||
9 | 3) Configurable driver parameters | ||
10 | 4) Troubleshooting | ||
11 | |||
12 | 1) Introduction: | ||
13 | ---------------- | ||
14 | This Linux driver supports all Neterion's X3100 series 10 GbE PCIe I/O | ||
15 | Virtualized Server adapters. | ||
16 | The X3100 series supports four modes of operation, configurable via | ||
17 | firmware - | ||
18 | Single function mode | ||
19 | Multi function mode | ||
20 | SRIOV mode | ||
21 | MRIOV mode | ||
22 | The functions share a 10GbE link and the pci-e bus, but hardly anything else | ||
23 | inside the ASIC. Features like independent hw reset, statistics, bandwidth/ | ||
24 | priority allocation and guarantees, GRO, TSO, interrupt moderation etc are | ||
25 | supported independently on each function. | ||
26 | |||
27 | (See below for a complete list of features supported for both IPv4 and IPv6) | ||
28 | |||
29 | 2) Features supported: | ||
30 | ---------------------- | ||
31 | |||
32 | i) Single function mode (up to 17 queues) | ||
33 | |||
34 | ii) Multi function mode (up to 17 functions) | ||
35 | |||
36 | iii) PCI-SIG's I/O Virtualization | ||
37 | - Single Root mode: v1.0 (up to 17 functions) | ||
38 | - Multi-Root mode: v1.0 (up to 17 functions) | ||
39 | |||
40 | iv) Jumbo frames | ||
41 | X3100 Series supports MTU up to 9600 bytes, modifiable using | ||
42 | ifconfig command. | ||
43 | |||
44 | v) Offloads supported: (Enabled by default) | ||
45 | Checksum offload (TCP/UDP/IP) on transmit and receive paths | ||
46 | TCP Segmentation Offload (TSO) on transmit path | ||
47 | Generic Receive Offload (GRO) on receive path | ||
48 | |||
49 | vi) MSI-X: (Enabled by default) | ||
50 | Resulting in noticeable performance improvement (up to 7% on certain | ||
51 | platforms). | ||
52 | |||
53 | vii) NAPI: (Enabled by default) | ||
54 | For better Rx interrupt moderation. | ||
55 | |||
56 | viii)RTH (Receive Traffic Hash): (Enabled by default) | ||
57 | Receive side steering for better scaling. | ||
58 | |||
59 | ix) Statistics | ||
60 | Comprehensive MAC-level and software statistics displayed using | ||
61 | "ethtool -S" option. | ||
62 | |||
63 | x) Multiple hardware queues: (Enabled by default) | ||
64 | Up to 17 hardware based transmit and receive data channels, with | ||
65 | multiple steering options (transmit multiqueue enabled by default). | ||
66 | |||
67 | 3) Configurable driver parameters: | ||
68 | ---------------------------------- | ||
69 | |||
70 | i) max_config_dev | ||
71 | Specifies maximum device functions to be enabled. | ||
72 | Valid range: 1-8 | ||
73 | |||
74 | ii) max_config_port | ||
75 | Specifies number of ports to be enabled. | ||
76 | Valid range: 1,2 | ||
77 | Default: 1 | ||
78 | |||
79 | iii)max_config_vpath | ||
80 | Specifies maximum VPATH(s) configured for each device function. | ||
81 | Valid range: 1-17 | ||
82 | |||
83 | iv) vlan_tag_strip | ||
84 | Enables/disables vlan tag stripping from all received tagged frames that | ||
85 | are not replicated at the internal L2 switch. | ||
86 | Valid range: 0,1 (disabled, enabled respectively) | ||
87 | Default: 1 | ||
88 | |||
89 | v) addr_learn_en | ||
90 | Enable learning the mac address of the guest OS interface in | ||
91 | virtualization environment. | ||
92 | Valid range: 0,1 (disabled, enabled respectively) | ||
93 | Default: 0 | ||
94 | |||
95 | 4) Troubleshooting: | ||
96 | ------------------- | ||
97 | |||
98 | To resolve an issue with the source code or X3100 series adapter, please collect | ||
99 | the statistics, register dumps using ethool, relevant logs and email them to | ||
100 | support@neterion.com. | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt index 6c238f59b2a9..249db3a15d15 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt +++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt | |||
@@ -1,6 +1,6 @@ | |||
1 | * Uploaded QE firmware | 1 | * Uploaded QE firmware |
2 | 2 | ||
3 | If a new firwmare has been uploaded to the QE (usually by the | 3 | If a new firmware has been uploaded to the QE (usually by the |
4 | boot loader), then a 'firmware' child node should be added to the QE | 4 | boot loader), then a 'firmware' child node should be added to the QE |
5 | node. This node provides information on the uploaded firmware that | 5 | node. This node provides information on the uploaded firmware that |
6 | device drivers may need. | 6 | device drivers may need. |
diff --git a/Documentation/powerpc/dts-bindings/fsl/dma.txt b/Documentation/powerpc/dts-bindings/fsl/dma.txt index cc453110fc46..0732cdd05ba1 100644 --- a/Documentation/powerpc/dts-bindings/fsl/dma.txt +++ b/Documentation/powerpc/dts-bindings/fsl/dma.txt | |||
@@ -35,30 +35,30 @@ Example: | |||
35 | #address-cells = <1>; | 35 | #address-cells = <1>; |
36 | #size-cells = <1>; | 36 | #size-cells = <1>; |
37 | compatible = "fsl,mpc8349-dma", "fsl,elo-dma"; | 37 | compatible = "fsl,mpc8349-dma", "fsl,elo-dma"; |
38 | reg = <82a8 4>; | 38 | reg = <0x82a8 4>; |
39 | ranges = <0 8100 1a4>; | 39 | ranges = <0 0x8100 0x1a4>; |
40 | interrupt-parent = <&ipic>; | 40 | interrupt-parent = <&ipic>; |
41 | interrupts = <47 8>; | 41 | interrupts = <71 8>; |
42 | cell-index = <0>; | 42 | cell-index = <0>; |
43 | dma-channel@0 { | 43 | dma-channel@0 { |
44 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; | 44 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; |
45 | cell-index = <0>; | 45 | cell-index = <0>; |
46 | reg = <0 80>; | 46 | reg = <0 0x80>; |
47 | }; | 47 | }; |
48 | dma-channel@80 { | 48 | dma-channel@80 { |
49 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; | 49 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; |
50 | cell-index = <1>; | 50 | cell-index = <1>; |
51 | reg = <80 80>; | 51 | reg = <0x80 0x80>; |
52 | }; | 52 | }; |
53 | dma-channel@100 { | 53 | dma-channel@100 { |
54 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; | 54 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; |
55 | cell-index = <2>; | 55 | cell-index = <2>; |
56 | reg = <100 80>; | 56 | reg = <0x100 0x80>; |
57 | }; | 57 | }; |
58 | dma-channel@180 { | 58 | dma-channel@180 { |
59 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; | 59 | compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel"; |
60 | cell-index = <3>; | 60 | cell-index = <3>; |
61 | reg = <180 80>; | 61 | reg = <0x180 0x80>; |
62 | }; | 62 | }; |
63 | }; | 63 | }; |
64 | 64 | ||
@@ -93,36 +93,36 @@ Example: | |||
93 | #address-cells = <1>; | 93 | #address-cells = <1>; |
94 | #size-cells = <1>; | 94 | #size-cells = <1>; |
95 | compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma"; | 95 | compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma"; |
96 | reg = <21300 4>; | 96 | reg = <0x21300 4>; |
97 | ranges = <0 21100 200>; | 97 | ranges = <0 0x21100 0x200>; |
98 | cell-index = <0>; | 98 | cell-index = <0>; |
99 | dma-channel@0 { | 99 | dma-channel@0 { |
100 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; | 100 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; |
101 | reg = <0 80>; | 101 | reg = <0 0x80>; |
102 | cell-index = <0>; | 102 | cell-index = <0>; |
103 | interrupt-parent = <&mpic>; | 103 | interrupt-parent = <&mpic>; |
104 | interrupts = <14 2>; | 104 | interrupts = <20 2>; |
105 | }; | 105 | }; |
106 | dma-channel@80 { | 106 | dma-channel@80 { |
107 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; | 107 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; |
108 | reg = <80 80>; | 108 | reg = <0x80 0x80>; |
109 | cell-index = <1>; | 109 | cell-index = <1>; |
110 | interrupt-parent = <&mpic>; | 110 | interrupt-parent = <&mpic>; |
111 | interrupts = <15 2>; | 111 | interrupts = <21 2>; |
112 | }; | 112 | }; |
113 | dma-channel@100 { | 113 | dma-channel@100 { |
114 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; | 114 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; |
115 | reg = <100 80>; | 115 | reg = <0x100 0x80>; |
116 | cell-index = <2>; | 116 | cell-index = <2>; |
117 | interrupt-parent = <&mpic>; | 117 | interrupt-parent = <&mpic>; |
118 | interrupts = <16 2>; | 118 | interrupts = <22 2>; |
119 | }; | 119 | }; |
120 | dma-channel@180 { | 120 | dma-channel@180 { |
121 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; | 121 | compatible = "fsl,mpc8540-dma-channel", "fsl,eloplus-dma-channel"; |
122 | reg = <180 80>; | 122 | reg = <0x180 0x80>; |
123 | cell-index = <3>; | 123 | cell-index = <3>; |
124 | interrupt-parent = <&mpic>; | 124 | interrupt-parent = <&mpic>; |
125 | interrupts = <17 2>; | 125 | interrupts = <23 2>; |
126 | }; | 126 | }; |
127 | }; | 127 | }; |
128 | 128 | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt new file mode 100644 index 000000000000..600846557763 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt | |||
@@ -0,0 +1,24 @@ | |||
1 | * Freescale Enhanced Secure Digital Host Controller (eSDHC) | ||
2 | |||
3 | The Enhanced Secure Digital Host Controller provides an interface | ||
4 | for MMC, SD, and SDIO types of memory cards. | ||
5 | |||
6 | Required properties: | ||
7 | - compatible : should be | ||
8 | "fsl,<chip>-esdhc", "fsl,mpc8379-esdhc" for MPC83xx processors. | ||
9 | "fsl,<chip>-esdhc", "fsl,mpc8536-esdhc" for MPC85xx processors. | ||
10 | - reg : should contain eSDHC registers location and length. | ||
11 | - interrupts : should contain eSDHC interrupt. | ||
12 | - interrupt-parent : interrupt source phandle. | ||
13 | - clock-frequency : specifies eSDHC base clock frequency. | ||
14 | |||
15 | Example: | ||
16 | |||
17 | sdhci@2e000 { | ||
18 | compatible = "fsl,mpc8378-esdhc", "fsl,mpc8379-esdhc"; | ||
19 | reg = <0x2e000 0x1000>; | ||
20 | interrupts = <42 0x8>; | ||
21 | interrupt-parent = <&ipic>; | ||
22 | /* Filled in by U-Boot */ | ||
23 | clock-frequency = <0>; | ||
24 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt b/Documentation/powerpc/dts-bindings/fsl/ssi.txt index a2d963998a65..5ff76c9c57d2 100644 --- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt +++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt | |||
@@ -4,44 +4,56 @@ The SSI is a serial device that communicates with audio codecs. It can | |||
4 | be programmed in AC97, I2S, left-justified, or right-justified modes. | 4 | be programmed in AC97, I2S, left-justified, or right-justified modes. |
5 | 5 | ||
6 | Required properties: | 6 | Required properties: |
7 | - compatible : compatible list, containing "fsl,ssi" | 7 | - compatible: Compatible list, contains "fsl,ssi". |
8 | - cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on | 8 | - cell-index: The SSI, <0> = SSI1, <1> = SSI2, and so on. |
9 | - reg : offset and length of the register set for the device | 9 | - reg: Offset and length of the register set for the device. |
10 | - interrupts : <a b> where a is the interrupt number and b is a | 10 | - interrupts: <a b> where a is the interrupt number and b is a |
11 | field that represents an encoding of the sense and | 11 | field that represents an encoding of the sense and |
12 | level information for the interrupt. This should be | 12 | level information for the interrupt. This should be |
13 | encoded based on the information in section 2) | 13 | encoded based on the information in section 2) |
14 | depending on the type of interrupt controller you | 14 | depending on the type of interrupt controller you |
15 | have. | 15 | have. |
16 | - interrupt-parent : the phandle for the interrupt controller that | 16 | - interrupt-parent: The phandle for the interrupt controller that |
17 | services interrupts for this device. | 17 | services interrupts for this device. |
18 | - fsl,mode : the operating mode for the SSI interface | 18 | - fsl,mode: The operating mode for the SSI interface. |
19 | "i2s-slave" - I2S mode, SSI is clock slave | 19 | "i2s-slave" - I2S mode, SSI is clock slave |
20 | "i2s-master" - I2S mode, SSI is clock master | 20 | "i2s-master" - I2S mode, SSI is clock master |
21 | "lj-slave" - left-justified mode, SSI is clock slave | 21 | "lj-slave" - left-justified mode, SSI is clock slave |
22 | "lj-master" - l.j. mode, SSI is clock master | 22 | "lj-master" - l.j. mode, SSI is clock master |
23 | "rj-slave" - right-justified mode, SSI is clock slave | 23 | "rj-slave" - right-justified mode, SSI is clock slave |
24 | "rj-master" - r.j., SSI is clock master | 24 | "rj-master" - r.j., SSI is clock master |
25 | "ac97-slave" - AC97 mode, SSI is clock slave | 25 | "ac97-slave" - AC97 mode, SSI is clock slave |
26 | "ac97-master" - AC97 mode, SSI is clock master | 26 | "ac97-master" - AC97 mode, SSI is clock master |
27 | - fsl,playback-dma: phandle to a node for the DMA channel to use for | 27 | - fsl,playback-dma: Phandle to a node for the DMA channel to use for |
28 | playback of audio. This is typically dictated by SOC | 28 | playback of audio. This is typically dictated by SOC |
29 | design. See the notes below. | 29 | design. See the notes below. |
30 | - fsl,capture-dma: phandle to a node for the DMA channel to use for | 30 | - fsl,capture-dma: Phandle to a node for the DMA channel to use for |
31 | capture (recording) of audio. This is typically dictated | 31 | capture (recording) of audio. This is typically dictated |
32 | by SOC design. See the notes below. | 32 | by SOC design. See the notes below. |
33 | - fsl,fifo-depth: The number of elements in the transmit and receive FIFOs. | ||
34 | This number is the maximum allowed value for SFCSR[TFWM0]. | ||
35 | - fsl,ssi-asynchronous: | ||
36 | If specified, the SSI is to be programmed in asynchronous | ||
37 | mode. In this mode, pins SRCK, STCK, SRFS, and STFS must | ||
38 | all be connected to valid signals. In synchronous mode, | ||
39 | SRCK and SRFS are ignored. Asynchronous mode allows | ||
40 | playback and capture to use different sample sizes and | ||
41 | sample rates. Some drivers may require that SRCK and STCK | ||
42 | be connected together, and SRFS and STFS be connected | ||
43 | together. This would still allow different sample sizes, | ||
44 | but not different sample rates. | ||
33 | 45 | ||
34 | Optional properties: | 46 | Optional properties: |
35 | - codec-handle : phandle to a 'codec' node that defines an audio | 47 | - codec-handle: Phandle to a 'codec' node that defines an audio |
36 | codec connected to this SSI. This node is typically | 48 | codec connected to this SSI. This node is typically |
37 | a child of an I2C or other control node. | 49 | a child of an I2C or other control node. |
38 | 50 | ||
39 | Child 'codec' node required properties: | 51 | Child 'codec' node required properties: |
40 | - compatible : compatible list, contains the name of the codec | 52 | - compatible: Compatible list, contains the name of the codec |
41 | 53 | ||
42 | Child 'codec' node optional properties: | 54 | Child 'codec' node optional properties: |
43 | - clock-frequency : The frequency of the input clock, which typically | 55 | - clock-frequency: The frequency of the input clock, which typically comes |
44 | comes from an on-board dedicated oscillator. | 56 | from an on-board dedicated oscillator. |
45 | 57 | ||
46 | Notes on fsl,playback-dma and fsl,capture-dma: | 58 | Notes on fsl,playback-dma and fsl,capture-dma: |
47 | 59 | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/tsec.txt b/Documentation/powerpc/dts-bindings/fsl/tsec.txt index 7fa4b27574b5..edb7ae19e868 100644 --- a/Documentation/powerpc/dts-bindings/fsl/tsec.txt +++ b/Documentation/powerpc/dts-bindings/fsl/tsec.txt | |||
@@ -56,6 +56,12 @@ Properties: | |||
56 | hardware. | 56 | hardware. |
57 | - fsl,magic-packet : If present, indicates that the hardware supports | 57 | - fsl,magic-packet : If present, indicates that the hardware supports |
58 | waking up via magic packet. | 58 | waking up via magic packet. |
59 | - bd-stash : If present, indicates that the hardware supports stashing | ||
60 | buffer descriptors in the L2. | ||
61 | - rx-stash-len : Denotes the number of bytes of a received buffer to stash | ||
62 | in the L2. | ||
63 | - rx-stash-idx : Denotes the index of the first byte from the received | ||
64 | buffer to stash in the L2. | ||
59 | 65 | ||
60 | Example: | 66 | Example: |
61 | ethernet@24000 { | 67 | ethernet@24000 { |
diff --git a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt index 84a04d5eb8e6..a48b2cadc7f0 100644 --- a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt +++ b/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt | |||
@@ -5,9 +5,21 @@ Required properties: | |||
5 | - reg : should specify localbus chip select and size used for the chip. | 5 | - reg : should specify localbus chip select and size used for the chip. |
6 | - fsl,upm-addr-offset : UPM pattern offset for the address latch. | 6 | - fsl,upm-addr-offset : UPM pattern offset for the address latch. |
7 | - fsl,upm-cmd-offset : UPM pattern offset for the command latch. | 7 | - fsl,upm-cmd-offset : UPM pattern offset for the command latch. |
8 | - gpios : may specify optional GPIO connected to the Ready-Not-Busy pin. | ||
9 | 8 | ||
10 | Example: | 9 | Optional properties: |
10 | - fsl,upm-wait-flags : add chip-dependent short delays after running the | ||
11 | UPM pattern (0x1), after writing a data byte (0x2) or after | ||
12 | writing out a buffer (0x4). | ||
13 | - fsl,upm-addr-line-cs-offsets : address offsets for multi-chip support. | ||
14 | The corresponding address lines are used to select the chip. | ||
15 | - gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins | ||
16 | (R/B#). For multi-chip devices, "n" GPIO definitions are required | ||
17 | according to the number of chips. | ||
18 | - chip-delay : chip dependent delay for transfering data from array to | ||
19 | read registers (tR). Required if property "gpios" is not used | ||
20 | (R/B# pins not connected). | ||
21 | |||
22 | Examples: | ||
11 | 23 | ||
12 | upm@1,0 { | 24 | upm@1,0 { |
13 | compatible = "fsl,upm-nand"; | 25 | compatible = "fsl,upm-nand"; |
@@ -26,3 +38,26 @@ upm@1,0 { | |||
26 | }; | 38 | }; |
27 | }; | 39 | }; |
28 | }; | 40 | }; |
41 | |||
42 | upm@3,0 { | ||
43 | #address-cells = <0>; | ||
44 | #size-cells = <0>; | ||
45 | compatible = "tqc,tqm8548-upm-nand", "fsl,upm-nand"; | ||
46 | reg = <3 0x0 0x800>; | ||
47 | fsl,upm-addr-offset = <0x10>; | ||
48 | fsl,upm-cmd-offset = <0x08>; | ||
49 | /* Multi-chip NAND device */ | ||
50 | fsl,upm-addr-line-cs-offsets = <0x0 0x200>; | ||
51 | fsl,upm-wait-flags = <0x5>; | ||
52 | chip-delay = <25>; // in micro-seconds | ||
53 | |||
54 | nand@0 { | ||
55 | #address-cells = <1>; | ||
56 | #size-cells = <1>; | ||
57 | |||
58 | partition@0 { | ||
59 | label = "fs"; | ||
60 | reg = <0x00000000 0x10000000>; | ||
61 | }; | ||
62 | }; | ||
63 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt b/Documentation/powerpc/dts-bindings/gpio/led.txt index ff51f4c0fa9d..4fe14deedc0a 100644 --- a/Documentation/powerpc/dts-bindings/gpio/led.txt +++ b/Documentation/powerpc/dts-bindings/gpio/led.txt | |||
@@ -1,15 +1,43 @@ | |||
1 | LED connected to GPIO | 1 | LEDs connected to GPIO lines |
2 | 2 | ||
3 | Required properties: | 3 | Required properties: |
4 | - compatible : should be "gpio-led". | 4 | - compatible : should be "gpio-leds". |
5 | - label : (optional) the label for this LED. If omitted, the label is | 5 | |
6 | Each LED is represented as a sub-node of the gpio-leds device. Each | ||
7 | node's name represents the name of the corresponding LED. | ||
8 | |||
9 | LED sub-node properties: | ||
10 | - gpios : Should specify the LED's GPIO, see "Specifying GPIO information | ||
11 | for devices" in Documentation/powerpc/booting-without-of.txt. Active | ||
12 | low LEDs should be indicated using flags in the GPIO specifier. | ||
13 | - label : (optional) The label for this LED. If omitted, the label is | ||
6 | taken from the node name (excluding the unit address). | 14 | taken from the node name (excluding the unit address). |
7 | - gpios : should specify LED GPIO. | 15 | - linux,default-trigger : (optional) This parameter, if present, is a |
16 | string defining the trigger assigned to the LED. Current triggers are: | ||
17 | "backlight" - LED will act as a back-light, controlled by the framebuffer | ||
18 | system | ||
19 | "default-on" - LED will turn on | ||
20 | "heartbeat" - LED "double" flashes at a load average based rate | ||
21 | "ide-disk" - LED indicates disk activity | ||
22 | "timer" - LED flashes at a fixed, configurable rate | ||
8 | 23 | ||
9 | Example: | 24 | Examples: |
10 | 25 | ||
11 | led@0 { | 26 | leds { |
12 | compatible = "gpio-led"; | 27 | compatible = "gpio-leds"; |
13 | label = "hdd"; | 28 | hdd { |
14 | gpios = <&mcu_pio 0 1>; | 29 | label = "IDE Activity"; |
30 | gpios = <&mcu_pio 0 1>; /* Active low */ | ||
31 | linux,default-trigger = "ide-disk"; | ||
32 | }; | ||
15 | }; | 33 | }; |
34 | |||
35 | run-control { | ||
36 | compatible = "gpio-leds"; | ||
37 | red { | ||
38 | gpios = <&mpc8572 6 0>; | ||
39 | }; | ||
40 | green { | ||
41 | gpios = <&mpc8572 7 0>; | ||
42 | }; | ||
43 | } | ||
diff --git a/Documentation/powerpc/dts-bindings/mmc-spi-slot.txt b/Documentation/powerpc/dts-bindings/mmc-spi-slot.txt new file mode 100644 index 000000000000..c39ac2891951 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/mmc-spi-slot.txt | |||
@@ -0,0 +1,23 @@ | |||
1 | MMC/SD/SDIO slot directly connected to a SPI bus | ||
2 | |||
3 | Required properties: | ||
4 | - compatible : should be "mmc-spi-slot". | ||
5 | - reg : should specify SPI address (chip-select number). | ||
6 | - spi-max-frequency : maximum frequency for this device (Hz). | ||
7 | - voltage-ranges : two cells are required, first cell specifies minimum | ||
8 | slot voltage (mV), second cell specifies maximum slot voltage (mV). | ||
9 | Several ranges could be specified. | ||
10 | - gpios : (optional) may specify GPIOs in this order: Card-Detect GPIO, | ||
11 | Write-Protect GPIO. | ||
12 | |||
13 | Example: | ||
14 | |||
15 | mmc-slot@0 { | ||
16 | compatible = "fsl,mpc8323rdb-mmc-slot", | ||
17 | "mmc-spi-slot"; | ||
18 | reg = <0>; | ||
19 | gpios = <&qe_pio_d 14 1 | ||
20 | &qe_pio_d 15 0>; | ||
21 | voltage-ranges = <3300 3300>; | ||
22 | spi-max-frequency = <50000000>; | ||
23 | }; | ||
diff --git a/Documentation/scheduler/00-INDEX b/Documentation/scheduler/00-INDEX index aabcc3a089ba..3c00c9c3219e 100644 --- a/Documentation/scheduler/00-INDEX +++ b/Documentation/scheduler/00-INDEX | |||
@@ -2,8 +2,6 @@ | |||
2 | - this file. | 2 | - this file. |
3 | sched-arch.txt | 3 | sched-arch.txt |
4 | - CPU Scheduler implementation hints for architecture specific code. | 4 | - CPU Scheduler implementation hints for architecture specific code. |
5 | sched-coding.txt | ||
6 | - reference for various scheduler-related methods in the O(1) scheduler. | ||
7 | sched-design-CFS.txt | 5 | sched-design-CFS.txt |
8 | - goals, design and implementation of the Complete Fair Scheduler. | 6 | - goals, design and implementation of the Complete Fair Scheduler. |
9 | sched-domains.txt | 7 | sched-domains.txt |
diff --git a/Documentation/scheduler/sched-coding.txt b/Documentation/scheduler/sched-coding.txt deleted file mode 100644 index cbd8db752acf..000000000000 --- a/Documentation/scheduler/sched-coding.txt +++ /dev/null | |||
@@ -1,126 +0,0 @@ | |||
1 | Reference for various scheduler-related methods in the O(1) scheduler | ||
2 | Robert Love <rml@tech9.net>, MontaVista Software | ||
3 | |||
4 | |||
5 | Note most of these methods are local to kernel/sched.c - this is by design. | ||
6 | The scheduler is meant to be self-contained and abstracted away. This document | ||
7 | is primarily for understanding the scheduler, not interfacing to it. Some of | ||
8 | the discussed interfaces, however, are general process/scheduling methods. | ||
9 | They are typically defined in include/linux/sched.h. | ||
10 | |||
11 | |||
12 | Main Scheduling Methods | ||
13 | ----------------------- | ||
14 | |||
15 | void load_balance(runqueue_t *this_rq, int idle) | ||
16 | Attempts to pull tasks from one cpu to another to balance cpu usage, | ||
17 | if needed. This method is called explicitly if the runqueues are | ||
18 | imbalanced or periodically by the timer tick. Prior to calling, | ||
19 | the current runqueue must be locked and interrupts disabled. | ||
20 | |||
21 | void schedule() | ||
22 | The main scheduling function. Upon return, the highest priority | ||
23 | process will be active. | ||
24 | |||
25 | |||
26 | Locking | ||
27 | ------- | ||
28 | |||
29 | Each runqueue has its own lock, rq->lock. When multiple runqueues need | ||
30 | to be locked, lock acquires must be ordered by ascending &runqueue value. | ||
31 | |||
32 | A specific runqueue is locked via | ||
33 | |||
34 | task_rq_lock(task_t pid, unsigned long *flags) | ||
35 | |||
36 | which disables preemption, disables interrupts, and locks the runqueue pid is | ||
37 | running on. Likewise, | ||
38 | |||
39 | task_rq_unlock(task_t pid, unsigned long *flags) | ||
40 | |||
41 | unlocks the runqueue pid is running on, restores interrupts to their previous | ||
42 | state, and reenables preemption. | ||
43 | |||
44 | The routines | ||
45 | |||
46 | double_rq_lock(runqueue_t *rq1, runqueue_t *rq2) | ||
47 | |||
48 | and | ||
49 | |||
50 | double_rq_unlock(runqueue_t *rq1, runqueue_t *rq2) | ||
51 | |||
52 | safely lock and unlock, respectively, the two specified runqueues. They do | ||
53 | not, however, disable and restore interrupts. Users are required to do so | ||
54 | manually before and after calls. | ||
55 | |||
56 | |||
57 | Values | ||
58 | ------ | ||
59 | |||
60 | MAX_PRIO | ||
61 | The maximum priority of the system, stored in the task as task->prio. | ||
62 | Lower priorities are higher. Normal (non-RT) priorities range from | ||
63 | MAX_RT_PRIO to (MAX_PRIO - 1). | ||
64 | MAX_RT_PRIO | ||
65 | The maximum real-time priority of the system. Valid RT priorities | ||
66 | range from 0 to (MAX_RT_PRIO - 1). | ||
67 | MAX_USER_RT_PRIO | ||
68 | The maximum real-time priority that is exported to user-space. Should | ||
69 | always be equal to or less than MAX_RT_PRIO. Setting it less allows | ||
70 | kernel threads to have higher priorities than any user-space task. | ||
71 | MIN_TIMESLICE | ||
72 | MAX_TIMESLICE | ||
73 | Respectively, the minimum and maximum timeslices (quanta) of a process. | ||
74 | |||
75 | Data | ||
76 | ---- | ||
77 | |||
78 | struct runqueue | ||
79 | The main per-CPU runqueue data structure. | ||
80 | struct task_struct | ||
81 | The main per-process data structure. | ||
82 | |||
83 | |||
84 | General Methods | ||
85 | --------------- | ||
86 | |||
87 | cpu_rq(cpu) | ||
88 | Returns the runqueue of the specified cpu. | ||
89 | this_rq() | ||
90 | Returns the runqueue of the current cpu. | ||
91 | task_rq(pid) | ||
92 | Returns the runqueue which holds the specified pid. | ||
93 | cpu_curr(cpu) | ||
94 | Returns the task currently running on the given cpu. | ||
95 | rt_task(pid) | ||
96 | Returns true if pid is real-time, false if not. | ||
97 | |||
98 | |||
99 | Process Control Methods | ||
100 | ----------------------- | ||
101 | |||
102 | void set_user_nice(task_t *p, long nice) | ||
103 | Sets the "nice" value of task p to the given value. | ||
104 | int setscheduler(pid_t pid, int policy, struct sched_param *param) | ||
105 | Sets the scheduling policy and parameters for the given pid. | ||
106 | int set_cpus_allowed(task_t *p, unsigned long new_mask) | ||
107 | Sets a given task's CPU affinity and migrates it to a proper cpu. | ||
108 | Callers must have a valid reference to the task and assure the | ||
109 | task not exit prematurely. No locks can be held during the call. | ||
110 | set_task_state(tsk, state_value) | ||
111 | Sets the given task's state to the given value. | ||
112 | set_current_state(state_value) | ||
113 | Sets the current task's state to the given value. | ||
114 | void set_tsk_need_resched(struct task_struct *tsk) | ||
115 | Sets need_resched in the given task. | ||
116 | void clear_tsk_need_resched(struct task_struct *tsk) | ||
117 | Clears need_resched in the given task. | ||
118 | void set_need_resched() | ||
119 | Sets need_resched in the current task. | ||
120 | void clear_need_resched() | ||
121 | Clears need_resched in the current task. | ||
122 | int need_resched() | ||
123 | Returns true if need_resched is set in the current task, false | ||
124 | otherwise. | ||
125 | yield() | ||
126 | Place the current process at the end of the runqueue and call schedule. | ||
diff --git a/Documentation/scheduler/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt index 3ef339f491e0..5ba4d3fc625a 100644 --- a/Documentation/scheduler/sched-rt-group.txt +++ b/Documentation/scheduler/sched-rt-group.txt | |||
@@ -126,7 +126,7 @@ This uses the /cgroup virtual file system and "/cgroup/<cgroup>/cpu.rt_runtime_u | |||
126 | to control the CPU time reserved for each control group instead. | 126 | to control the CPU time reserved for each control group instead. |
127 | 127 | ||
128 | For more information on working with control groups, you should read | 128 | For more information on working with control groups, you should read |
129 | Documentation/cgroups.txt as well. | 129 | Documentation/cgroups/cgroups.txt as well. |
130 | 130 | ||
131 | Group settings are checked against the following limits in order to keep the configuration | 131 | Group settings are checked against the following limits in order to keep the configuration |
132 | schedulable: | 132 | schedulable: |
diff --git a/Documentation/scsi/aacraid.txt b/Documentation/scsi/aacraid.txt index ddace3afc83b..30f643f611b2 100644 --- a/Documentation/scsi/aacraid.txt +++ b/Documentation/scsi/aacraid.txt | |||
@@ -60,17 +60,9 @@ Supported Cards/Chipsets | |||
60 | 9005:0285:9005:02d5 Adaptec ASR-2405 (Voodoo40 Lite) | 60 | 9005:0285:9005:02d5 Adaptec ASR-2405 (Voodoo40 Lite) |
61 | 9005:0285:9005:02d6 Adaptec ASR-2445 (Voodoo44 Lite) | 61 | 9005:0285:9005:02d6 Adaptec ASR-2445 (Voodoo44 Lite) |
62 | 9005:0285:9005:02d7 Adaptec ASR-2805 (Voodoo80 Lite) | 62 | 9005:0285:9005:02d7 Adaptec ASR-2805 (Voodoo80 Lite) |
63 | 9005:0285:9005:02d8 Adaptec 5405G (Voodoo40 PM) | 63 | 9005:0285:9005:02d8 Adaptec 5405Z (Voodoo40 BLBU) |
64 | 9005:0285:9005:02d9 Adaptec 5445G (Voodoo44 PM) | 64 | 9005:0285:9005:02d9 Adaptec 5445Z (Voodoo44 BLBU) |
65 | 9005:0285:9005:02da Adaptec 5805G (Voodoo80 PM) | 65 | 9005:0285:9005:02da Adaptec 5805Z (Voodoo80 BLBU) |
66 | 9005:0285:9005:02db Adaptec 5085G (Voodoo08 PM) | ||
67 | 9005:0285:9005:02dc Adaptec 51245G (Voodoo124 PM) | ||
68 | 9005:0285:9005:02dd Adaptec 51645G (Voodoo164 PM) | ||
69 | 9005:0285:9005:02de Adaptec 52445G (Voodoo244 PM) | ||
70 | 9005:0285:9005:02df Adaptec ASR-2045G (Voodoo04 Lite PM) | ||
71 | 9005:0285:9005:02e0 Adaptec ASR-2405G (Voodoo40 Lite PM) | ||
72 | 9005:0285:9005:02e1 Adaptec ASR-2445G (Voodoo44 Lite PM) | ||
73 | 9005:0285:9005:02e2 Adaptec ASR-2805G (Voodoo80 Lite PM) | ||
74 | 1011:0046:9005:0364 Adaptec 5400S (Mustang) | 66 | 1011:0046:9005:0364 Adaptec 5400S (Mustang) |
75 | 1011:0046:9005:0365 Adaptec 5400S (Mustang) | 67 | 1011:0046:9005:0365 Adaptec 5400S (Mustang) |
76 | 9005:0287:9005:0800 Adaptec Themisto (Jupiter) | 68 | 9005:0287:9005:0800 Adaptec Themisto (Jupiter) |
@@ -140,6 +132,7 @@ Deanna Bonds (non-DASD support, PAE fibs and 64 bit, | |||
140 | where fibs that go to the hardware are consistently called hw_fibs and | 132 | where fibs that go to the hardware are consistently called hw_fibs and |
141 | not just fibs like the name of the driver tracking structure) | 133 | not just fibs like the name of the driver tracking structure) |
142 | Mark Salyzyn <Mark_Salyzyn@adaptec.com> Fixed panic issues and added some new product ids for upcoming hbas. Performance tuning, card failover and bug mitigations. | 134 | Mark Salyzyn <Mark_Salyzyn@adaptec.com> Fixed panic issues and added some new product ids for upcoming hbas. Performance tuning, card failover and bug mitigations. |
135 | Achim Leubner <Achim_Leubner@adaptec.com> | ||
143 | 136 | ||
144 | Original Driver | 137 | Original Driver |
145 | ------------------------- | 138 | ------------------------- |
diff --git a/Documentation/scsi/cxgb3i.txt b/Documentation/scsi/cxgb3i.txt index 8141fa01978e..7ac8032ee9b2 100644 --- a/Documentation/scsi/cxgb3i.txt +++ b/Documentation/scsi/cxgb3i.txt | |||
@@ -4,7 +4,7 @@ Introduction | |||
4 | ============ | 4 | ============ |
5 | 5 | ||
6 | The Chelsio T3 ASIC based Adapters (S310, S320, S302, S304, Mezz cards, etc. | 6 | The Chelsio T3 ASIC based Adapters (S310, S320, S302, S304, Mezz cards, etc. |
7 | series of products) supports iSCSI acceleration and iSCSI Direct Data Placement | 7 | series of products) support iSCSI acceleration and iSCSI Direct Data Placement |
8 | (DDP) where the hardware handles the expensive byte touching operations, such | 8 | (DDP) where the hardware handles the expensive byte touching operations, such |
9 | as CRC computation and verification, and direct DMA to the final host memory | 9 | as CRC computation and verification, and direct DMA to the final host memory |
10 | destination: | 10 | destination: |
@@ -31,9 +31,9 @@ destination: | |||
31 | the TCP segments onto the wire. It handles TCP retransmission if | 31 | the TCP segments onto the wire. It handles TCP retransmission if |
32 | needed. | 32 | needed. |
33 | 33 | ||
34 | On receving, S3 h/w recovers the iSCSI PDU by reassembling TCP | 34 | On receiving, S3 h/w recovers the iSCSI PDU by reassembling TCP |
35 | segments, separating the header and data, calculating and verifying | 35 | segments, separating the header and data, calculating and verifying |
36 | the digests, then forwards the header to the host. The payload data, | 36 | the digests, then forwarding the header to the host. The payload data, |
37 | if possible, will be directly placed into the pre-posted host DDP | 37 | if possible, will be directly placed into the pre-posted host DDP |
38 | buffer. Otherwise, the payload data will be sent to the host too. | 38 | buffer. Otherwise, the payload data will be sent to the host too. |
39 | 39 | ||
@@ -68,9 +68,8 @@ The following steps need to be taken to accelerates the open-iscsi initiator: | |||
68 | sure the ip address is unique in the network. | 68 | sure the ip address is unique in the network. |
69 | 69 | ||
70 | 3. edit /etc/iscsi/iscsid.conf | 70 | 3. edit /etc/iscsi/iscsid.conf |
71 | The default setting for MaxRecvDataSegmentLength (131072) is too big, | 71 | The default setting for MaxRecvDataSegmentLength (131072) is too big; |
72 | replace "node.conn[0].iscsi.MaxRecvDataSegmentLength" to be a value no | 72 | replace with a value no bigger than 15360 (for example 8192): |
73 | bigger than 15360 (for example 8192): | ||
74 | 73 | ||
75 | node.conn[0].iscsi.MaxRecvDataSegmentLength = 8192 | 74 | node.conn[0].iscsi.MaxRecvDataSegmentLength = 8192 |
76 | 75 | ||
diff --git a/Documentation/scsi/osd.txt b/Documentation/scsi/osd.txt new file mode 100644 index 000000000000..da162f7fd5f5 --- /dev/null +++ b/Documentation/scsi/osd.txt | |||
@@ -0,0 +1,198 @@ | |||
1 | The OSD Standard | ||
2 | ================ | ||
3 | OSD (Object-Based Storage Device) is a T10 SCSI command set that is designed | ||
4 | to provide efficient operation of input/output logical units that manage the | ||
5 | allocation, placement, and accessing of variable-size data-storage containers, | ||
6 | called objects. Objects are intended to contain operating system and application | ||
7 | constructs. Each object has associated attributes attached to it, which are | ||
8 | integral part of the object and provide metadata about the object. The standard | ||
9 | defines some common obligatory attributes, but user attributes can be added as | ||
10 | needed. | ||
11 | |||
12 | See: http://www.t10.org/ftp/t10/drafts/osd2/ for the latest draft for OSD 2 | ||
13 | or search the web for "OSD SCSI" | ||
14 | |||
15 | OSD in the Linux Kernel | ||
16 | ======================= | ||
17 | osd-initiator: | ||
18 | The main component of OSD in Kernel is the osd-initiator library. Its main | ||
19 | user is intended to be the pNFS-over-objects layout driver, which uses objects | ||
20 | as its back-end data storage. Other clients are the other osd parts listed below. | ||
21 | |||
22 | osd-uld: | ||
23 | This is a SCSI ULD that registers for OSD type devices and provides a testing | ||
24 | platform, both for the in-kernel initiator as well as connected targets. It | ||
25 | currently has no useful user-mode API, though it could have if need be. | ||
26 | |||
27 | exofs: | ||
28 | Is an OSD based Linux file system. It uses the osd-initiator and osd-uld, | ||
29 | to export a usable file system for users. | ||
30 | See Documentation/filesystems/exofs.txt for more details | ||
31 | |||
32 | osd target: | ||
33 | There are no current plans for an OSD target implementation in kernel. For all | ||
34 | needs, a user-mode target that is based on the scsi tgt target framework is | ||
35 | available from Ohio Supercomputer Center (OSC) at: | ||
36 | http://www.open-osd.org/bin/view/Main/OscOsdProject | ||
37 | There are several other target implementations. See http://open-osd.org for more | ||
38 | links. | ||
39 | |||
40 | Files and Folders | ||
41 | ================= | ||
42 | This is the complete list of files included in this work: | ||
43 | include/scsi/ | ||
44 | osd_initiator.h Main API for the initiator library | ||
45 | osd_types.h Common OSD types | ||
46 | osd_sec.h Security Manager API | ||
47 | osd_protocol.h Wire definitions of the OSD standard protocol | ||
48 | osd_attributes.h Wire definitions of OSD attributes | ||
49 | |||
50 | drivers/scsi/osd/ | ||
51 | osd_initiator.c OSD-Initiator library implementation | ||
52 | osd_uld.c The OSD scsi ULD | ||
53 | osd_ktest.{h,c} In-kernel test suite (called by osd_uld) | ||
54 | osd_debug.h Some printk macros | ||
55 | Makefile For both in-tree and out-of-tree compilation | ||
56 | Kconfig Enables inclusion of the different pieces | ||
57 | osd_test.c User-mode application to call the kernel tests | ||
58 | |||
59 | The OSD-Initiator Library | ||
60 | ========================= | ||
61 | osd_initiator is a low level implementation of an osd initiator encoder. | ||
62 | But even though, it should be intuitive and easy to use. Perhaps over time an | ||
63 | higher lever will form that automates some of the more common recipes. | ||
64 | |||
65 | init/fini: | ||
66 | - osd_dev_init() associates a scsi_device with an osd_dev structure | ||
67 | and initializes some global pools. This should be done once per scsi_device | ||
68 | (OSD LUN). The osd_dev structure is needed for calling osd_start_request(). | ||
69 | |||
70 | - osd_dev_fini() cleans up before a osd_dev/scsi_device destruction. | ||
71 | |||
72 | OSD commands encoding, execution, and decoding of results: | ||
73 | |||
74 | struct osd_request's is used to iteratively encode an OSD command and carry | ||
75 | its state throughout execution. Each request goes through these stages: | ||
76 | |||
77 | a. osd_start_request() allocates the request. | ||
78 | |||
79 | b. Any of the osd_req_* methods is used to encode a request of the specified | ||
80 | type. | ||
81 | |||
82 | c. osd_req_add_{get,set}_attr_* may be called to add get/set attributes to the | ||
83 | CDB. "List" or "Page" mode can be used exclusively. The attribute-list API | ||
84 | can be called multiple times on the same request. However, only one | ||
85 | attribute-page can be read, as mandated by the OSD standard. | ||
86 | |||
87 | d. osd_finalize_request() computes offsets into the data-in and data-out buffers | ||
88 | and signs the request using the provided capability key and integrity- | ||
89 | check parameters. | ||
90 | |||
91 | e. osd_execute_request() may be called to execute the request via the block | ||
92 | layer and wait for its completion. The request can be executed | ||
93 | asynchronously by calling the block layer API directly. | ||
94 | |||
95 | f. After execution, osd_req_decode_sense() can be called to decode the request's | ||
96 | sense information. | ||
97 | |||
98 | g. osd_req_decode_get_attr() may be called to retrieve osd_add_get_attr_list() | ||
99 | values. | ||
100 | |||
101 | h. osd_end_request() must be called to deallocate the request and any resource | ||
102 | associated with it. Note that osd_end_request cleans up the request at any | ||
103 | stage and it must always be called after a successful osd_start_request(). | ||
104 | |||
105 | osd_request's structure: | ||
106 | |||
107 | The OSD standard defines a complex structure of IO segments pointed to by | ||
108 | members in the CDB. Up to 3 segments can be deployed in the IN-Buffer and up to | ||
109 | 4 in the OUT-Buffer. The ASCII illustration below depicts a secure-read with | ||
110 | associated get+set of attributes-lists. Other combinations very on the same | ||
111 | basic theme. From no-segments-used up to all-segments-used. | ||
112 | |||
113 | |________OSD-CDB__________| | ||
114 | | | | ||
115 | |read_len (offset=0) -|---------\ | ||
116 | | | | | ||
117 | |get_attrs_list_length | | | ||
118 | |get_attrs_list_offset -|----\ | | ||
119 | | | | | | ||
120 | |retrieved_attrs_alloc_len| | | | ||
121 | |retrieved_attrs_offset -|----|----|-\ | ||
122 | | | | | | | ||
123 | |set_attrs_list_length | | | | | ||
124 | |set_attrs_list_offset -|-\ | | | | ||
125 | | | | | | | | ||
126 | |in_data_integ_offset -|-|--|----|-|-\ | ||
127 | |out_data_integ_offset -|-|--|--\ | | | | ||
128 | \_________________________/ | | | | | | | ||
129 | | | | | | | | ||
130 | |_______OUT-BUFFER________| | | | | | | | ||
131 | | Set attr list |</ | | | | | | ||
132 | | | | | | | | | ||
133 | |-------------------------| | | | | | | ||
134 | | Get attr descriptors |<---/ | | | | | ||
135 | | | | | | | | ||
136 | |-------------------------| | | | | | ||
137 | | Out-data integrity |<------/ | | | | ||
138 | | | | | | | ||
139 | \_________________________/ | | | | ||
140 | | | | | ||
141 | |________IN-BUFFER________| | | | | ||
142 | | In-Data read |<--------/ | | | ||
143 | | | | | | ||
144 | |-------------------------| | | | ||
145 | | Get attr list |<----------/ | | ||
146 | | | | | ||
147 | |-------------------------| | | ||
148 | | In-data integrity |<------------/ | ||
149 | | | | ||
150 | \_________________________/ | ||
151 | |||
152 | A block device request can carry bidirectional payload by means of associating | ||
153 | a bidi_read request with a main write-request. Each in/out request is described | ||
154 | by a chain of BIOs associated with each request. | ||
155 | The CDB is of a SCSI VARLEN CDB format, as described by OSD standard. | ||
156 | The OSD standard also mandates alignment restrictions at start of each segment. | ||
157 | |||
158 | In the code, in struct osd_request, there are two _osd_io_info structures to | ||
159 | describe the IN/OUT buffers above, two BIOs for the data payload and up to five | ||
160 | _osd_req_data_segment structures to hold the different segments allocation and | ||
161 | information. | ||
162 | |||
163 | Important: We have chosen to disregard the assumption that a BIO-chain (and | ||
164 | the resulting sg-list) describes a linear memory buffer. Meaning only first and | ||
165 | last scatter chain can be incomplete and all the middle chains are of PAGE_SIZE. | ||
166 | For us, a scatter-gather-list, as its name implies and as used by the Networking | ||
167 | layer, is to describe a vector of buffers that will be transferred to/from the | ||
168 | wire. It works very well with current iSCSI transport. iSCSI is currently the | ||
169 | only deployed OSD transport. In the future we anticipate SAS and FC attached OSD | ||
170 | devices as well. | ||
171 | |||
172 | The OSD Testing ULD | ||
173 | =================== | ||
174 | TODO: More user-mode control on tests. | ||
175 | |||
176 | Authors, Mailing list | ||
177 | ===================== | ||
178 | Please communicate with us on any deployment of osd, whether using this code | ||
179 | or not. | ||
180 | |||
181 | Any problems, questions, bug reports, lonely OSD nights, please email: | ||
182 | OSD Dev List <osd-dev@open-osd.org> | ||
183 | |||
184 | More up-to-date information can be found on: | ||
185 | http://open-osd.org | ||
186 | |||
187 | Boaz Harrosh <bharrosh@panasas.com> | ||
188 | Benny Halevy <bhalevy@panasas.com> | ||
189 | |||
190 | References | ||
191 | ========== | ||
192 | Weber, R., "SCSI Object-Based Storage Device Commands", | ||
193 | T10/1355-D ANSI/INCITS 400-2004, | ||
194 | http://www.t10.org/ftp/t10/drafts/osd/osd-r10.pdf | ||
195 | |||
196 | Weber, R., "SCSI Object-Based Storage Device Commands -2 (OSD-2)" | ||
197 | T10/1729-D, Working Draft, rev. 3 | ||
198 | http://www.t10.org/ftp/t10/drafts/osd2/osd2r03.pdf | ||
diff --git a/Documentation/slow-work.txt b/Documentation/slow-work.txt new file mode 100644 index 000000000000..ebc50f808ea4 --- /dev/null +++ b/Documentation/slow-work.txt | |||
@@ -0,0 +1,174 @@ | |||
1 | ==================================== | ||
2 | SLOW WORK ITEM EXECUTION THREAD POOL | ||
3 | ==================================== | ||
4 | |||
5 | By: David Howells <dhowells@redhat.com> | ||
6 | |||
7 | The slow work item execution thread pool is a pool of threads for performing | ||
8 | things that take a relatively long time, such as making mkdir calls. | ||
9 | Typically, when processing something, these items will spend a lot of time | ||
10 | blocking a thread on I/O, thus making that thread unavailable for doing other | ||
11 | work. | ||
12 | |||
13 | The standard workqueue model is unsuitable for this class of work item as that | ||
14 | limits the owner to a single thread or a single thread per CPU. For some | ||
15 | tasks, however, more threads - or fewer - are required. | ||
16 | |||
17 | There is just one pool per system. It contains no threads unless something | ||
18 | wants to use it - and that something must register its interest first. When | ||
19 | the pool is active, the number of threads it contains is dynamic, varying | ||
20 | between a maximum and minimum setting, depending on the load. | ||
21 | |||
22 | |||
23 | ==================== | ||
24 | CLASSES OF WORK ITEM | ||
25 | ==================== | ||
26 | |||
27 | This pool support two classes of work items: | ||
28 | |||
29 | (*) Slow work items. | ||
30 | |||
31 | (*) Very slow work items. | ||
32 | |||
33 | The former are expected to finish much quicker than the latter. | ||
34 | |||
35 | An operation of the very slow class may do a batch combination of several | ||
36 | lookups, mkdirs, and a create for instance. | ||
37 | |||
38 | An operation of the ordinarily slow class may, for example, write stuff or | ||
39 | expand files, provided the time taken to do so isn't too long. | ||
40 | |||
41 | Operations of both types may sleep during execution, thus tying up the thread | ||
42 | loaned to it. | ||
43 | |||
44 | |||
45 | THREAD-TO-CLASS ALLOCATION | ||
46 | -------------------------- | ||
47 | |||
48 | Not all the threads in the pool are available to work on very slow work items. | ||
49 | The number will be between one and one fewer than the number of active threads. | ||
50 | This is configurable (see the "Pool Configuration" section). | ||
51 | |||
52 | All the threads are available to work on ordinarily slow work items, but a | ||
53 | percentage of the threads will prefer to work on very slow work items. | ||
54 | |||
55 | The configuration ensures that at least one thread will be available to work on | ||
56 | very slow work items, and at least one thread will be available that won't work | ||
57 | on very slow work items at all. | ||
58 | |||
59 | |||
60 | ===================== | ||
61 | USING SLOW WORK ITEMS | ||
62 | ===================== | ||
63 | |||
64 | Firstly, a module or subsystem wanting to make use of slow work items must | ||
65 | register its interest: | ||
66 | |||
67 | int ret = slow_work_register_user(); | ||
68 | |||
69 | This will return 0 if successful, or a -ve error upon failure. | ||
70 | |||
71 | |||
72 | Slow work items may then be set up by: | ||
73 | |||
74 | (1) Declaring a slow_work struct type variable: | ||
75 | |||
76 | #include <linux/slow-work.h> | ||
77 | |||
78 | struct slow_work myitem; | ||
79 | |||
80 | (2) Declaring the operations to be used for this item: | ||
81 | |||
82 | struct slow_work_ops myitem_ops = { | ||
83 | .get_ref = myitem_get_ref, | ||
84 | .put_ref = myitem_put_ref, | ||
85 | .execute = myitem_execute, | ||
86 | }; | ||
87 | |||
88 | [*] For a description of the ops, see section "Item Operations". | ||
89 | |||
90 | (3) Initialising the item: | ||
91 | |||
92 | slow_work_init(&myitem, &myitem_ops); | ||
93 | |||
94 | or: | ||
95 | |||
96 | vslow_work_init(&myitem, &myitem_ops); | ||
97 | |||
98 | depending on its class. | ||
99 | |||
100 | A suitably set up work item can then be enqueued for processing: | ||
101 | |||
102 | int ret = slow_work_enqueue(&myitem); | ||
103 | |||
104 | This will return a -ve error if the thread pool is unable to gain a reference | ||
105 | on the item, 0 otherwise. | ||
106 | |||
107 | |||
108 | The items are reference counted, so there ought to be no need for a flush | ||
109 | operation. When all a module's slow work items have been processed, and the | ||
110 | module has no further interest in the facility, it should unregister its | ||
111 | interest: | ||
112 | |||
113 | slow_work_unregister_user(); | ||
114 | |||
115 | |||
116 | =============== | ||
117 | ITEM OPERATIONS | ||
118 | =============== | ||
119 | |||
120 | Each work item requires a table of operations of type struct slow_work_ops. | ||
121 | All members are required: | ||
122 | |||
123 | (*) Get a reference on an item: | ||
124 | |||
125 | int (*get_ref)(struct slow_work *work); | ||
126 | |||
127 | This allows the thread pool to attempt to pin an item by getting a | ||
128 | reference on it. This function should return 0 if the reference was | ||
129 | granted, or a -ve error otherwise. If an error is returned, | ||
130 | slow_work_enqueue() will fail. | ||
131 | |||
132 | The reference is held whilst the item is queued and whilst it is being | ||
133 | executed. The item may then be requeued with the same reference held, or | ||
134 | the reference will be released. | ||
135 | |||
136 | (*) Release a reference on an item: | ||
137 | |||
138 | void (*put_ref)(struct slow_work *work); | ||
139 | |||
140 | This allows the thread pool to unpin an item by releasing the reference on | ||
141 | it. The thread pool will not touch the item again once this has been | ||
142 | called. | ||
143 | |||
144 | (*) Execute an item: | ||
145 | |||
146 | void (*execute)(struct slow_work *work); | ||
147 | |||
148 | This should perform the work required of the item. It may sleep, it may | ||
149 | perform disk I/O and it may wait for locks. | ||
150 | |||
151 | |||
152 | ================== | ||
153 | POOL CONFIGURATION | ||
154 | ================== | ||
155 | |||
156 | The slow-work thread pool has a number of configurables: | ||
157 | |||
158 | (*) /proc/sys/kernel/slow-work/min-threads | ||
159 | |||
160 | The minimum number of threads that should be in the pool whilst it is in | ||
161 | use. This may be anywhere between 2 and max-threads. | ||
162 | |||
163 | (*) /proc/sys/kernel/slow-work/max-threads | ||
164 | |||
165 | The maximum number of threads that should in the pool. This may be | ||
166 | anywhere between min-threads and 255 or NR_CPUS * 2, whichever is greater. | ||
167 | |||
168 | (*) /proc/sys/kernel/slow-work/vslow-percentage | ||
169 | |||
170 | The percentage of active threads in the pool that may be used to execute | ||
171 | very slow work items. This may be between 1 and 99. The resultant number | ||
172 | is bounded to between 1 and one fewer than the number of active threads. | ||
173 | This ensures there is always at least one thread that can process very | ||
174 | slow work items, and always at least one thread that won't. | ||
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 841a9365d5fd..012858d2b119 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt | |||
@@ -346,6 +346,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
346 | sbirq - IRQ # for CMI8330 chip (SB16) | 346 | sbirq - IRQ # for CMI8330 chip (SB16) |
347 | sbdma8 - 8bit DMA # for CMI8330 chip (SB16) | 347 | sbdma8 - 8bit DMA # for CMI8330 chip (SB16) |
348 | sbdma16 - 16bit DMA # for CMI8330 chip (SB16) | 348 | sbdma16 - 16bit DMA # for CMI8330 chip (SB16) |
349 | fmport - (optional) OPL3 I/O port | ||
350 | mpuport - (optional) MPU401 I/O port | ||
351 | mpuirq - (optional) MPU401 irq # | ||
349 | 352 | ||
350 | This module supports multiple cards and autoprobe. | 353 | This module supports multiple cards and autoprobe. |
351 | 354 | ||
@@ -388,34 +391,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
388 | 391 | ||
389 | The power-management is supported. | 392 | The power-management is supported. |
390 | 393 | ||
391 | Module snd-cs4232 | ||
392 | ----------------- | ||
393 | |||
394 | Module for sound cards based on CS4232/CS4232A ISA chips. | ||
395 | |||
396 | isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) | ||
397 | |||
398 | with isapnp=0, the following options are available: | ||
399 | |||
400 | port - port # for CS4232 chip (PnP setup - 0x534) | ||
401 | cport - control port # for CS4232 chip (PnP setup - 0x120,0x210,0xf00) | ||
402 | mpu_port - port # for MPU-401 UART (PnP setup - 0x300), -1 = disable | ||
403 | fm_port - FM port # for CS4232 chip (PnP setup - 0x388), -1 = disable | ||
404 | irq - IRQ # for CS4232 chip (5,7,9,11,12,15) | ||
405 | mpu_irq - IRQ # for MPU-401 UART (9,11,12,15) | ||
406 | dma1 - first DMA # for CS4232 chip (0,1,3) | ||
407 | dma2 - second DMA # for Yamaha CS4232 chip (0,1,3), -1 = disable | ||
408 | |||
409 | This module supports multiple cards. This module does not support autoprobe | ||
410 | (if ISA PnP is not used) thus main port must be specified!!! Other ports are | ||
411 | optional. | ||
412 | |||
413 | The power-management is supported. | ||
414 | |||
415 | Module snd-cs4236 | 394 | Module snd-cs4236 |
416 | ----------------- | 395 | ----------------- |
417 | 396 | ||
418 | Module for sound cards based on CS4235/CS4236/CS4236B/CS4237B/ | 397 | Module for sound cards based on CS4232/CS4232A, |
398 | CS4235/CS4236/CS4236B/CS4237B/ | ||
419 | CS4238B/CS4239 ISA chips. | 399 | CS4238B/CS4239 ISA chips. |
420 | 400 | ||
421 | isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) | 401 | isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) |
@@ -437,6 +417,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
437 | 417 | ||
438 | The power-management is supported. | 418 | The power-management is supported. |
439 | 419 | ||
420 | This module is aliased as snd-cs4232 since it provides the old | ||
421 | snd-cs4232 functionality, too. | ||
422 | |||
440 | Module snd-cs4281 | 423 | Module snd-cs4281 |
441 | ----------------- | 424 | ----------------- |
442 | 425 | ||
@@ -606,6 +589,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
606 | Module for ESS AudioDrive ES-1688 and ES-688 sound cards. | 589 | Module for ESS AudioDrive ES-1688 and ES-688 sound cards. |
607 | 590 | ||
608 | port - port # for ES-1688 chip (0x220,0x240,0x260) | 591 | port - port # for ES-1688 chip (0x220,0x240,0x260) |
592 | fm_port - port # for OPL3 (option; share the same port as default) | ||
609 | mpu_port - port # for MPU-401 port (0x300,0x310,0x320,0x330), -1 = disable (default) | 593 | mpu_port - port # for MPU-401 port (0x300,0x310,0x320,0x330), -1 = disable (default) |
610 | irq - IRQ # for ES-1688 chip (5,7,9,10) | 594 | irq - IRQ # for ES-1688 chip (5,7,9,10) |
611 | mpu_irq - IRQ # for MPU-401 port (5,7,9,10) | 595 | mpu_irq - IRQ # for MPU-401 port (5,7,9,10) |
@@ -757,6 +741,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
757 | model - force the model name | 741 | model - force the model name |
758 | position_fix - Fix DMA pointer (0 = auto, 1 = use LPIB, 2 = POSBUF) | 742 | position_fix - Fix DMA pointer (0 = auto, 1 = use LPIB, 2 = POSBUF) |
759 | probe_mask - Bitmask to probe codecs (default = -1, meaning all slots) | 743 | probe_mask - Bitmask to probe codecs (default = -1, meaning all slots) |
744 | When the bit 8 (0x100) is set, the lower 8 bits are used | ||
745 | as the "fixed" codec slots; i.e. the driver probes the | ||
746 | slots regardless what hardware reports back | ||
760 | probe_only - Only probing and no codec initialization (default=off); | 747 | probe_only - Only probing and no codec initialization (default=off); |
761 | Useful to check the initial codec status for debugging | 748 | Useful to check the initial codec status for debugging |
762 | bdl_pos_adj - Specifies the DMA IRQ timing delay in samples. | 749 | bdl_pos_adj - Specifies the DMA IRQ timing delay in samples. |
@@ -1185,6 +1172,54 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
1185 | 1172 | ||
1186 | This module supports multiple devices and PnP. | 1173 | This module supports multiple devices and PnP. |
1187 | 1174 | ||
1175 | Module snd-msnd-classic | ||
1176 | ----------------------- | ||
1177 | |||
1178 | Module for Turtle Beach MultiSound Classic, Tahiti or Monterey | ||
1179 | soundcards. | ||
1180 | |||
1181 | io - Port # for msnd-classic card | ||
1182 | irq - IRQ # for msnd-classic card | ||
1183 | mem - Memory address (0xb0000, 0xc8000, 0xd0000, 0xd8000, | ||
1184 | 0xe0000 or 0xe8000) | ||
1185 | write_ndelay - enable write ndelay (default = 1) | ||
1186 | calibrate_signal - calibrate signal (default = 0) | ||
1187 | isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) | ||
1188 | digital - Digital daughterboard present (default = 0) | ||
1189 | cfg - Config port (0x250, 0x260 or 0x270) default = PnP | ||
1190 | reset - Reset all devices | ||
1191 | mpu_io - MPU401 I/O port | ||
1192 | mpu_irq - MPU401 irq# | ||
1193 | ide_io0 - IDE port #0 | ||
1194 | ide_io1 - IDE port #1 | ||
1195 | ide_irq - IDE irq# | ||
1196 | joystick_io - Joystick I/O port | ||
1197 | |||
1198 | The driver requires firmware files "turtlebeach/msndinit.bin" and | ||
1199 | "turtlebeach/msndperm.bin" in the proper firmware directory. | ||
1200 | |||
1201 | See Documentation/sound/oss/MultiSound for important information | ||
1202 | about this driver. Note that it has been discontinued, but the | ||
1203 | Voyetra Turtle Beach knowledge base entry for it is still available | ||
1204 | at | ||
1205 | http://www.turtlebeach.com/site/kb_ftp/790.asp | ||
1206 | |||
1207 | Module snd-msnd-pinnacle | ||
1208 | ------------------------ | ||
1209 | |||
1210 | Module for Turtle Beach MultiSound Pinnacle/Fiji soundcards. | ||
1211 | |||
1212 | io - Port # for pinnacle/fiji card | ||
1213 | irq - IRQ # for pinnalce/fiji card | ||
1214 | mem - Memory address (0xb0000, 0xc8000, 0xd0000, 0xd8000, | ||
1215 | 0xe0000 or 0xe8000) | ||
1216 | write_ndelay - enable write ndelay (default = 1) | ||
1217 | calibrate_signal - calibrate signal (default = 0) | ||
1218 | isapnp - ISA PnP detection - 0 = disable, 1 = enable (default) | ||
1219 | |||
1220 | The driver requires firmware files "turtlebeach/pndspini.bin" and | ||
1221 | "turtlebeach/pndsperm.bin" in the proper firmware directory. | ||
1222 | |||
1188 | Module snd-mtpav | 1223 | Module snd-mtpav |
1189 | ---------------- | 1224 | ---------------- |
1190 | 1225 | ||
@@ -1824,7 +1859,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
1824 | ------------------- | 1859 | ------------------- |
1825 | 1860 | ||
1826 | Module for sound cards based on the Asus AV100/AV200 chips, | 1861 | Module for sound cards based on the Asus AV100/AV200 chips, |
1827 | i.e., Xonar D1, DX, D2, D2X and HDAV1.3 (Deluxe). | 1862 | i.e., Xonar D1, DX, D2, D2X, HDAV1.3 (Deluxe), and Essence STX. |
1828 | 1863 | ||
1829 | This module supports autoprobe and multiple cards. | 1864 | This module supports autoprobe and multiple cards. |
1830 | 1865 | ||
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 0f5d26bea80f..8eec05bc079e 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt | |||
@@ -56,6 +56,7 @@ ALC262 | |||
56 | sony-assamd Sony ASSAMD | 56 | sony-assamd Sony ASSAMD |
57 | toshiba-s06 Toshiba S06 | 57 | toshiba-s06 Toshiba S06 |
58 | toshiba-rx1 Toshiba RX1 | 58 | toshiba-rx1 Toshiba RX1 |
59 | tyan Tyan Thunder n6650W (S2915-E) | ||
59 | ultra Samsung Q1 Ultra Vista model | 60 | ultra Samsung Q1 Ultra Vista model |
60 | lenovo-3000 Lenovo 3000 y410 | 61 | lenovo-3000 Lenovo 3000 y410 |
61 | nec NEC Versa S9100 | 62 | nec NEC Versa S9100 |
@@ -261,6 +262,8 @@ Conexant 5051 | |||
261 | ============= | 262 | ============= |
262 | laptop Basic Laptop config (default) | 263 | laptop Basic Laptop config (default) |
263 | hp HP Spartan laptop | 264 | hp HP Spartan laptop |
265 | hp-dv6736 HP dv6736 | ||
266 | lenovo-x200 Lenovo X200 laptop | ||
264 | 267 | ||
265 | STAC9200 | 268 | STAC9200 |
266 | ======== | 269 | ======== |
@@ -278,6 +281,7 @@ STAC9200 | |||
278 | gateway-m4 Gateway laptops with EAPD control | 281 | gateway-m4 Gateway laptops with EAPD control |
279 | gateway-m4-2 Gateway laptops with EAPD control | 282 | gateway-m4-2 Gateway laptops with EAPD control |
280 | panasonic Panasonic CF-74 | 283 | panasonic Panasonic CF-74 |
284 | auto BIOS setup (default) | ||
281 | 285 | ||
282 | STAC9205/9254 | 286 | STAC9205/9254 |
283 | ============= | 287 | ============= |
@@ -285,6 +289,8 @@ STAC9205/9254 | |||
285 | dell-m42 Dell (unknown) | 289 | dell-m42 Dell (unknown) |
286 | dell-m43 Dell Precision | 290 | dell-m43 Dell Precision |
287 | dell-m44 Dell Inspiron | 291 | dell-m44 Dell Inspiron |
292 | eapd Keep EAPD on (e.g. Gateway T1616) | ||
293 | auto BIOS setup (default) | ||
288 | 294 | ||
289 | STAC9220/9221 | 295 | STAC9220/9221 |
290 | ============= | 296 | ============= |
@@ -308,6 +314,7 @@ STAC9220/9221 | |||
308 | dell-d82 Dell (unknown) | 314 | dell-d82 Dell (unknown) |
309 | dell-m81 Dell (unknown) | 315 | dell-m81 Dell (unknown) |
310 | dell-m82 Dell XPS M1210 | 316 | dell-m82 Dell XPS M1210 |
317 | auto BIOS setup (default) | ||
311 | 318 | ||
312 | STAC9202/9250/9251 | 319 | STAC9202/9250/9251 |
313 | ================== | 320 | ================== |
@@ -319,6 +326,7 @@ STAC9202/9250/9251 | |||
319 | m3 Some Gateway MX series laptops | 326 | m3 Some Gateway MX series laptops |
320 | m5 Some Gateway MX series laptops (MP6954) | 327 | m5 Some Gateway MX series laptops (MP6954) |
321 | m6 Some Gateway NX series laptops | 328 | m6 Some Gateway NX series laptops |
329 | auto BIOS setup (default) | ||
322 | 330 | ||
323 | STAC9227/9228/9229/927x | 331 | STAC9227/9228/9229/927x |
324 | ======================= | 332 | ======================= |
@@ -328,6 +336,7 @@ STAC9227/9228/9229/927x | |||
328 | 5stack D965 5stack + SPDIF | 336 | 5stack D965 5stack + SPDIF |
329 | dell-3stack Dell Dimension E520 | 337 | dell-3stack Dell Dimension E520 |
330 | dell-bios Fixes with Dell BIOS setup | 338 | dell-bios Fixes with Dell BIOS setup |
339 | auto BIOS setup (default) | ||
331 | 340 | ||
332 | STAC92HD71B* | 341 | STAC92HD71B* |
333 | ============ | 342 | ============ |
@@ -335,7 +344,10 @@ STAC92HD71B* | |||
335 | dell-m4-1 Dell desktops | 344 | dell-m4-1 Dell desktops |
336 | dell-m4-2 Dell desktops | 345 | dell-m4-2 Dell desktops |
337 | dell-m4-3 Dell desktops | 346 | dell-m4-3 Dell desktops |
338 | hp-m4 HP dv laptops | 347 | hp-m4 HP mini 1000 |
348 | hp-dv5 HP dv series | ||
349 | hp-hdx HP HDX series | ||
350 | auto BIOS setup (default) | ||
339 | 351 | ||
340 | STAC92HD73* | 352 | STAC92HD73* |
341 | =========== | 353 | =========== |
@@ -345,13 +357,16 @@ STAC92HD73* | |||
345 | dell-m6-dmic Dell desktops/laptops with digital mics | 357 | dell-m6-dmic Dell desktops/laptops with digital mics |
346 | dell-m6 Dell desktops/laptops with both type of mics | 358 | dell-m6 Dell desktops/laptops with both type of mics |
347 | dell-eq Dell desktops/laptops | 359 | dell-eq Dell desktops/laptops |
360 | auto BIOS setup (default) | ||
348 | 361 | ||
349 | STAC92HD83* | 362 | STAC92HD83* |
350 | =========== | 363 | =========== |
351 | ref Reference board | 364 | ref Reference board |
352 | mic-ref Reference board with power managment for ports | 365 | mic-ref Reference board with power managment for ports |
366 | dell-s14 Dell laptop | ||
367 | auto BIOS setup (default) | ||
353 | 368 | ||
354 | STAC9872 | 369 | STAC9872 |
355 | ======== | 370 | ======== |
356 | vaio Setup for VAIO FE550G/SZ110 | 371 | vaio VAIO laptop without SPDIF |
357 | vaio-ar Setup for VAIO AR | 372 | auto BIOS setup (default) |
diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt index 8d68fff71839..c5948f2f9a25 100644 --- a/Documentation/sound/alsa/HD-Audio.txt +++ b/Documentation/sound/alsa/HD-Audio.txt | |||
@@ -109,6 +109,13 @@ slot, pass `probe_mask=1`. For the first and the third slots, pass | |||
109 | Since 2.6.29 kernel, the driver has a more robust probing method, so | 109 | Since 2.6.29 kernel, the driver has a more robust probing method, so |
110 | this error might happen rarely, though. | 110 | this error might happen rarely, though. |
111 | 111 | ||
112 | On a machine with a broken BIOS, sometimes you need to force the | ||
113 | driver to probe the codec slots the hardware doesn't report for use. | ||
114 | In such a case, turn the bit 8 (0x100) of `probe_mask` option on. | ||
115 | Then the rest 8 bits are passed as the codec slots to probe | ||
116 | unconditionally. For example, `probe_mask=0x103` will force to probe | ||
117 | the codec slots 0 and 1 no matter what the hardware reports. | ||
118 | |||
112 | 119 | ||
113 | Interrupt Handling | 120 | Interrupt Handling |
114 | ~~~~~~~~~~~~~~~~~~ | 121 | ~~~~~~~~~~~~~~~~~~ |
@@ -358,10 +365,26 @@ modelname:: | |||
358 | to this file. | 365 | to this file. |
359 | init_verbs:: | 366 | init_verbs:: |
360 | The extra verbs to execute at initialization. You can add a verb by | 367 | The extra verbs to execute at initialization. You can add a verb by |
361 | writing to this file. Pass tree numbers, nid, verb and parameter. | 368 | writing to this file. Pass three numbers: nid, verb and parameter |
369 | (separated with a space). | ||
362 | hints:: | 370 | hints:: |
363 | Shows hint strings for codec parsers for any use. Right now it's | 371 | Shows / stores hint strings for codec parsers for any use. |
364 | not used. | 372 | Its format is `key = value`. For example, passing `hp_detect = yes` |
373 | to IDT/STAC codec parser will result in the disablement of the | ||
374 | headphone detection. | ||
375 | init_pin_configs:: | ||
376 | Shows the initial pin default config values set by BIOS. | ||
377 | driver_pin_configs:: | ||
378 | Shows the pin default values set by the codec parser explicitly. | ||
379 | This doesn't show all pin values but only the changed values by | ||
380 | the parser. That is, if the parser doesn't change the pin default | ||
381 | config values by itself, this will contain nothing. | ||
382 | user_pin_configs:: | ||
383 | Shows the pin default config values to override the BIOS setup. | ||
384 | Writing this (with two numbers, NID and value) appends the new | ||
385 | value. The given will be used instead of the initial BIOS value at | ||
386 | the next reconfiguration time. Note that this config will override | ||
387 | even the driver pin configs, too. | ||
365 | reconfig:: | 388 | reconfig:: |
366 | Triggers the codec re-configuration. When any value is written to | 389 | Triggers the codec re-configuration. When any value is written to |
367 | this file, the driver re-initialize and parses the codec tree | 390 | this file, the driver re-initialize and parses the codec tree |
@@ -371,6 +394,14 @@ clear:: | |||
371 | Resets the codec, removes the mixer elements and PCM stuff of the | 394 | Resets the codec, removes the mixer elements and PCM stuff of the |
372 | specified codec, and clear all init verbs and hints. | 395 | specified codec, and clear all init verbs and hints. |
373 | 396 | ||
397 | For example, when you want to change the pin default configuration | ||
398 | value of the pin widget 0x14 to 0x9993013f, and let the driver | ||
399 | re-configure based on that state, run like below: | ||
400 | ------------------------------------------------------------------------ | ||
401 | # echo 0x14 0x9993013f > /sys/class/sound/hwC0D0/user_pin_configs | ||
402 | # echo 1 > /sys/class/sound/hwC0D0/reconfig | ||
403 | ------------------------------------------------------------------------ | ||
404 | |||
374 | 405 | ||
375 | Power-Saving | 406 | Power-Saving |
376 | ~~~~~~~~~~~~ | 407 | ~~~~~~~~~~~~ |
@@ -461,6 +492,16 @@ run with `--no-upload` option, and attach the generated file. | |||
461 | There are some other useful options. See `--help` option output for | 492 | There are some other useful options. See `--help` option output for |
462 | details. | 493 | details. |
463 | 494 | ||
495 | When a probe error occurs or when the driver obviously assigns a | ||
496 | mismatched model, it'd be helpful to load the driver with | ||
497 | `probe_only=1` option (at best after the cold reboot) and run | ||
498 | alsa-info at this state. With this option, the driver won't configure | ||
499 | the mixer and PCM but just tries to probe the codec slot. After | ||
500 | probing, the proc file is available, so you can get the raw codec | ||
501 | information before modified by the driver. Of course, the driver | ||
502 | isn't usable with `probe_only=1`. But you can continue the | ||
503 | configuration via hwdep sysfs file if hda-reconfig option is enabled. | ||
504 | |||
464 | 505 | ||
465 | hda-verb | 506 | hda-verb |
466 | ~~~~~~~~ | 507 | ~~~~~~~~ |
diff --git a/Documentation/sound/alsa/soc/dapm.txt b/Documentation/sound/alsa/soc/dapm.txt index 46f9684d0b29..9e6763264a2e 100644 --- a/Documentation/sound/alsa/soc/dapm.txt +++ b/Documentation/sound/alsa/soc/dapm.txt | |||
@@ -116,6 +116,9 @@ SOC_DAPM_SINGLE("HiFi Playback Switch", WM8731_APANA, 4, 1, 0), | |||
116 | SND_SOC_DAPM_MIXER("Output Mixer", WM8731_PWR, 4, 1, wm8731_output_mixer_controls, | 116 | SND_SOC_DAPM_MIXER("Output Mixer", WM8731_PWR, 4, 1, wm8731_output_mixer_controls, |
117 | ARRAY_SIZE(wm8731_output_mixer_controls)), | 117 | ARRAY_SIZE(wm8731_output_mixer_controls)), |
118 | 118 | ||
119 | If you dont want the mixer elements prefixed with the name of the mixer widget, | ||
120 | you can use SND_SOC_DAPM_MIXER_NAMED_CTL instead. the parameters are the same | ||
121 | as for SND_SOC_DAPM_MIXER. | ||
119 | 122 | ||
120 | 2.3 Platform/Machine domain Widgets | 123 | 2.3 Platform/Machine domain Widgets |
121 | ----------------------------------- | 124 | ----------------------------------- |
diff --git a/Documentation/sound/alsa/soc/jack.txt b/Documentation/sound/alsa/soc/jack.txt new file mode 100644 index 000000000000..fcf82a417293 --- /dev/null +++ b/Documentation/sound/alsa/soc/jack.txt | |||
@@ -0,0 +1,71 @@ | |||
1 | ASoC jack detection | ||
2 | =================== | ||
3 | |||
4 | ALSA has a standard API for representing physical jacks to user space, | ||
5 | the kernel side of which can be seen in include/sound/jack.h. ASoC | ||
6 | provides a version of this API adding two additional features: | ||
7 | |||
8 | - It allows more than one jack detection method to work together on one | ||
9 | user visible jack. In embedded systems it is common for multiple | ||
10 | to be present on a single jack but handled by separate bits of | ||
11 | hardware. | ||
12 | |||
13 | - Integration with DAPM, allowing DAPM endpoints to be updated | ||
14 | automatically based on the detected jack status (eg, turning off the | ||
15 | headphone outputs if no headphones are present). | ||
16 | |||
17 | This is done by splitting the jacks up into three things working | ||
18 | together: the jack itself represented by a struct snd_soc_jack, sets of | ||
19 | snd_soc_jack_pins representing DAPM endpoints to update and blocks of | ||
20 | code providing jack reporting mechanisms. | ||
21 | |||
22 | For example, a system may have a stereo headset jack with two reporting | ||
23 | mechanisms, one for the headphone and one for the microphone. Some | ||
24 | systems won't be able to use their speaker output while a headphone is | ||
25 | connected and so will want to make sure to update both speaker and | ||
26 | headphone when the headphone jack status changes. | ||
27 | |||
28 | The jack - struct snd_soc_jack | ||
29 | ============================== | ||
30 | |||
31 | This represents a physical jack on the system and is what is visible to | ||
32 | user space. The jack itself is completely passive, it is set up by the | ||
33 | machine driver and updated by jack detection methods. | ||
34 | |||
35 | Jacks are created by the machine driver calling snd_soc_jack_new(). | ||
36 | |||
37 | snd_soc_jack_pin | ||
38 | ================ | ||
39 | |||
40 | These represent a DAPM pin to update depending on some of the status | ||
41 | bits supported by the jack. Each snd_soc_jack has zero or more of these | ||
42 | which are updated automatically. They are created by the machine driver | ||
43 | and associated with the jack using snd_soc_jack_add_pins(). The status | ||
44 | of the endpoint may configured to be the opposite of the jack status if | ||
45 | required (eg, enabling a built in microphone if a microphone is not | ||
46 | connected via a jack). | ||
47 | |||
48 | Jack detection methods | ||
49 | ====================== | ||
50 | |||
51 | Actual jack detection is done by code which is able to monitor some | ||
52 | input to the system and update a jack by calling snd_soc_jack_report(), | ||
53 | specifying a subset of bits to update. The jack detection code should | ||
54 | be set up by the machine driver, taking configuration for the jack to | ||
55 | update and the set of things to report when the jack is connected. | ||
56 | |||
57 | Often this is done based on the status of a GPIO - a handler for this is | ||
58 | provided by the snd_soc_jack_add_gpio() function. Other methods are | ||
59 | also available, for example integrated into CODECs. One example of | ||
60 | CODEC integrated jack detection can be see in the WM8350 driver. | ||
61 | |||
62 | Each jack may have multiple reporting mechanisms, though it will need at | ||
63 | least one to be useful. | ||
64 | |||
65 | Machine drivers | ||
66 | =============== | ||
67 | |||
68 | These are all hooked together by the machine driver depending on the | ||
69 | system hardware. The machine driver will set up the snd_soc_jack and | ||
70 | the list of pins to update then set up one or more jack detection | ||
71 | mechanisms to update that jack based on their current status. | ||
diff --git a/Documentation/sound/oss/CS4232 b/Documentation/sound/oss/CS4232 deleted file mode 100644 index 7d6af7a5c1c2..000000000000 --- a/Documentation/sound/oss/CS4232 +++ /dev/null | |||
@@ -1,23 +0,0 @@ | |||
1 | To configure the Crystal CS423x sound chip and activate its DSP functions, | ||
2 | modules may be loaded in this order: | ||
3 | |||
4 | modprobe sound | ||
5 | insmod ad1848 | ||
6 | insmod uart401 | ||
7 | insmod cs4232 io=* irq=* dma=* dma2=* | ||
8 | |||
9 | This is the meaning of the parameters: | ||
10 | |||
11 | io--I/O address of the Windows Sound System (normally 0x534) | ||
12 | irq--IRQ of this device | ||
13 | dma and dma2--DMA channels (DMA2 may be 0) | ||
14 | |||
15 | On some cards, the board attempts to do non-PnP setup, and fails. If you | ||
16 | have problems, use Linux' PnP facilities. | ||
17 | |||
18 | To get MIDI facilities add | ||
19 | |||
20 | insmod opl3 io=* | ||
21 | |||
22 | where "io" is the I/O address of the OPL3 synthesizer. This will be shown | ||
23 | in /proc/sys/pnp and is normally 0x388. | ||
diff --git a/Documentation/sound/oss/Introduction b/Documentation/sound/oss/Introduction index f04ba6bb7395..75d967ff9266 100644 --- a/Documentation/sound/oss/Introduction +++ b/Documentation/sound/oss/Introduction | |||
@@ -80,7 +80,7 @@ Notes: | |||
80 | additional features. | 80 | additional features. |
81 | 81 | ||
82 | 2. The commercial OSS driver may be obtained from the site: | 82 | 2. The commercial OSS driver may be obtained from the site: |
83 | http://www/opensound.com. This may be used for cards that | 83 | http://www.opensound.com. This may be used for cards that |
84 | are unsupported by the kernel driver, or may be used | 84 | are unsupported by the kernel driver, or may be used |
85 | by other operating systems. | 85 | by other operating systems. |
86 | 86 | ||
diff --git a/Documentation/sysctl/00-INDEX b/Documentation/sysctl/00-INDEX index a20a9066dc4c..1286f455992f 100644 --- a/Documentation/sysctl/00-INDEX +++ b/Documentation/sysctl/00-INDEX | |||
@@ -10,6 +10,8 @@ fs.txt | |||
10 | - documentation for /proc/sys/fs/*. | 10 | - documentation for /proc/sys/fs/*. |
11 | kernel.txt | 11 | kernel.txt |
12 | - documentation for /proc/sys/kernel/*. | 12 | - documentation for /proc/sys/kernel/*. |
13 | net.txt | ||
14 | - documentation for /proc/sys/net/*. | ||
13 | sunrpc.txt | 15 | sunrpc.txt |
14 | - documentation for /proc/sys/sunrpc/*. | 16 | - documentation for /proc/sys/sunrpc/*. |
15 | vm.txt | 17 | vm.txt |
diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt index f99254327ae5..1458448436cc 100644 --- a/Documentation/sysctl/fs.txt +++ b/Documentation/sysctl/fs.txt | |||
@@ -1,5 +1,6 @@ | |||
1 | Documentation for /proc/sys/fs/* kernel version 2.2.10 | 1 | Documentation for /proc/sys/fs/* kernel version 2.2.10 |
2 | (c) 1998, 1999, Rik van Riel <riel@nl.linux.org> | 2 | (c) 1998, 1999, Rik van Riel <riel@nl.linux.org> |
3 | (c) 2009, Shen Feng<shen@cn.fujitsu.com> | ||
3 | 4 | ||
4 | For general info and legal blurb, please look in README. | 5 | For general info and legal blurb, please look in README. |
5 | 6 | ||
@@ -14,7 +15,12 @@ kernel. Since some of the files _can_ be used to screw up your | |||
14 | system, it is advisable to read both documentation and source | 15 | system, it is advisable to read both documentation and source |
15 | before actually making adjustments. | 16 | before actually making adjustments. |
16 | 17 | ||
18 | 1. /proc/sys/fs | ||
19 | ---------------------------------------------------------- | ||
20 | |||
17 | Currently, these files are in /proc/sys/fs: | 21 | Currently, these files are in /proc/sys/fs: |
22 | - aio-max-nr | ||
23 | - aio-nr | ||
18 | - dentry-state | 24 | - dentry-state |
19 | - dquot-max | 25 | - dquot-max |
20 | - dquot-nr | 26 | - dquot-nr |
@@ -30,8 +36,15 @@ Currently, these files are in /proc/sys/fs: | |||
30 | - super-max | 36 | - super-max |
31 | - super-nr | 37 | - super-nr |
32 | 38 | ||
33 | Documentation for the files in /proc/sys/fs/binfmt_misc is | 39 | ============================================================== |
34 | in Documentation/binfmt_misc.txt. | 40 | |
41 | aio-nr & aio-max-nr: | ||
42 | |||
43 | aio-nr is the running total of the number of events specified on the | ||
44 | io_setup system call for all currently active aio contexts. If aio-nr | ||
45 | reaches aio-max-nr then io_setup will fail with EAGAIN. Note that | ||
46 | raising aio-max-nr does not result in the pre-allocation or re-sizing | ||
47 | of any kernel data structures. | ||
35 | 48 | ||
36 | ============================================================== | 49 | ============================================================== |
37 | 50 | ||
@@ -178,3 +191,60 @@ requests. aio-max-nr allows you to change the maximum value | |||
178 | aio-nr can grow to. | 191 | aio-nr can grow to. |
179 | 192 | ||
180 | ============================================================== | 193 | ============================================================== |
194 | |||
195 | |||
196 | 2. /proc/sys/fs/binfmt_misc | ||
197 | ---------------------------------------------------------- | ||
198 | |||
199 | Documentation for the files in /proc/sys/fs/binfmt_misc is | ||
200 | in Documentation/binfmt_misc.txt. | ||
201 | |||
202 | |||
203 | 3. /proc/sys/fs/mqueue - POSIX message queues filesystem | ||
204 | ---------------------------------------------------------- | ||
205 | |||
206 | The "mqueue" filesystem provides the necessary kernel features to enable the | ||
207 | creation of a user space library that implements the POSIX message queues | ||
208 | API (as noted by the MSG tag in the POSIX 1003.1-2001 version of the System | ||
209 | Interfaces specification.) | ||
210 | |||
211 | The "mqueue" filesystem contains values for determining/setting the amount of | ||
212 | resources used by the file system. | ||
213 | |||
214 | /proc/sys/fs/mqueue/queues_max is a read/write file for setting/getting the | ||
215 | maximum number of message queues allowed on the system. | ||
216 | |||
217 | /proc/sys/fs/mqueue/msg_max is a read/write file for setting/getting the | ||
218 | maximum number of messages in a queue value. In fact it is the limiting value | ||
219 | for another (user) limit which is set in mq_open invocation. This attribute of | ||
220 | a queue must be less or equal then msg_max. | ||
221 | |||
222 | /proc/sys/fs/mqueue/msgsize_max is a read/write file for setting/getting the | ||
223 | maximum message size value (it is every message queue's attribute set during | ||
224 | its creation). | ||
225 | |||
226 | |||
227 | 4. /proc/sys/fs/epoll - Configuration options for the epoll interface | ||
228 | -------------------------------------------------------- | ||
229 | |||
230 | This directory contains configuration options for the epoll(7) interface. | ||
231 | |||
232 | max_user_instances | ||
233 | ------------------ | ||
234 | |||
235 | This is the maximum number of epoll file descriptors that a single user can | ||
236 | have open at a given time. The default value is 128, and should be enough | ||
237 | for normal users. | ||
238 | |||
239 | max_user_watches | ||
240 | ---------------- | ||
241 | |||
242 | Every epoll file descriptor can store a number of files to be monitored | ||
243 | for event readiness. Each one of these monitored files constitutes a "watch". | ||
244 | This configuration option sets the maximum number of "watches" that are | ||
245 | allowed for each user. | ||
246 | Each "watch" costs roughly 90 bytes on a 32bit kernel, and roughly 160 bytes | ||
247 | on a 64bit one. | ||
248 | The current default value for max_user_watches is the 1/32 of the available | ||
249 | low memory, divided for the "watch" cost in bytes. | ||
250 | |||
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index a4ccdd1981cf..f11ca7979fa6 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt | |||
@@ -1,5 +1,6 @@ | |||
1 | Documentation for /proc/sys/kernel/* kernel version 2.2.10 | 1 | Documentation for /proc/sys/kernel/* kernel version 2.2.10 |
2 | (c) 1998, 1999, Rik van Riel <riel@nl.linux.org> | 2 | (c) 1998, 1999, Rik van Riel <riel@nl.linux.org> |
3 | (c) 2009, Shen Feng<shen@cn.fujitsu.com> | ||
3 | 4 | ||
4 | For general info and legal blurb, please look in README. | 5 | For general info and legal blurb, please look in README. |
5 | 6 | ||
@@ -18,6 +19,7 @@ Currently, these files might (depending on your configuration) | |||
18 | show up in /proc/sys/kernel: | 19 | show up in /proc/sys/kernel: |
19 | - acpi_video_flags | 20 | - acpi_video_flags |
20 | - acct | 21 | - acct |
22 | - auto_msgmni | ||
21 | - core_pattern | 23 | - core_pattern |
22 | - core_uses_pid | 24 | - core_uses_pid |
23 | - ctrl-alt-del | 25 | - ctrl-alt-del |
@@ -33,6 +35,7 @@ show up in /proc/sys/kernel: | |||
33 | - msgmax | 35 | - msgmax |
34 | - msgmnb | 36 | - msgmnb |
35 | - msgmni | 37 | - msgmni |
38 | - nmi_watchdog | ||
36 | - osrelease | 39 | - osrelease |
37 | - ostype | 40 | - ostype |
38 | - overflowgid | 41 | - overflowgid |
@@ -40,6 +43,7 @@ show up in /proc/sys/kernel: | |||
40 | - panic | 43 | - panic |
41 | - pid_max | 44 | - pid_max |
42 | - powersave-nap [ PPC only ] | 45 | - powersave-nap [ PPC only ] |
46 | - panic_on_unrecovered_nmi | ||
43 | - printk | 47 | - printk |
44 | - randomize_va_space | 48 | - randomize_va_space |
45 | - real-root-dev ==> Documentation/initrd.txt | 49 | - real-root-dev ==> Documentation/initrd.txt |
@@ -55,6 +59,7 @@ show up in /proc/sys/kernel: | |||
55 | - sysrq ==> Documentation/sysrq.txt | 59 | - sysrq ==> Documentation/sysrq.txt |
56 | - tainted | 60 | - tainted |
57 | - threads-max | 61 | - threads-max |
62 | - unknown_nmi_panic | ||
58 | - version | 63 | - version |
59 | 64 | ||
60 | ============================================================== | 65 | ============================================================== |
@@ -381,3 +386,51 @@ can be ORed together: | |||
381 | 512 - A kernel warning has occurred. | 386 | 512 - A kernel warning has occurred. |
382 | 1024 - A module from drivers/staging was loaded. | 387 | 1024 - A module from drivers/staging was loaded. |
383 | 388 | ||
389 | ============================================================== | ||
390 | |||
391 | auto_msgmni: | ||
392 | |||
393 | Enables/Disables automatic recomputing of msgmni upon memory add/remove or | ||
394 | upon ipc namespace creation/removal (see the msgmni description above). | ||
395 | Echoing "1" into this file enables msgmni automatic recomputing. | ||
396 | Echoing "0" turns it off. | ||
397 | auto_msgmni default value is 1. | ||
398 | |||
399 | ============================================================== | ||
400 | |||
401 | nmi_watchdog: | ||
402 | |||
403 | Enables/Disables the NMI watchdog on x86 systems. When the value is non-zero | ||
404 | the NMI watchdog is enabled and will continuously test all online cpus to | ||
405 | determine whether or not they are still functioning properly. Currently, | ||
406 | passing "nmi_watchdog=" parameter at boot time is required for this function | ||
407 | to work. | ||
408 | |||
409 | If LAPIC NMI watchdog method is in use (nmi_watchdog=2 kernel parameter), the | ||
410 | NMI watchdog shares registers with oprofile. By disabling the NMI watchdog, | ||
411 | oprofile may have more registers to utilize. | ||
412 | |||
413 | ============================================================== | ||
414 | |||
415 | unknown_nmi_panic: | ||
416 | |||
417 | The value in this file affects behavior of handling NMI. When the value is | ||
418 | non-zero, unknown NMI is trapped and then panic occurs. At that time, kernel | ||
419 | debugging information is displayed on console. | ||
420 | |||
421 | NMI switch that most IA32 servers have fires unknown NMI up, for example. | ||
422 | If a system hangs up, try pressing the NMI switch. | ||
423 | |||
424 | ============================================================== | ||
425 | |||
426 | panic_on_unrecovered_nmi: | ||
427 | |||
428 | The default Linux behaviour on an NMI of either memory or unknown is to continue | ||
429 | operation. For many environments such as scientific computing it is preferable | ||
430 | that the box is taken out and the error dealt with than an uncorrected | ||
431 | parity/ECC error get propogated. | ||
432 | |||
433 | A small number of systems do generate NMI's for bizarre random reasons such as | ||
434 | power management so the default is off. That sysctl works like the existing | ||
435 | panic controls already in that directory. | ||
436 | |||
diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt new file mode 100644 index 000000000000..a34d55b65441 --- /dev/null +++ b/Documentation/sysctl/net.txt | |||
@@ -0,0 +1,175 @@ | |||
1 | Documentation for /proc/sys/net/* kernel version 2.4.0-test11-pre4 | ||
2 | (c) 1999 Terrehon Bowden <terrehon@pacbell.net> | ||
3 | Bodo Bauer <bb@ricochet.net> | ||
4 | (c) 2000 Jorge Nerin <comandante@zaralinux.com> | ||
5 | (c) 2009 Shen Feng <shen@cn.fujitsu.com> | ||
6 | |||
7 | For general info and legal blurb, please look in README. | ||
8 | |||
9 | ============================================================== | ||
10 | |||
11 | This file contains the documentation for the sysctl files in | ||
12 | /proc/sys/net and is valid for Linux kernel version 2.4.0-test11-pre4. | ||
13 | |||
14 | The interface to the networking parts of the kernel is located in | ||
15 | /proc/sys/net. The following table shows all possible subdirectories.You may | ||
16 | see only some of them, depending on your kernel's configuration. | ||
17 | |||
18 | |||
19 | Table : Subdirectories in /proc/sys/net | ||
20 | .............................................................................. | ||
21 | Directory Content Directory Content | ||
22 | core General parameter appletalk Appletalk protocol | ||
23 | unix Unix domain sockets netrom NET/ROM | ||
24 | 802 E802 protocol ax25 AX25 | ||
25 | ethernet Ethernet protocol rose X.25 PLP layer | ||
26 | ipv4 IP version 4 x25 X.25 protocol | ||
27 | ipx IPX token-ring IBM token ring | ||
28 | bridge Bridging decnet DEC net | ||
29 | ipv6 IP version 6 | ||
30 | .............................................................................. | ||
31 | |||
32 | 1. /proc/sys/net/core - Network core options | ||
33 | ------------------------------------------------------- | ||
34 | |||
35 | rmem_default | ||
36 | ------------ | ||
37 | |||
38 | The default setting of the socket receive buffer in bytes. | ||
39 | |||
40 | rmem_max | ||
41 | -------- | ||
42 | |||
43 | The maximum receive socket buffer size in bytes. | ||
44 | |||
45 | wmem_default | ||
46 | ------------ | ||
47 | |||
48 | The default setting (in bytes) of the socket send buffer. | ||
49 | |||
50 | wmem_max | ||
51 | -------- | ||
52 | |||
53 | The maximum send socket buffer size in bytes. | ||
54 | |||
55 | message_burst and message_cost | ||
56 | ------------------------------ | ||
57 | |||
58 | These parameters are used to limit the warning messages written to the kernel | ||
59 | log from the networking code. They enforce a rate limit to make a | ||
60 | denial-of-service attack impossible. A higher message_cost factor, results in | ||
61 | fewer messages that will be written. Message_burst controls when messages will | ||
62 | be dropped. The default settings limit warning messages to one every five | ||
63 | seconds. | ||
64 | |||
65 | warnings | ||
66 | -------- | ||
67 | |||
68 | This controls console messages from the networking stack that can occur because | ||
69 | of problems on the network like duplicate address or bad checksums. Normally, | ||
70 | this should be enabled, but if the problem persists the messages can be | ||
71 | disabled. | ||
72 | |||
73 | netdev_budget | ||
74 | ------------- | ||
75 | |||
76 | Maximum number of packets taken from all interfaces in one polling cycle (NAPI | ||
77 | poll). In one polling cycle interfaces which are registered to polling are | ||
78 | probed in a round-robin manner. The limit of packets in one such probe can be | ||
79 | set per-device via sysfs class/net/<device>/weight . | ||
80 | |||
81 | netdev_max_backlog | ||
82 | ------------------ | ||
83 | |||
84 | Maximum number of packets, queued on the INPUT side, when the interface | ||
85 | receives packets faster than kernel can process them. | ||
86 | |||
87 | optmem_max | ||
88 | ---------- | ||
89 | |||
90 | Maximum ancillary buffer size allowed per socket. Ancillary data is a sequence | ||
91 | of struct cmsghdr structures with appended data. | ||
92 | |||
93 | 2. /proc/sys/net/unix - Parameters for Unix domain sockets | ||
94 | ------------------------------------------------------- | ||
95 | |||
96 | There is only one file in this directory. | ||
97 | unix_dgram_qlen limits the max number of datagrams queued in Unix domain | ||
98 | socket's buffer. It will not take effect unless PF_UNIX flag is spicified. | ||
99 | |||
100 | |||
101 | 3. /proc/sys/net/ipv4 - IPV4 settings | ||
102 | ------------------------------------------------------- | ||
103 | Please see: Documentation/networking/ip-sysctl.txt and ipvs-sysctl.txt for | ||
104 | descriptions of these entries. | ||
105 | |||
106 | |||
107 | 4. Appletalk | ||
108 | ------------------------------------------------------- | ||
109 | |||
110 | The /proc/sys/net/appletalk directory holds the Appletalk configuration data | ||
111 | when Appletalk is loaded. The configurable parameters are: | ||
112 | |||
113 | aarp-expiry-time | ||
114 | ---------------- | ||
115 | |||
116 | The amount of time we keep an ARP entry before expiring it. Used to age out | ||
117 | old hosts. | ||
118 | |||
119 | aarp-resolve-time | ||
120 | ----------------- | ||
121 | |||
122 | The amount of time we will spend trying to resolve an Appletalk address. | ||
123 | |||
124 | aarp-retransmit-limit | ||
125 | --------------------- | ||
126 | |||
127 | The number of times we will retransmit a query before giving up. | ||
128 | |||
129 | aarp-tick-time | ||
130 | -------------- | ||
131 | |||
132 | Controls the rate at which expires are checked. | ||
133 | |||
134 | The directory /proc/net/appletalk holds the list of active Appletalk sockets | ||
135 | on a machine. | ||
136 | |||
137 | The fields indicate the DDP type, the local address (in network:node format) | ||
138 | the remote address, the size of the transmit pending queue, the size of the | ||
139 | received queue (bytes waiting for applications to read) the state and the uid | ||
140 | owning the socket. | ||
141 | |||
142 | /proc/net/atalk_iface lists all the interfaces configured for appletalk.It | ||
143 | shows the name of the interface, its Appletalk address, the network range on | ||
144 | that address (or network number for phase 1 networks), and the status of the | ||
145 | interface. | ||
146 | |||
147 | /proc/net/atalk_route lists each known network route. It lists the target | ||
148 | (network) that the route leads to, the router (may be directly connected), the | ||
149 | route flags, and the device the route is using. | ||
150 | |||
151 | |||
152 | 5. IPX | ||
153 | ------------------------------------------------------- | ||
154 | |||
155 | The IPX protocol has no tunable values in proc/sys/net. | ||
156 | |||
157 | The IPX protocol does, however, provide proc/net/ipx. This lists each IPX | ||
158 | socket giving the local and remote addresses in Novell format (that is | ||
159 | network:node:port). In accordance with the strange Novell tradition, | ||
160 | everything but the port is in hex. Not_Connected is displayed for sockets that | ||
161 | are not tied to a specific remote address. The Tx and Rx queue sizes indicate | ||
162 | the number of bytes pending for transmission and reception. The state | ||
163 | indicates the state the socket is in and the uid is the owning uid of the | ||
164 | socket. | ||
165 | |||
166 | The /proc/net/ipx_interface file lists all IPX interfaces. For each interface | ||
167 | it gives the network number, the node number, and indicates if the network is | ||
168 | the primary network. It also indicates which device it is bound to (or | ||
169 | Internal for internal networks) and the Frame Type if appropriate. Linux | ||
170 | supports 802.3, 802.2, 802.2 SNAP and DIX (Blue Book) ethernet framing for | ||
171 | IPX. | ||
172 | |||
173 | The /proc/net/ipx_route table holds a list of IPX routes. For each route it | ||
174 | gives the destination network, the router node (or Directly) and the network | ||
175 | address of the router (or Connected) for internal networks. | ||
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 3197fc83bc51..97c4b3284329 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt | |||
@@ -39,6 +39,8 @@ Currently, these files are in /proc/sys/vm: | |||
39 | - nr_hugepages | 39 | - nr_hugepages |
40 | - nr_overcommit_hugepages | 40 | - nr_overcommit_hugepages |
41 | - nr_pdflush_threads | 41 | - nr_pdflush_threads |
42 | - nr_pdflush_threads_min | ||
43 | - nr_pdflush_threads_max | ||
42 | - nr_trim_pages (only if CONFIG_MMU=n) | 44 | - nr_trim_pages (only if CONFIG_MMU=n) |
43 | - numa_zonelist_order | 45 | - numa_zonelist_order |
44 | - oom_dump_tasks | 46 | - oom_dump_tasks |
@@ -463,6 +465,32 @@ The default value is 0. | |||
463 | 465 | ||
464 | ============================================================== | 466 | ============================================================== |
465 | 467 | ||
468 | nr_pdflush_threads_min | ||
469 | |||
470 | This value controls the minimum number of pdflush threads. | ||
471 | |||
472 | At boot time, the kernel will create and maintain 'nr_pdflush_threads_min' | ||
473 | threads for the kernel's lifetime. | ||
474 | |||
475 | The default value is 2. The minimum value you can specify is 1, and | ||
476 | the maximum value is the current setting of 'nr_pdflush_threads_max'. | ||
477 | |||
478 | See 'nr_pdflush_threads_max' below for more information. | ||
479 | |||
480 | ============================================================== | ||
481 | |||
482 | nr_pdflush_threads_max | ||
483 | |||
484 | This value controls the maximum number of pdflush threads that can be | ||
485 | created. The pdflush algorithm will create a new pdflush thread (up to | ||
486 | this maximum) if no pdflush threads have been available for >= 1 second. | ||
487 | |||
488 | The default value is 8. The minimum value you can specify is the | ||
489 | current value of 'nr_pdflush_threads_min' and the | ||
490 | maximum is 1000. | ||
491 | |||
492 | ============================================================== | ||
493 | |||
466 | overcommit_memory: | 494 | overcommit_memory: |
467 | 495 | ||
468 | This value contains a flag that enables memory overcommitment. | 496 | This value contains a flag that enables memory overcommitment. |
diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index 9e592c718afb..cf42b820ff9d 100644 --- a/Documentation/sysrq.txt +++ b/Documentation/sysrq.txt | |||
@@ -81,6 +81,8 @@ On all - write a character to /proc/sysrq-trigger. e.g.: | |||
81 | 81 | ||
82 | 'i' - Send a SIGKILL to all processes, except for init. | 82 | 'i' - Send a SIGKILL to all processes, except for init. |
83 | 83 | ||
84 | 'j' - Forcibly "Just thaw it" - filesystems frozen by the FIFREEZE ioctl. | ||
85 | |||
84 | 'k' - Secure Access Key (SAK) Kills all programs on the current virtual | 86 | 'k' - Secure Access Key (SAK) Kills all programs on the current virtual |
85 | console. NOTE: See important comments below in SAK section. | 87 | console. NOTE: See important comments below in SAK section. |
86 | 88 | ||
@@ -113,6 +115,8 @@ On all - write a character to /proc/sysrq-trigger. e.g.: | |||
113 | 115 | ||
114 | 'x' - Used by xmon interface on ppc/powerpc platforms. | 116 | 'x' - Used by xmon interface on ppc/powerpc platforms. |
115 | 117 | ||
118 | 'z' - Dump the ftrace buffer | ||
119 | |||
116 | '0'-'9' - Sets the console log level, controlling which kernel messages | 120 | '0'-'9' - Sets the console log level, controlling which kernel messages |
117 | will be printed to your console. ('0', for example would make | 121 | will be printed to your console. ('0', for example would make |
118 | it so that only emergency messages like PANICs or OOPSes would | 122 | it so that only emergency messages like PANICs or OOPSes would |
@@ -160,6 +164,9 @@ t'E'rm and k'I'll are useful if you have some sort of runaway process you | |||
160 | are unable to kill any other way, especially if it's spawning other | 164 | are unable to kill any other way, especially if it's spawning other |
161 | processes. | 165 | processes. |
162 | 166 | ||
167 | "'J'ust thaw it" is useful if your system becomes unresponsive due to a frozen | ||
168 | (probably root) filesystem via the FIFREEZE ioctl. | ||
169 | |||
163 | * Sometimes SysRq seems to get 'stuck' after using it, what can I do? | 170 | * Sometimes SysRq seems to get 'stuck' after using it, what can I do? |
164 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 171 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
165 | That happens to me, also. I've found that tapping shift, alt, and control | 172 | That happens to me, also. I've found that tapping shift, alt, and control |
diff --git a/Documentation/tracepoints.txt b/Documentation/tracepoints.txt index 6f0a044f5b5e..c0e1ceed75a4 100644 --- a/Documentation/tracepoints.txt +++ b/Documentation/tracepoints.txt | |||
@@ -45,8 +45,8 @@ In include/trace/subsys.h : | |||
45 | #include <linux/tracepoint.h> | 45 | #include <linux/tracepoint.h> |
46 | 46 | ||
47 | DECLARE_TRACE(subsys_eventname, | 47 | DECLARE_TRACE(subsys_eventname, |
48 | TPPROTO(int firstarg, struct task_struct *p), | 48 | TP_PROTO(int firstarg, struct task_struct *p), |
49 | TPARGS(firstarg, p)); | 49 | TP_ARGS(firstarg, p)); |
50 | 50 | ||
51 | In subsys/file.c (where the tracing statement must be added) : | 51 | In subsys/file.c (where the tracing statement must be added) : |
52 | 52 | ||
@@ -66,10 +66,10 @@ Where : | |||
66 | - subsys is the name of your subsystem. | 66 | - subsys is the name of your subsystem. |
67 | - eventname is the name of the event to trace. | 67 | - eventname is the name of the event to trace. |
68 | 68 | ||
69 | - TPPROTO(int firstarg, struct task_struct *p) is the prototype of the | 69 | - TP_PROTO(int firstarg, struct task_struct *p) is the prototype of the |
70 | function called by this tracepoint. | 70 | function called by this tracepoint. |
71 | 71 | ||
72 | - TPARGS(firstarg, p) are the parameters names, same as found in the | 72 | - TP_ARGS(firstarg, p) are the parameters names, same as found in the |
73 | prototype. | 73 | prototype. |
74 | 74 | ||
75 | Connecting a function (probe) to a tracepoint is done by providing a | 75 | Connecting a function (probe) to a tracepoint is done by providing a |
@@ -103,13 +103,14 @@ used to export the defined tracepoints. | |||
103 | 103 | ||
104 | * Probe / tracepoint example | 104 | * Probe / tracepoint example |
105 | 105 | ||
106 | See the example provided in samples/tracepoints/src | 106 | See the example provided in samples/tracepoints |
107 | 107 | ||
108 | Compile them with your kernel. | 108 | Compile them with your kernel. They are built during 'make' (not |
109 | 'make modules') when CONFIG_SAMPLE_TRACEPOINTS=m. | ||
109 | 110 | ||
110 | Run, as root : | 111 | Run, as root : |
111 | modprobe tracepoint-example (insmod order is not important) | 112 | modprobe tracepoint-sample (insmod order is not important) |
112 | modprobe tracepoint-probe-example | 113 | modprobe tracepoint-probe-sample |
113 | cat /proc/tracepoint-example (returns an expected error) | 114 | cat /proc/tracepoint-sample (returns an expected error) |
114 | rmmod tracepoint-example tracepoint-probe-example | 115 | rmmod tracepoint-sample tracepoint-probe-sample |
115 | dmesg | 116 | dmesg |
diff --git a/Documentation/tracers/mmiotrace.txt b/Documentation/tracers/mmiotrace.txt index cde23b4a12a1..5731c67abc55 100644 --- a/Documentation/tracers/mmiotrace.txt +++ b/Documentation/tracers/mmiotrace.txt | |||
@@ -78,12 +78,10 @@ to view your kernel log and look for "mmiotrace has lost events" warning. If | |||
78 | events were lost, the trace is incomplete. You should enlarge the buffers and | 78 | events were lost, the trace is incomplete. You should enlarge the buffers and |
79 | try again. Buffers are enlarged by first seeing how large the current buffers | 79 | try again. Buffers are enlarged by first seeing how large the current buffers |
80 | are: | 80 | are: |
81 | $ cat /debug/tracing/trace_entries | 81 | $ cat /debug/tracing/buffer_size_kb |
82 | gives you a number. Approximately double this number and write it back, for | 82 | gives you a number. Approximately double this number and write it back, for |
83 | instance: | 83 | instance: |
84 | $ echo 0 > /debug/tracing/tracing_enabled | 84 | $ echo 128000 > /debug/tracing/buffer_size_kb |
85 | $ echo 128000 > /debug/tracing/trace_entries | ||
86 | $ echo 1 > /debug/tracing/tracing_enabled | ||
87 | Then start again from the top. | 85 | Then start again from the top. |
88 | 86 | ||
89 | If you are doing a trace for a driver project, e.g. Nouveau, you should also | 87 | If you are doing a trace for a driver project, e.g. Nouveau, you should also |
diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt index 270481906dc8..6c3c625b7f30 100644 --- a/Documentation/usb/usbmon.txt +++ b/Documentation/usb/usbmon.txt | |||
@@ -229,16 +229,26 @@ struct usbmon_packet { | |||
229 | int status; /* 28: */ | 229 | int status; /* 28: */ |
230 | unsigned int length; /* 32: Length of data (submitted or actual) */ | 230 | unsigned int length; /* 32: Length of data (submitted or actual) */ |
231 | unsigned int len_cap; /* 36: Delivered length */ | 231 | unsigned int len_cap; /* 36: Delivered length */ |
232 | unsigned char setup[8]; /* 40: Only for Control 'S' */ | 232 | union { /* 40: */ |
233 | }; /* 48 bytes total */ | 233 | unsigned char setup[SETUP_LEN]; /* Only for Control S-type */ |
234 | struct iso_rec { /* Only for ISO */ | ||
235 | int error_count; | ||
236 | int numdesc; | ||
237 | } iso; | ||
238 | } s; | ||
239 | int interval; /* 48: Only for Interrupt and ISO */ | ||
240 | int start_frame; /* 52: For ISO */ | ||
241 | unsigned int xfer_flags; /* 56: copy of URB's transfer_flags */ | ||
242 | unsigned int ndesc; /* 60: Actual number of ISO descriptors */ | ||
243 | }; /* 64 total length */ | ||
234 | 244 | ||
235 | These events can be received from a character device by reading with read(2), | 245 | These events can be received from a character device by reading with read(2), |
236 | with an ioctl(2), or by accessing the buffer with mmap. | 246 | with an ioctl(2), or by accessing the buffer with mmap. However, read(2) |
247 | only returns first 48 bytes for compatibility reasons. | ||
237 | 248 | ||
238 | The character device is usually called /dev/usbmonN, where N is the USB bus | 249 | The character device is usually called /dev/usbmonN, where N is the USB bus |
239 | number. Number zero (/dev/usbmon0) is special and means "all buses". | 250 | number. Number zero (/dev/usbmon0) is special and means "all buses". |
240 | However, this feature is not implemented yet. Note that specific naming | 251 | Note that specific naming policy is set by your Linux distribution. |
241 | policy is set by your Linux distribution. | ||
242 | 252 | ||
243 | If you create /dev/usbmon0 by hand, make sure that it is owned by root | 253 | If you create /dev/usbmon0 by hand, make sure that it is owned by root |
244 | and has mode 0600. Otherwise, unpriviledged users will be able to snoop | 254 | and has mode 0600. Otherwise, unpriviledged users will be able to snoop |
@@ -279,9 +289,10 @@ size is out of [unspecified] bounds for this kernel, the call fails with | |||
279 | This call returns the current size of the buffer in bytes. | 289 | This call returns the current size of the buffer in bytes. |
280 | 290 | ||
281 | MON_IOCX_GET, defined as _IOW(MON_IOC_MAGIC, 6, struct mon_get_arg) | 291 | MON_IOCX_GET, defined as _IOW(MON_IOC_MAGIC, 6, struct mon_get_arg) |
292 | MON_IOCX_GETX, defined as _IOW(MON_IOC_MAGIC, 10, struct mon_get_arg) | ||
282 | 293 | ||
283 | This call waits for events to arrive if none were in the kernel buffer, | 294 | These calls wait for events to arrive if none were in the kernel buffer, |
284 | then returns the first event. Its argument is a pointer to the following | 295 | then return the first event. The argument is a pointer to the following |
285 | structure: | 296 | structure: |
286 | 297 | ||
287 | struct mon_get_arg { | 298 | struct mon_get_arg { |
@@ -294,6 +305,8 @@ Before the call, hdr, data, and alloc should be filled. Upon return, the area | |||
294 | pointed by hdr contains the next event structure, and the data buffer contains | 305 | pointed by hdr contains the next event structure, and the data buffer contains |
295 | the data, if any. The event is removed from the kernel buffer. | 306 | the data, if any. The event is removed from the kernel buffer. |
296 | 307 | ||
308 | The MON_IOCX_GET copies 48 bytes, MON_IOCX_GETX copies 64 bytes. | ||
309 | |||
297 | MON_IOCX_MFETCH, defined as _IOWR(MON_IOC_MAGIC, 7, struct mon_mfetch_arg) | 310 | MON_IOCX_MFETCH, defined as _IOWR(MON_IOC_MAGIC, 7, struct mon_mfetch_arg) |
298 | 311 | ||
299 | This ioctl is primarily used when the application accesses the buffer | 312 | This ioctl is primarily used when the application accesses the buffer |
diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv index 0d93fa1ac25e..f11c583295e9 100644 --- a/Documentation/video4linux/CARDLIST.bttv +++ b/Documentation/video4linux/CARDLIST.bttv | |||
@@ -135,7 +135,7 @@ | |||
135 | 134 -> Adlink RTV24 | 135 | 134 -> Adlink RTV24 |
136 | 135 -> DViCO FusionHDTV 5 Lite [18ac:d500] | 136 | 135 -> DViCO FusionHDTV 5 Lite [18ac:d500] |
137 | 136 -> Acorp Y878F [9511:1540] | 137 | 136 -> Acorp Y878F [9511:1540] |
138 | 137 -> Conceptronic CTVFMi v2 | 138 | 137 -> Conceptronic CTVFMi v2 [036e:109e] |
139 | 138 -> Prolink Pixelview PV-BT878P+ (Rev.2E) | 139 | 138 -> Prolink Pixelview PV-BT878P+ (Rev.2E) |
140 | 139 -> Prolink PixelView PlayTV MPEG2 PV-M4900 | 140 | 139 -> Prolink PixelView PlayTV MPEG2 PV-M4900 |
141 | 140 -> Osprey 440 [0070:ff07] | 141 | 140 -> Osprey 440 [0070:ff07] |
@@ -154,3 +154,7 @@ | |||
154 | 153 -> PHYTEC VD-012 (bt878) | 154 | 153 -> PHYTEC VD-012 (bt878) |
155 | 154 -> PHYTEC VD-012-X1 (bt878) | 155 | 154 -> PHYTEC VD-012-X1 (bt878) |
156 | 155 -> PHYTEC VD-012-X2 (bt878) | 156 | 155 -> PHYTEC VD-012-X2 (bt878) |
157 | 156 -> IVCE-8784 [0000:f050,0001:f050,0002:f050,0003:f050] | ||
158 | 157 -> Geovision GV-800(S) (master) [800a:763d] | ||
159 | 158 -> Geovision GV-800(S) (slave) [800b:763d,800c:763d,800d:763d] | ||
160 | 159 -> ProVideo PV183 [1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540] | ||
diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 35ea130e9898..91aa3c0f0dd2 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 | |||
@@ -12,3 +12,7 @@ | |||
12 | 11 -> DViCO FusionHDTV DVB-T Dual Express [18ac:db78] | 12 | 11 -> DViCO FusionHDTV DVB-T Dual Express [18ac:db78] |
13 | 12 -> Leadtek Winfast PxDVR3200 H [107d:6681] | 13 | 12 -> Leadtek Winfast PxDVR3200 H [107d:6681] |
14 | 13 -> Compro VideoMate E650F [185b:e800] | 14 | 13 -> Compro VideoMate E650F [185b:e800] |
15 | 14 -> TurboSight TBS 6920 [6920:8888] | ||
16 | 15 -> TeVii S470 [d470:9022] | ||
17 | 16 -> DVBWorld DVB-S2 2005 [0001:2005] | ||
18 | 17 -> NetUP Dual DVB-S2 CI [1b55:2a2c] | ||
diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 index 0d08f1edcf6d..71e9db0b26f7 100644 --- a/Documentation/video4linux/CARDLIST.cx88 +++ b/Documentation/video4linux/CARDLIST.cx88 | |||
@@ -77,3 +77,4 @@ | |||
77 | 76 -> SATTRADE ST4200 DVB-S/S2 [b200:4200] | 77 | 76 -> SATTRADE ST4200 DVB-S/S2 [b200:4200] |
78 | 77 -> TBS 8910 DVB-S [8910:8888] | 78 | 77 -> TBS 8910 DVB-S [8910:8888] |
79 | 78 -> Prof 6200 DVB-S [b022:3022] | 79 | 78 -> Prof 6200 DVB-S [b022:3022] |
80 | 79 -> Terratec Cinergy HT PCI MKII [153b:1177] | ||
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index 75bded8a4aa2..78d0a6eed571 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx | |||
@@ -7,12 +7,12 @@ | |||
7 | 6 -> Terratec Cinergy 200 USB (em2800) | 7 | 6 -> Terratec Cinergy 200 USB (em2800) |
8 | 7 -> Leadtek Winfast USB II (em2800) [0413:6023] | 8 | 7 -> Leadtek Winfast USB II (em2800) [0413:6023] |
9 | 8 -> Kworld USB2800 (em2800) | 9 | 8 -> Kworld USB2800 (em2800) |
10 | 9 -> Pinnacle Dazzle DVC 90/DVC 100 (em2820/em2840) [2304:0207,2304:021a] | 10 | 9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker (em2820/em2840) [1b80:e302,2304:0207,2304:021a] |
11 | 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500] | 11 | 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500] |
12 | 11 -> Terratec Hybrid XS (em2880) [0ccd:0042] | 12 | 11 -> Terratec Hybrid XS (em2880) [0ccd:0042] |
13 | 12 -> Kworld PVR TV 2800 RF (em2820/em2840) | 13 | 12 -> Kworld PVR TV 2800 RF (em2820/em2840) |
14 | 13 -> Terratec Prodigy XS (em2880) [0ccd:0047] | 14 | 13 -> Terratec Prodigy XS (em2880) [0ccd:0047] |
15 | 14 -> Pixelview Prolink PlayTV USB 2.0 (em2820/em2840) | 15 | 14 -> SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 (em2820/em2840) |
16 | 15 -> V-Gear PocketTV (em2800) | 16 | 15 -> V-Gear PocketTV (em2800) |
17 | 16 -> Hauppauge WinTV HVR 950 (em2883) [2040:6513,2040:6517,2040:651b] | 17 | 16 -> Hauppauge WinTV HVR 950 (em2883) [2040:6513,2040:6517,2040:651b] |
18 | 17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227] | 18 | 17 -> Pinnacle PCTV HD Pro Stick (em2880) [2304:0227] |
@@ -30,7 +30,6 @@ | |||
30 | 30 -> Videology 20K14XUSB USB2.0 (em2820/em2840) | 30 | 30 -> Videology 20K14XUSB USB2.0 (em2820/em2840) |
31 | 31 -> Usbgear VD204v9 (em2821) | 31 | 31 -> Usbgear VD204v9 (em2821) |
32 | 32 -> Supercomp USB 2.0 TV (em2821) | 32 | 32 -> Supercomp USB 2.0 TV (em2821) |
33 | 33 -> SIIG AVTuner-PVR/Prolink PlayTV USB 2.0 (em2821) | ||
34 | 34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f] | 33 | 34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f] |
35 | 35 -> Typhoon DVD Maker (em2860) | 34 | 35 -> Typhoon DVD Maker (em2860) |
36 | 36 -> NetGMBH Cam (em2860) | 35 | 36 -> NetGMBH Cam (em2860) |
@@ -58,3 +57,7 @@ | |||
58 | 58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041] | 57 | 58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041] |
59 | 60 -> Hauppauge WinTV HVR 850 (em2883) [2040:651f] | 58 | 60 -> Hauppauge WinTV HVR 850 (em2883) [2040:651f] |
60 | 61 -> Pixelview PlayTV Box 4 USB 2.0 (em2820/em2840) | 59 | 61 -> Pixelview PlayTV Box 4 USB 2.0 (em2820/em2840) |
60 | 62 -> Gadmei TVR200 (em2820/em2840) | ||
61 | 63 -> Kaiomy TVnPC U2 (em2860) [eb1a:e303] | ||
62 | 64 -> Easy Cap Capture DC-60 (em2860) | ||
63 | 65 -> IO-DATA GV-MVP/SZ (em2820/em2840) [04bb:0515] | ||
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index b8d470596b0c..6dacf2825259 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 | |||
@@ -153,3 +153,5 @@ | |||
153 | 152 -> Asus Tiger Rev:1.00 [1043:4857] | 153 | 152 -> Asus Tiger Rev:1.00 [1043:4857] |
154 | 153 -> Kworld Plus TV Analog Lite PCI [17de:7128] | 154 | 153 -> Kworld Plus TV Analog Lite PCI [17de:7128] |
155 | 154 -> Avermedia AVerTV GO 007 FM Plus [1461:f31d] | 155 | 154 -> Avermedia AVerTV GO 007 FM Plus [1461:f31d] |
156 | 155 -> Hauppauge WinTV-HVR1120 ATSC/QAM-Hybrid [0070:6706,0070:6708] | ||
157 | 156 -> Hauppauge WinTV-HVR1110r3 [0070:6707,0070:6709,0070:670a] | ||
diff --git a/Documentation/video4linux/Zoran b/Documentation/video4linux/Zoran index 295462b2317a..0e89e7676298 100644 --- a/Documentation/video4linux/Zoran +++ b/Documentation/video4linux/Zoran | |||
@@ -401,8 +401,7 @@ Additional notes for software developers: | |||
401 | first set the correct norm. Well, it seems logically correct: TV | 401 | first set the correct norm. Well, it seems logically correct: TV |
402 | standard is "more constant" for current country than geometry | 402 | standard is "more constant" for current country than geometry |
403 | settings of a variety of TV capture cards which may work in ITU or | 403 | settings of a variety of TV capture cards which may work in ITU or |
404 | square pixel format. Remember that users now can lock the norm to | 404 | square pixel format. |
405 | avoid any ambiguity. | ||
406 | -- | 405 | -- |
407 | Please note that lavplay/lavrec are also included in the MJPEG-tools | 406 | Please note that lavplay/lavrec are also included in the MJPEG-tools |
408 | (http://mjpeg.sf.net/). | 407 | (http://mjpeg.sf.net/). |
diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options index 5ef75787f83a..bbe3ed667d91 100644 --- a/Documentation/video4linux/bttv/Insmod-options +++ b/Documentation/video4linux/bttv/Insmod-options | |||
@@ -81,16 +81,6 @@ tuner.o | |||
81 | pal=[bdgil] select PAL variant (used for some tuners | 81 | pal=[bdgil] select PAL variant (used for some tuners |
82 | only, important for the audio carrier). | 82 | only, important for the audio carrier). |
83 | 83 | ||
84 | tvmixer.o | ||
85 | registers a mixer device for the TV card's volume/bass/treble | ||
86 | controls (requires a i2c audio control chip like the msp3400). | ||
87 | |||
88 | insmod args: | ||
89 | debug=1 print some debug info to the syslog. | ||
90 | devnr=n allocate device #n (0 == /dev/mixer, | ||
91 | 1 = /dev/mixer1, ...), default is to | ||
92 | use the first free one. | ||
93 | |||
94 | tvaudio.o | 84 | tvaudio.o |
95 | new, experimental module which is supported to provide a single | 85 | new, experimental module which is supported to provide a single |
96 | driver for all simple i2c audio control chips (tda/tea*). | 86 | driver for all simple i2c audio control chips (tda/tea*). |
diff --git a/Documentation/video4linux/bttv/README b/Documentation/video4linux/bttv/README index 7ca2154c2bf5..3a367cdb664e 100644 --- a/Documentation/video4linux/bttv/README +++ b/Documentation/video4linux/bttv/README | |||
@@ -63,8 +63,8 @@ If you have some knowledge and spare time, please try to fix this | |||
63 | yourself (patches very welcome of course...) You know: The linux | 63 | yourself (patches very welcome of course...) You know: The linux |
64 | slogan is "Do it yourself". | 64 | slogan is "Do it yourself". |
65 | 65 | ||
66 | There is a mailing list: video4linux-list@redhat.com. | 66 | There is a mailing list: linux-media@vger.kernel.org |
67 | https://listman.redhat.com/mailman/listinfo/video4linux-list | 67 | http://vger.kernel.org/vger-lists.html#linux-media |
68 | 68 | ||
69 | If you have trouble with some specific TV card, try to ask there | 69 | If you have trouble with some specific TV card, try to ask there |
70 | instead of mailing me directly. The chance that someone with the | 70 | instead of mailing me directly. The chance that someone with the |
diff --git a/Documentation/video4linux/cx2341x/README.hm12 b/Documentation/video4linux/cx2341x/README.hm12 index 0e213ed095e6..b36148ea0750 100644 --- a/Documentation/video4linux/cx2341x/README.hm12 +++ b/Documentation/video4linux/cx2341x/README.hm12 | |||
@@ -32,6 +32,10 @@ Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels. | |||
32 | The width of a frame is always 720 pixels, regardless of the actual specified | 32 | The width of a frame is always 720 pixels, regardless of the actual specified |
33 | width. | 33 | width. |
34 | 34 | ||
35 | If the height is not a multiple of 32 lines, then the captured video is | ||
36 | missing macroblocks at the end and is unusable. So the height must be a | ||
37 | multiple of 32. | ||
38 | |||
35 | -------------------------------------------------------------------------- | 39 | -------------------------------------------------------------------------- |
36 | 40 | ||
37 | #include <stdio.h> | 41 | #include <stdio.h> |
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 1c58a7630146..98529e03a46e 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt | |||
@@ -32,6 +32,7 @@ spca561 041e:403b Creative Webcam Vista (VF0010) | |||
32 | zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250) | 32 | zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250) |
33 | ov519 041e:4052 Creative Live! VISTA IM | 33 | ov519 041e:4052 Creative Live! VISTA IM |
34 | zc3xx 041e:4053 Creative Live!Cam Video IM | 34 | zc3xx 041e:4053 Creative Live!Cam Video IM |
35 | vc032x 041e:405b Creative Live! Cam Notebook Ultra (VC0130) | ||
35 | ov519 041e:405f Creative Live! VISTA VF0330 | 36 | ov519 041e:405f Creative Live! VISTA VF0330 |
36 | ov519 041e:4060 Creative Live! VISTA VF0350 | 37 | ov519 041e:4060 Creative Live! VISTA VF0350 |
37 | ov519 041e:4061 Creative Live! VISTA VF0400 | 38 | ov519 041e:4061 Creative Live! VISTA VF0400 |
@@ -193,6 +194,7 @@ spca500 084d:0003 D-Link DSC-350 | |||
193 | spca500 08ca:0103 Aiptek PocketDV | 194 | spca500 08ca:0103 Aiptek PocketDV |
194 | sunplus 08ca:0104 Aiptek PocketDVII 1.3 | 195 | sunplus 08ca:0104 Aiptek PocketDVII 1.3 |
195 | sunplus 08ca:0106 Aiptek Pocket DV3100+ | 196 | sunplus 08ca:0106 Aiptek Pocket DV3100+ |
197 | mr97310a 08ca:0111 Aiptek PenCam VGA+ | ||
196 | sunplus 08ca:2008 Aiptek Mini PenCam 2 M | 198 | sunplus 08ca:2008 Aiptek Mini PenCam 2 M |
197 | sunplus 08ca:2010 Aiptek PocketCam 3M | 199 | sunplus 08ca:2010 Aiptek PocketCam 3M |
198 | sunplus 08ca:2016 Aiptek PocketCam 2 Mega | 200 | sunplus 08ca:2016 Aiptek PocketCam 2 Mega |
@@ -215,6 +217,7 @@ pac207 093a:2468 PAC207 | |||
215 | pac207 093a:2470 Genius GF112 | 217 | pac207 093a:2470 Genius GF112 |
216 | pac207 093a:2471 Genius VideoCam ge111 | 218 | pac207 093a:2471 Genius VideoCam ge111 |
217 | pac207 093a:2472 Genius VideoCam ge110 | 219 | pac207 093a:2472 Genius VideoCam ge110 |
220 | pac207 093a:2474 Genius iLook 111 | ||
218 | pac207 093a:2476 Genius e-Messenger 112 | 221 | pac207 093a:2476 Genius e-Messenger 112 |
219 | pac7311 093a:2600 PAC7311 Typhoon | 222 | pac7311 093a:2600 PAC7311 Typhoon |
220 | pac7311 093a:2601 Philips SPC 610 NC | 223 | pac7311 093a:2601 Philips SPC 610 NC |
@@ -279,6 +282,7 @@ spca561 10fd:7e50 FlyCam Usb 100 | |||
279 | zc3xx 10fd:8050 Typhoon Webshot II USB 300k | 282 | zc3xx 10fd:8050 Typhoon Webshot II USB 300k |
280 | ov534 1415:2000 Sony HD Eye for PS3 (SLEH 00201) | 283 | ov534 1415:2000 Sony HD Eye for PS3 (SLEH 00201) |
281 | pac207 145f:013a Trust WB-1300N | 284 | pac207 145f:013a Trust WB-1300N |
285 | vc032x 15b8:6001 HP 2.0 Megapixel | ||
282 | vc032x 15b8:6002 HP 2.0 Megapixel rz406aa | 286 | vc032x 15b8:6002 HP 2.0 Megapixel rz406aa |
283 | spca501 1776:501c Arowana 300K CMOS Camera | 287 | spca501 1776:501c Arowana 300K CMOS Camera |
284 | t613 17a1:0128 TASCORP JPEG Webcam, NGS Cyclops | 288 | t613 17a1:0128 TASCORP JPEG Webcam, NGS Cyclops |
diff --git a/Documentation/video4linux/pxa_camera.txt b/Documentation/video4linux/pxa_camera.txt new file mode 100644 index 000000000000..b1137f9a53eb --- /dev/null +++ b/Documentation/video4linux/pxa_camera.txt | |||
@@ -0,0 +1,125 @@ | |||
1 | PXA-Camera Host Driver | ||
2 | ====================== | ||
3 | |||
4 | Constraints | ||
5 | ----------- | ||
6 | a) Image size for YUV422P format | ||
7 | All YUV422P images are enforced to have width x height % 16 = 0. | ||
8 | This is due to DMA constraints, which transfers only planes of 8 byte | ||
9 | multiples. | ||
10 | |||
11 | |||
12 | Global video workflow | ||
13 | --------------------- | ||
14 | a) QCI stopped | ||
15 | Initialy, the QCI interface is stopped. | ||
16 | When a buffer is queued (pxa_videobuf_ops->buf_queue), the QCI starts. | ||
17 | |||
18 | b) QCI started | ||
19 | More buffers can be queued while the QCI is started without halting the | ||
20 | capture. The new buffers are "appended" at the tail of the DMA chain, and | ||
21 | smoothly captured one frame after the other. | ||
22 | |||
23 | Once a buffer is filled in the QCI interface, it is marked as "DONE" and | ||
24 | removed from the active buffers list. It can be then requeud or dequeued by | ||
25 | userland application. | ||
26 | |||
27 | Once the last buffer is filled in, the QCI interface stops. | ||
28 | |||
29 | |||
30 | DMA usage | ||
31 | --------- | ||
32 | a) DMA flow | ||
33 | - first buffer queued for capture | ||
34 | Once a first buffer is queued for capture, the QCI is started, but data | ||
35 | transfer is not started. On "End Of Frame" interrupt, the irq handler | ||
36 | starts the DMA chain. | ||
37 | - capture of one videobuffer | ||
38 | The DMA chain starts transfering data into videobuffer RAM pages. | ||
39 | When all pages are transfered, the DMA irq is raised on "ENDINTR" status | ||
40 | - finishing one videobuffer | ||
41 | The DMA irq handler marks the videobuffer as "done", and removes it from | ||
42 | the active running queue | ||
43 | Meanwhile, the next videobuffer (if there is one), is transfered by DMA | ||
44 | - finishing the last videobuffer | ||
45 | On the DMA irq of the last videobuffer, the QCI is stopped. | ||
46 | |||
47 | b) DMA prepared buffer will have this structure | ||
48 | |||
49 | +------------+-----+---------------+-----------------+ | ||
50 | | desc-sg[0] | ... | desc-sg[last] | finisher/linker | | ||
51 | +------------+-----+---------------+-----------------+ | ||
52 | |||
53 | This structure is pointed by dma->sg_cpu. | ||
54 | The descriptors are used as follows : | ||
55 | - desc-sg[i]: i-th descriptor, transfering the i-th sg | ||
56 | element to the video buffer scatter gather | ||
57 | - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN | ||
58 | - linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0 | ||
59 | |||
60 | For the next schema, let's assume d0=desc-sg[0] .. dN=desc-sg[N], | ||
61 | "f" stands for finisher and "l" for linker. | ||
62 | A typical running chain is : | ||
63 | |||
64 | Videobuffer 1 Videobuffer 2 | ||
65 | +---------+----+---+ +----+----+----+---+ | ||
66 | | d0 | .. | dN | l | | d0 | .. | dN | f | | ||
67 | +---------+----+-|-+ ^----+----+----+---+ | ||
68 | | | | ||
69 | +----+ | ||
70 | |||
71 | After the chaining is finished, the chain looks like : | ||
72 | |||
73 | Videobuffer 1 Videobuffer 2 Videobuffer 3 | ||
74 | +---------+----+---+ +----+----+----+---+ +----+----+----+---+ | ||
75 | | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f | | ||
76 | +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+ | ||
77 | | | | | | ||
78 | +----+ +----+ | ||
79 | new_link | ||
80 | |||
81 | c) DMA hot chaining timeslice issue | ||
82 | |||
83 | As DMA chaining is done while DMA _is_ running, the linking may be done | ||
84 | while the DMA jumps from one Videobuffer to another. On the schema, that | ||
85 | would be a problem if the following sequence is encountered : | ||
86 | |||
87 | - DMA chain is Videobuffer1 + Videobuffer2 | ||
88 | - pxa_videobuf_queue() is called to queue Videobuffer3 | ||
89 | - DMA controller finishes Videobuffer2, and DMA stops | ||
90 | => | ||
91 | Videobuffer 1 Videobuffer 2 | ||
92 | +---------+----+---+ +----+----+----+---+ | ||
93 | | d0 | .. | dN | l | | d0 | .. | dN | f | | ||
94 | +---------+----+-|-+ ^----+----+----+-^-+ | ||
95 | | | | | ||
96 | +----+ +-- DMA DDADR loads DDADR_STOP | ||
97 | |||
98 | - pxa_dma_add_tail_buf() is called, the Videobuffer2 "finisher" is | ||
99 | replaced by a "linker" to Videobuffer3 (creation of new_link) | ||
100 | - pxa_videobuf_queue() finishes | ||
101 | - the DMA irq handler is called, which terminates Videobuffer2 | ||
102 | - Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!) | ||
103 | |||
104 | Videobuffer 1 Videobuffer 2 Videobuffer 3 | ||
105 | +---------+----+---+ +----+----+----+---+ +----+----+----+---+ | ||
106 | | d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f | | ||
107 | +---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+ | ||
108 | | | | | | ||
109 | +----+ +----+ | ||
110 | new_link | ||
111 | DMA DDADR still is DDADR_STOP | ||
112 | |||
113 | - pxa_camera_check_link_miss() is called | ||
114 | This checks if the DMA is finished and a buffer is still on the | ||
115 | pcdev->capture list. If that's the case, the capture will be restarted, | ||
116 | and Videobuffer3 is scheduled on DMA chain. | ||
117 | - the DMA irq handler finishes | ||
118 | |||
119 | Note: if DMA stops just after pxa_camera_check_link_miss() reads DDADR() | ||
120 | value, we have the guarantee that the DMA irq handler will be called back | ||
121 | when the DMA will finish the buffer, and pxa_camera_check_link_miss() will | ||
122 | be called again, to reschedule Videobuffer3. | ||
123 | |||
124 | -- | ||
125 | Author: Robert Jarzmik <robert.jarzmik@free.fr> | ||
diff --git a/Documentation/video4linux/si470x.txt b/Documentation/video4linux/si470x.txt index 49679e6aaa76..3a7823e01b4d 100644 --- a/Documentation/video4linux/si470x.txt +++ b/Documentation/video4linux/si470x.txt | |||
@@ -1,6 +1,6 @@ | |||
1 | Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers | 1 | Driver for USB radios for the Silicon Labs Si470x FM Radio Receivers |
2 | 2 | ||
3 | Copyright (c) 2008 Tobias Lorenz <tobias.lorenz@gmx.net> | 3 | Copyright (c) 2009 Tobias Lorenz <tobias.lorenz@gmx.net> |
4 | 4 | ||
5 | 5 | ||
6 | Information from Silicon Labs | 6 | Information from Silicon Labs |
@@ -41,7 +41,7 @@ chips are known to work: | |||
41 | - 10c4:818a: Silicon Labs USB FM Radio Reference Design | 41 | - 10c4:818a: Silicon Labs USB FM Radio Reference Design |
42 | - 06e1:a155: ADS/Tech FM Radio Receiver (formerly Instant FM Music) (RDX-155-EF) | 42 | - 06e1:a155: ADS/Tech FM Radio Receiver (formerly Instant FM Music) (RDX-155-EF) |
43 | - 1b80:d700: KWorld USB FM Radio SnapMusic Mobile 700 (FM700) | 43 | - 1b80:d700: KWorld USB FM Radio SnapMusic Mobile 700 (FM700) |
44 | - 10c5:819a: DealExtreme USB Radio | 44 | - 10c5:819a: Sanei Electric, Inc. FM USB Radio (sold as DealExtreme.com PCear) |
45 | 45 | ||
46 | 46 | ||
47 | Software | 47 | Software |
@@ -52,6 +52,7 @@ Testing is usually done with most application under Debian/testing: | |||
52 | - gradio - GTK FM radio tuner | 52 | - gradio - GTK FM radio tuner |
53 | - kradio - Comfortable Radio Application for KDE | 53 | - kradio - Comfortable Radio Application for KDE |
54 | - radio - ncurses-based radio application | 54 | - radio - ncurses-based radio application |
55 | - mplayer - The Ultimate Movie Player For Linux | ||
55 | 56 | ||
56 | There is also a library libv4l, which can be used. It's going to have a function | 57 | There is also a library libv4l, which can be used. It's going to have a function |
57 | for frequency seeking, either by using hardware functionality as in radio-si470x | 58 | for frequency seeking, either by using hardware functionality as in radio-si470x |
@@ -69,7 +70,7 @@ Audio Listing | |||
69 | USB Audio is provided by the ALSA snd_usb_audio module. It is recommended to | 70 | USB Audio is provided by the ALSA snd_usb_audio module. It is recommended to |
70 | also select SND_USB_AUDIO, as this is required to get sound from the radio. For | 71 | also select SND_USB_AUDIO, as this is required to get sound from the radio. For |
71 | listing you have to redirect the sound, for example using one of the following | 72 | listing you have to redirect the sound, for example using one of the following |
72 | commands. | 73 | commands. Please adjust the audio devices to your needs (/dev/dsp* and hw:x,x). |
73 | 74 | ||
74 | If you just want to test audio (very poor quality): | 75 | If you just want to test audio (very poor quality): |
75 | cat /dev/dsp1 > /dev/dsp | 76 | cat /dev/dsp1 > /dev/dsp |
@@ -80,6 +81,10 @@ sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp | |||
80 | If you use arts try: | 81 | If you use arts try: |
81 | arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B - | 82 | arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B - |
82 | 83 | ||
84 | If you use mplayer try: | ||
85 | mplayer -radio adevice=hw=1.0:arate=96000 \ | ||
86 | -rawaudio rate=96000 \ | ||
87 | radio://<frequency>/capture | ||
83 | 88 | ||
84 | Module Parameters | 89 | Module Parameters |
85 | ================= | 90 | ================= |
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index ff124374e9ba..854808b67fae 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt | |||
@@ -47,7 +47,9 @@ All drivers have the following structure: | |||
47 | 3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX, /dev/radioX and | 47 | 3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX, /dev/radioX and |
48 | /dev/vtxX) and keeping track of device-node specific data. | 48 | /dev/vtxX) and keeping track of device-node specific data. |
49 | 49 | ||
50 | 4) Filehandle-specific structs containing per-filehandle data. | 50 | 4) Filehandle-specific structs containing per-filehandle data; |
51 | |||
52 | 5) video buffer handling. | ||
51 | 53 | ||
52 | This is a rough schematic of how it all relates: | 54 | This is a rough schematic of how it all relates: |
53 | 55 | ||
@@ -82,12 +84,20 @@ You must register the device instance: | |||
82 | v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev); | 84 | v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev); |
83 | 85 | ||
84 | Registration will initialize the v4l2_device struct and link dev->driver_data | 86 | Registration will initialize the v4l2_device struct and link dev->driver_data |
85 | to v4l2_dev. Registration will also set v4l2_dev->name to a value derived from | 87 | to v4l2_dev. If v4l2_dev->name is empty then it will be set to a value derived |
86 | dev (driver name followed by the bus_id, to be precise). You may change the | 88 | from dev (driver name followed by the bus_id, to be precise). If you set it |
87 | name after registration if you want. | 89 | up before calling v4l2_device_register then it will be untouched. If dev is |
90 | NULL, then you *must* setup v4l2_dev->name before calling v4l2_device_register. | ||
88 | 91 | ||
89 | The first 'dev' argument is normally the struct device pointer of a pci_dev, | 92 | The first 'dev' argument is normally the struct device pointer of a pci_dev, |
90 | usb_device or platform_device. | 93 | usb_interface or platform_device. It is rare for dev to be NULL, but it happens |
94 | with ISA devices or when one device creates multiple PCI devices, thus making | ||
95 | it impossible to associate v4l2_dev with a particular parent. | ||
96 | |||
97 | You can also supply a notify() callback that can be called by sub-devices to | ||
98 | notify you of events. Whether you need to set this depends on the sub-device. | ||
99 | Any notifications a sub-device supports must be defined in a header in | ||
100 | include/media/<subdevice>.h. | ||
91 | 101 | ||
92 | You unregister with: | 102 | You unregister with: |
93 | 103 | ||
@@ -95,6 +105,17 @@ You unregister with: | |||
95 | 105 | ||
96 | Unregistering will also automatically unregister all subdevs from the device. | 106 | Unregistering will also automatically unregister all subdevs from the device. |
97 | 107 | ||
108 | If you have a hotpluggable device (e.g. a USB device), then when a disconnect | ||
109 | happens the parent device becomes invalid. Since v4l2_device has a pointer to | ||
110 | that parent device it has to be cleared as well to mark that the parent is | ||
111 | gone. To do this call: | ||
112 | |||
113 | v4l2_device_disconnect(struct v4l2_device *v4l2_dev); | ||
114 | |||
115 | This does *not* unregister the subdevs, so you still need to call the | ||
116 | v4l2_device_unregister() function for that. If your driver is not hotpluggable, | ||
117 | then there is no need to call v4l2_device_disconnect(). | ||
118 | |||
98 | Sometimes you need to iterate over all devices registered by a specific | 119 | Sometimes you need to iterate over all devices registered by a specific |
99 | driver. This is usually the case if multiple device drivers use the same | 120 | driver. This is usually the case if multiple device drivers use the same |
100 | hardware. E.g. the ivtvfb driver is a framebuffer driver that uses the ivtv | 121 | hardware. E.g. the ivtvfb driver is a framebuffer driver that uses the ivtv |
@@ -134,7 +155,7 @@ The recommended approach is as follows: | |||
134 | 155 | ||
135 | static atomic_t drv_instance = ATOMIC_INIT(0); | 156 | static atomic_t drv_instance = ATOMIC_INIT(0); |
136 | 157 | ||
137 | static int __devinit drv_probe(struct pci_dev *dev, | 158 | static int __devinit drv_probe(struct pci_dev *pdev, |
138 | const struct pci_device_id *pci_id) | 159 | const struct pci_device_id *pci_id) |
139 | { | 160 | { |
140 | ... | 161 | ... |
@@ -218,7 +239,7 @@ to add new ops and categories. | |||
218 | 239 | ||
219 | A sub-device driver initializes the v4l2_subdev struct using: | 240 | A sub-device driver initializes the v4l2_subdev struct using: |
220 | 241 | ||
221 | v4l2_subdev_init(subdev, &ops); | 242 | v4l2_subdev_init(sd, &ops); |
222 | 243 | ||
223 | Afterwards you need to initialize subdev->name with a unique name and set the | 244 | Afterwards you need to initialize subdev->name with a unique name and set the |
224 | module owner. This is done for you if you use the i2c helper functions. | 245 | module owner. This is done for you if you use the i2c helper functions. |
@@ -226,7 +247,7 @@ module owner. This is done for you if you use the i2c helper functions. | |||
226 | A device (bridge) driver needs to register the v4l2_subdev with the | 247 | A device (bridge) driver needs to register the v4l2_subdev with the |
227 | v4l2_device: | 248 | v4l2_device: |
228 | 249 | ||
229 | int err = v4l2_device_register_subdev(device, subdev); | 250 | int err = v4l2_device_register_subdev(v4l2_dev, sd); |
230 | 251 | ||
231 | This can fail if the subdev module disappeared before it could be registered. | 252 | This can fail if the subdev module disappeared before it could be registered. |
232 | After this function was called successfully the subdev->dev field points to | 253 | After this function was called successfully the subdev->dev field points to |
@@ -234,17 +255,17 @@ the v4l2_device. | |||
234 | 255 | ||
235 | You can unregister a sub-device using: | 256 | You can unregister a sub-device using: |
236 | 257 | ||
237 | v4l2_device_unregister_subdev(subdev); | 258 | v4l2_device_unregister_subdev(sd); |
238 | 259 | ||
239 | Afterwards the subdev module can be unloaded and subdev->dev == NULL. | 260 | Afterwards the subdev module can be unloaded and sd->dev == NULL. |
240 | 261 | ||
241 | You can call an ops function either directly: | 262 | You can call an ops function either directly: |
242 | 263 | ||
243 | err = subdev->ops->core->g_chip_ident(subdev, &chip); | 264 | err = sd->ops->core->g_chip_ident(sd, &chip); |
244 | 265 | ||
245 | but it is better and easier to use this macro: | 266 | but it is better and easier to use this macro: |
246 | 267 | ||
247 | err = v4l2_subdev_call(subdev, core, g_chip_ident, &chip); | 268 | err = v4l2_subdev_call(sd, core, g_chip_ident, &chip); |
248 | 269 | ||
249 | The macro will to the right NULL pointer checks and returns -ENODEV if subdev | 270 | The macro will to the right NULL pointer checks and returns -ENODEV if subdev |
250 | is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_chip_ident is | 271 | is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_chip_ident is |
@@ -252,19 +273,19 @@ NULL, or the actual result of the subdev->ops->core->g_chip_ident ops. | |||
252 | 273 | ||
253 | It is also possible to call all or a subset of the sub-devices: | 274 | It is also possible to call all or a subset of the sub-devices: |
254 | 275 | ||
255 | v4l2_device_call_all(dev, 0, core, g_chip_ident, &chip); | 276 | v4l2_device_call_all(v4l2_dev, 0, core, g_chip_ident, &chip); |
256 | 277 | ||
257 | Any subdev that does not support this ops is skipped and error results are | 278 | Any subdev that does not support this ops is skipped and error results are |
258 | ignored. If you want to check for errors use this: | 279 | ignored. If you want to check for errors use this: |
259 | 280 | ||
260 | err = v4l2_device_call_until_err(dev, 0, core, g_chip_ident, &chip); | 281 | err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip); |
261 | 282 | ||
262 | Any error except -ENOIOCTLCMD will exit the loop with that error. If no | 283 | Any error except -ENOIOCTLCMD will exit the loop with that error. If no |
263 | errors (except -ENOIOCTLCMD) occured, then 0 is returned. | 284 | errors (except -ENOIOCTLCMD) occured, then 0 is returned. |
264 | 285 | ||
265 | The second argument to both calls is a group ID. If 0, then all subdevs are | 286 | The second argument to both calls is a group ID. If 0, then all subdevs are |
266 | called. If non-zero, then only those whose group ID match that value will | 287 | called. If non-zero, then only those whose group ID match that value will |
267 | be called. Before a bridge driver registers a subdev it can set subdev->grp_id | 288 | be called. Before a bridge driver registers a subdev it can set sd->grp_id |
268 | to whatever value it wants (it's 0 by default). This value is owned by the | 289 | to whatever value it wants (it's 0 by default). This value is owned by the |
269 | bridge driver and the sub-device driver will never modify or use it. | 290 | bridge driver and the sub-device driver will never modify or use it. |
270 | 291 | ||
@@ -276,6 +297,11 @@ e.g. AUDIO_CONTROLLER and specify that as the group ID value when calling | |||
276 | v4l2_device_call_all(). That ensures that it will only go to the subdev | 297 | v4l2_device_call_all(). That ensures that it will only go to the subdev |
277 | that needs it. | 298 | that needs it. |
278 | 299 | ||
300 | If the sub-device needs to notify its v4l2_device parent of an event, then | ||
301 | it can call v4l2_subdev_notify(sd, notification, arg). This macro checks | ||
302 | whether there is a notify() callback defined and returns -ENODEV if not. | ||
303 | Otherwise the result of the notify() call is returned. | ||
304 | |||
279 | The advantage of using v4l2_subdev is that it is a generic struct and does | 305 | The advantage of using v4l2_subdev is that it is a generic struct and does |
280 | not contain any knowledge about the underlying hardware. So a driver might | 306 | not contain any knowledge about the underlying hardware. So a driver might |
281 | contain several subdevs that use an I2C bus, but also a subdev that is | 307 | contain several subdevs that use an I2C bus, but also a subdev that is |
@@ -325,32 +351,25 @@ And this to go from an i2c_client to a v4l2_subdev struct: | |||
325 | 351 | ||
326 | struct v4l2_subdev *sd = i2c_get_clientdata(client); | 352 | struct v4l2_subdev *sd = i2c_get_clientdata(client); |
327 | 353 | ||
328 | Finally you need to make a command function to make driver->command() | ||
329 | call the right subdev_ops functions: | ||
330 | |||
331 | static int subdev_command(struct i2c_client *client, unsigned cmd, void *arg) | ||
332 | { | ||
333 | return v4l2_subdev_command(i2c_get_clientdata(client), cmd, arg); | ||
334 | } | ||
335 | |||
336 | If driver->command is never used then you can leave this out. Eventually the | ||
337 | driver->command usage should be removed from v4l. | ||
338 | |||
339 | Make sure to call v4l2_device_unregister_subdev(sd) when the remove() callback | 354 | Make sure to call v4l2_device_unregister_subdev(sd) when the remove() callback |
340 | is called. This will unregister the sub-device from the bridge driver. It is | 355 | is called. This will unregister the sub-device from the bridge driver. It is |
341 | safe to call this even if the sub-device was never registered. | 356 | safe to call this even if the sub-device was never registered. |
342 | 357 | ||
358 | You need to do this because when the bridge driver destroys the i2c adapter | ||
359 | the remove() callbacks are called of the i2c devices on that adapter. | ||
360 | After that the corresponding v4l2_subdev structures are invalid, so they | ||
361 | have to be unregistered first. Calling v4l2_device_unregister_subdev(sd) | ||
362 | from the remove() callback ensures that this is always done correctly. | ||
363 | |||
343 | 364 | ||
344 | The bridge driver also has some helper functions it can use: | 365 | The bridge driver also has some helper functions it can use: |
345 | 366 | ||
346 | struct v4l2_subdev *sd = v4l2_i2c_new_subdev(adapter, "module_foo", "chipid", 0x36); | 367 | struct v4l2_subdev *sd = v4l2_i2c_new_subdev(v4l2_dev, adapter, |
368 | "module_foo", "chipid", 0x36); | ||
347 | 369 | ||
348 | This loads the given module (can be NULL if no module needs to be loaded) and | 370 | This loads the given module (can be NULL if no module needs to be loaded) and |
349 | calls i2c_new_device() with the given i2c_adapter and chip/address arguments. | 371 | calls i2c_new_device() with the given i2c_adapter and chip/address arguments. |
350 | If all goes well, then it registers the subdev with the v4l2_device. It gets | 372 | If all goes well, then it registers the subdev with the v4l2_device. |
351 | the v4l2_device by calling i2c_get_adapdata(adapter), so you should make sure | ||
352 | that adapdata is set to v4l2_device when you setup the i2c_adapter in your | ||
353 | driver. | ||
354 | 373 | ||
355 | You can also use v4l2_i2c_new_probed_subdev() which is very similar to | 374 | You can also use v4l2_i2c_new_probed_subdev() which is very similar to |
356 | v4l2_i2c_new_subdev(), except that it has an array of possible I2C addresses | 375 | v4l2_i2c_new_subdev(), except that it has an array of possible I2C addresses |
@@ -358,6 +377,14 @@ that it should probe. Internally it calls i2c_new_probed_device(). | |||
358 | 377 | ||
359 | Both functions return NULL if something went wrong. | 378 | Both functions return NULL if something went wrong. |
360 | 379 | ||
380 | Note that the chipid you pass to v4l2_i2c_new_(probed_)subdev() is usually | ||
381 | the same as the module name. It allows you to specify a chip variant, e.g. | ||
382 | "saa7114" or "saa7115". In general though the i2c driver autodetects this. | ||
383 | The use of chipid is something that needs to be looked at more closely at a | ||
384 | later date. It differs between i2c drivers and as such can be confusing. | ||
385 | To see which chip variants are supported you can look in the i2c driver code | ||
386 | for the i2c_device_id table. This lists all the possibilities. | ||
387 | |||
361 | 388 | ||
362 | struct video_device | 389 | struct video_device |
363 | ------------------- | 390 | ------------------- |
@@ -396,6 +423,15 @@ You should also set these fields: | |||
396 | - ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance | 423 | - ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance |
397 | (highly recommended to use this and it might become compulsory in the | 424 | (highly recommended to use this and it might become compulsory in the |
398 | future!), then set this to your v4l2_ioctl_ops struct. | 425 | future!), then set this to your v4l2_ioctl_ops struct. |
426 | - parent: you only set this if v4l2_device was registered with NULL as | ||
427 | the parent device struct. This only happens in cases where one hardware | ||
428 | device has multiple PCI devices that all share the same v4l2_device core. | ||
429 | |||
430 | The cx88 driver is an example of this: one core v4l2_device struct, but | ||
431 | it is used by both an raw video PCI device (cx8800) and a MPEG PCI device | ||
432 | (cx8802). Since the v4l2_device cannot be associated with a particular | ||
433 | PCI device it is setup without a parent device. But when the struct | ||
434 | video_device is setup you do know which parent PCI device to use. | ||
399 | 435 | ||
400 | If you use v4l2_ioctl_ops, then you should set either .unlocked_ioctl or | 436 | If you use v4l2_ioctl_ops, then you should set either .unlocked_ioctl or |
401 | .ioctl to video_ioctl2 in your v4l2_file_operations struct. | 437 | .ioctl to video_ioctl2 in your v4l2_file_operations struct. |
@@ -499,8 +535,8 @@ There are a few useful helper functions: | |||
499 | 535 | ||
500 | You can set/get driver private data in the video_device struct using: | 536 | You can set/get driver private data in the video_device struct using: |
501 | 537 | ||
502 | void *video_get_drvdata(struct video_device *dev); | 538 | void *video_get_drvdata(struct video_device *vdev); |
503 | void video_set_drvdata(struct video_device *dev, void *data); | 539 | void video_set_drvdata(struct video_device *vdev, void *data); |
504 | 540 | ||
505 | Note that you can safely call video_set_drvdata() before calling | 541 | Note that you can safely call video_set_drvdata() before calling |
506 | video_register_device(). | 542 | video_register_device(). |
@@ -519,3 +555,103 @@ void *video_drvdata(struct file *file); | |||
519 | You can go from a video_device struct to the v4l2_device struct using: | 555 | You can go from a video_device struct to the v4l2_device struct using: |
520 | 556 | ||
521 | struct v4l2_device *v4l2_dev = vdev->v4l2_dev; | 557 | struct v4l2_device *v4l2_dev = vdev->v4l2_dev; |
558 | |||
559 | video buffer helper functions | ||
560 | ----------------------------- | ||
561 | |||
562 | The v4l2 core API provides a standard method for dealing with video | ||
563 | buffers. Those methods allow a driver to implement read(), mmap() and | ||
564 | overlay() on a consistent way. | ||
565 | |||
566 | There are currently methods for using video buffers on devices that | ||
567 | supports DMA with scatter/gather method (videobuf-dma-sg), DMA with | ||
568 | linear access (videobuf-dma-contig), and vmalloced buffers, mostly | ||
569 | used on USB drivers (videobuf-vmalloc). | ||
570 | |||
571 | Any driver using videobuf should provide operations (callbacks) for | ||
572 | four handlers: | ||
573 | |||
574 | ops->buf_setup - calculates the size of the video buffers and avoid they | ||
575 | to waste more than some maximum limit of RAM; | ||
576 | ops->buf_prepare - fills the video buffer structs and calls | ||
577 | videobuf_iolock() to alloc and prepare mmaped memory; | ||
578 | ops->buf_queue - advices the driver that another buffer were | ||
579 | requested (by read() or by QBUF); | ||
580 | ops->buf_release - frees any buffer that were allocated. | ||
581 | |||
582 | In order to use it, the driver need to have a code (generally called at | ||
583 | interrupt context) that will properly handle the buffer request lists, | ||
584 | announcing that a new buffer were filled. | ||
585 | |||
586 | The irq handling code should handle the videobuf task lists, in order | ||
587 | to advice videobuf that a new frame were filled, in order to honor to a | ||
588 | request. The code is generally like this one: | ||
589 | if (list_empty(&dma_q->active)) | ||
590 | return; | ||
591 | |||
592 | buf = list_entry(dma_q->active.next, struct vbuffer, vb.queue); | ||
593 | |||
594 | if (!waitqueue_active(&buf->vb.done)) | ||
595 | return; | ||
596 | |||
597 | /* Some logic to handle the buf may be needed here */ | ||
598 | |||
599 | list_del(&buf->vb.queue); | ||
600 | do_gettimeofday(&buf->vb.ts); | ||
601 | wake_up(&buf->vb.done); | ||
602 | |||
603 | Those are the videobuffer functions used on drivers, implemented on | ||
604 | videobuf-core: | ||
605 | |||
606 | - Videobuf init functions | ||
607 | videobuf_queue_sg_init() | ||
608 | Initializes the videobuf infrastructure. This function should be | ||
609 | called before any other videobuf function on drivers that uses DMA | ||
610 | Scatter/Gather buffers. | ||
611 | |||
612 | videobuf_queue_dma_contig_init | ||
613 | Initializes the videobuf infrastructure. This function should be | ||
614 | called before any other videobuf function on drivers that need DMA | ||
615 | contiguous buffers. | ||
616 | |||
617 | videobuf_queue_vmalloc_init() | ||
618 | Initializes the videobuf infrastructure. This function should be | ||
619 | called before any other videobuf function on USB (and other drivers) | ||
620 | that need a vmalloced type of videobuf. | ||
621 | |||
622 | - videobuf_iolock() | ||
623 | Prepares the videobuf memory for the proper method (read, mmap, overlay). | ||
624 | |||
625 | - videobuf_queue_is_busy() | ||
626 | Checks if a videobuf is streaming. | ||
627 | |||
628 | - videobuf_queue_cancel() | ||
629 | Stops video handling. | ||
630 | |||
631 | - videobuf_mmap_free() | ||
632 | frees mmap buffers. | ||
633 | |||
634 | - videobuf_stop() | ||
635 | Stops video handling, ends mmap and frees mmap and other buffers. | ||
636 | |||
637 | - V4L2 api functions. Those functions correspond to VIDIOC_foo ioctls: | ||
638 | videobuf_reqbufs(), videobuf_querybuf(), videobuf_qbuf(), | ||
639 | videobuf_dqbuf(), videobuf_streamon(), videobuf_streamoff(). | ||
640 | |||
641 | - V4L1 api function (corresponds to VIDIOCMBUF ioctl): | ||
642 | videobuf_cgmbuf() | ||
643 | This function is used to provide backward compatibility with V4L1 | ||
644 | API. | ||
645 | |||
646 | - Some help functions for read()/poll() operations: | ||
647 | videobuf_read_stream() | ||
648 | For continuous stream read() | ||
649 | videobuf_read_one() | ||
650 | For snapshot read() | ||
651 | videobuf_poll_stream() | ||
652 | polling help function | ||
653 | |||
654 | The better way to understand it is to take a look at vivi driver. One | ||
655 | of the main reasons for vivi is to be a videobuf usage example. the | ||
656 | vivi_thread_tick() does the task that the IRQ callback would do on PCI | ||
657 | drivers (or the irq callback on USB). | ||
diff --git a/Documentation/video4linux/v4lgrab.c b/Documentation/video4linux/v4lgrab.c index d6e70bef8ad0..05769cff1009 100644 --- a/Documentation/video4linux/v4lgrab.c +++ b/Documentation/video4linux/v4lgrab.c | |||
@@ -105,8 +105,8 @@ int main(int argc, char ** argv) | |||
105 | struct video_picture vpic; | 105 | struct video_picture vpic; |
106 | 106 | ||
107 | unsigned char *buffer, *src; | 107 | unsigned char *buffer, *src; |
108 | int bpp = 24, r, g, b; | 108 | int bpp = 24, r = 0, g = 0, b = 0; |
109 | unsigned int i, src_depth; | 109 | unsigned int i, src_depth = 16; |
110 | 110 | ||
111 | if (fd < 0) { | 111 | if (fd < 0) { |
112 | perror(VIDEO_DEV); | 112 | perror(VIDEO_DEV); |
diff --git a/Documentation/video4linux/zr364xx.txt b/Documentation/video4linux/zr364xx.txt index 5c81e3ae6458..7f3d1955d214 100644 --- a/Documentation/video4linux/zr364xx.txt +++ b/Documentation/video4linux/zr364xx.txt | |||
@@ -65,3 +65,4 @@ Vendor Product Distributor Model | |||
65 | 0x06d6 0x003b Trust Powerc@m 970Z | 65 | 0x06d6 0x003b Trust Powerc@m 970Z |
66 | 0x0a17 0x004e Pentax Optio 50 | 66 | 0x0a17 0x004e Pentax Optio 50 |
67 | 0x041e 0x405d Creative DiVi CAM 516 | 67 | 0x041e 0x405d Creative DiVi CAM 516 |
68 | 0x08ca 0x2102 Aiptek DV T300 | ||
diff --git a/Documentation/vm/kmemtrace.txt b/Documentation/vm/kmemtrace.txt new file mode 100644 index 000000000000..a956d9b7f943 --- /dev/null +++ b/Documentation/vm/kmemtrace.txt | |||
@@ -0,0 +1,126 @@ | |||
1 | kmemtrace - Kernel Memory Tracer | ||
2 | |||
3 | by Eduard - Gabriel Munteanu | ||
4 | <eduard.munteanu@linux360.ro> | ||
5 | |||
6 | I. Introduction | ||
7 | =============== | ||
8 | |||
9 | kmemtrace helps kernel developers figure out two things: | ||
10 | 1) how different allocators (SLAB, SLUB etc.) perform | ||
11 | 2) how kernel code allocates memory and how much | ||
12 | |||
13 | To do this, we trace every allocation and export information to the userspace | ||
14 | through the relay interface. We export things such as the number of requested | ||
15 | bytes, the number of bytes actually allocated (i.e. including internal | ||
16 | fragmentation), whether this is a slab allocation or a plain kmalloc() and so | ||
17 | on. | ||
18 | |||
19 | The actual analysis is performed by a userspace tool (see section III for | ||
20 | details on where to get it from). It logs the data exported by the kernel, | ||
21 | processes it and (as of writing this) can provide the following information: | ||
22 | - the total amount of memory allocated and fragmentation per call-site | ||
23 | - the amount of memory allocated and fragmentation per allocation | ||
24 | - total memory allocated and fragmentation in the collected dataset | ||
25 | - number of cross-CPU allocation and frees (makes sense in NUMA environments) | ||
26 | |||
27 | Moreover, it can potentially find inconsistent and erroneous behavior in | ||
28 | kernel code, such as using slab free functions on kmalloc'ed memory or | ||
29 | allocating less memory than requested (but not truly failed allocations). | ||
30 | |||
31 | kmemtrace also makes provisions for tracing on some arch and analysing the | ||
32 | data on another. | ||
33 | |||
34 | II. Design and goals | ||
35 | ==================== | ||
36 | |||
37 | kmemtrace was designed to handle rather large amounts of data. Thus, it uses | ||
38 | the relay interface to export whatever is logged to userspace, which then | ||
39 | stores it. Analysis and reporting is done asynchronously, that is, after the | ||
40 | data is collected and stored. By design, it allows one to log and analyse | ||
41 | on different machines and different arches. | ||
42 | |||
43 | As of writing this, the ABI is not considered stable, though it might not | ||
44 | change much. However, no guarantees are made about compatibility yet. When | ||
45 | deemed stable, the ABI should still allow easy extension while maintaining | ||
46 | backward compatibility. This is described further in Documentation/ABI. | ||
47 | |||
48 | Summary of design goals: | ||
49 | - allow logging and analysis to be done across different machines | ||
50 | - be fast and anticipate usage in high-load environments (*) | ||
51 | - be reasonably extensible | ||
52 | - make it possible for GNU/Linux distributions to have kmemtrace | ||
53 | included in their repositories | ||
54 | |||
55 | (*) - one of the reasons Pekka Enberg's original userspace data analysis | ||
56 | tool's code was rewritten from Perl to C (although this is more than a | ||
57 | simple conversion) | ||
58 | |||
59 | |||
60 | III. Quick usage guide | ||
61 | ====================== | ||
62 | |||
63 | 1) Get a kernel that supports kmemtrace and build it accordingly (i.e. enable | ||
64 | CONFIG_KMEMTRACE). | ||
65 | |||
66 | 2) Get the userspace tool and build it: | ||
67 | $ git-clone git://repo.or.cz/kmemtrace-user.git # current repository | ||
68 | $ cd kmemtrace-user/ | ||
69 | $ ./autogen.sh | ||
70 | $ ./configure | ||
71 | $ make | ||
72 | |||
73 | 3) Boot the kmemtrace-enabled kernel if you haven't, preferably in the | ||
74 | 'single' runlevel (so that relay buffers don't fill up easily), and run | ||
75 | kmemtrace: | ||
76 | # '$' does not mean user, but root here. | ||
77 | $ mount -t debugfs none /sys/kernel/debug | ||
78 | $ mount -t proc none /proc | ||
79 | $ cd path/to/kmemtrace-user/ | ||
80 | $ ./kmemtraced | ||
81 | Wait a bit, then stop it with CTRL+C. | ||
82 | $ cat /sys/kernel/debug/kmemtrace/total_overruns # Check if we didn't | ||
83 | # overrun, should | ||
84 | # be zero. | ||
85 | $ (Optionally) [Run kmemtrace_check separately on each cpu[0-9]*.out file to | ||
86 | check its correctness] | ||
87 | $ ./kmemtrace-report | ||
88 | |||
89 | Now you should have a nice and short summary of how the allocator performs. | ||
90 | |||
91 | IV. FAQ and known issues | ||
92 | ======================== | ||
93 | |||
94 | Q: 'cat /sys/kernel/debug/kmemtrace/total_overruns' is non-zero, how do I fix | ||
95 | this? Should I worry? | ||
96 | A: If it's non-zero, this affects kmemtrace's accuracy, depending on how | ||
97 | large the number is. You can fix it by supplying a higher | ||
98 | 'kmemtrace.subbufs=N' kernel parameter. | ||
99 | --- | ||
100 | |||
101 | Q: kmemtrace_check reports errors, how do I fix this? Should I worry? | ||
102 | A: This is a bug and should be reported. It can occur for a variety of | ||
103 | reasons: | ||
104 | - possible bugs in relay code | ||
105 | - possible misuse of relay by kmemtrace | ||
106 | - timestamps being collected unorderly | ||
107 | Or you may fix it yourself and send us a patch. | ||
108 | --- | ||
109 | |||
110 | Q: kmemtrace_report shows many errors, how do I fix this? Should I worry? | ||
111 | A: This is a known issue and I'm working on it. These might be true errors | ||
112 | in kernel code, which may have inconsistent behavior (e.g. allocating memory | ||
113 | with kmem_cache_alloc() and freeing it with kfree()). Pekka Enberg pointed | ||
114 | out this behavior may work with SLAB, but may fail with other allocators. | ||
115 | |||
116 | It may also be due to lack of tracing in some unusual allocator functions. | ||
117 | |||
118 | We don't want bug reports regarding this issue yet. | ||
119 | --- | ||
120 | |||
121 | V. See also | ||
122 | =========== | ||
123 | |||
124 | Documentation/kernel-parameters.txt | ||
125 | Documentation/ABI/testing/debugfs-kmemtrace | ||
126 | |||
diff --git a/Documentation/vm/numa_memory_policy.txt b/Documentation/vm/numa_memory_policy.txt index 6aaaeb38730c..be45dbb9d7f2 100644 --- a/Documentation/vm/numa_memory_policy.txt +++ b/Documentation/vm/numa_memory_policy.txt | |||
@@ -8,7 +8,8 @@ The current memory policy support was added to Linux 2.6 around May 2004. This | |||
8 | document attempts to describe the concepts and APIs of the 2.6 memory policy | 8 | document attempts to describe the concepts and APIs of the 2.6 memory policy |
9 | support. | 9 | support. |
10 | 10 | ||
11 | Memory policies should not be confused with cpusets (Documentation/cpusets.txt) | 11 | Memory policies should not be confused with cpusets |
12 | (Documentation/cgroups/cpusets.txt) | ||
12 | which is an administrative mechanism for restricting the nodes from which | 13 | which is an administrative mechanism for restricting the nodes from which |
13 | memory may be allocated by a set of processes. Memory policies are a | 14 | memory may be allocated by a set of processes. Memory policies are a |
14 | programming interface that a NUMA-aware application can take advantage of. When | 15 | programming interface that a NUMA-aware application can take advantage of. When |
diff --git a/Documentation/vm/page_migration b/Documentation/vm/page_migration index d5fdfd34bbaf..6513fe2d90b8 100644 --- a/Documentation/vm/page_migration +++ b/Documentation/vm/page_migration | |||
@@ -37,7 +37,8 @@ locations. | |||
37 | 37 | ||
38 | Larger installations usually partition the system using cpusets into | 38 | Larger installations usually partition the system using cpusets into |
39 | sections of nodes. Paul Jackson has equipped cpusets with the ability to | 39 | sections of nodes. Paul Jackson has equipped cpusets with the ability to |
40 | move pages when a task is moved to another cpuset (See ../cpusets.txt). | 40 | move pages when a task is moved to another cpuset (See |
41 | Documentation/cgroups/cpusets.txt). | ||
41 | Cpusets allows the automation of process locality. If a task is moved to | 42 | Cpusets allows the automation of process locality. If a task is moved to |
42 | a new cpuset then also all its pages are moved with it so that the | 43 | a new cpuset then also all its pages are moved with it so that the |
43 | performance of the process does not sink dramatically. Also the pages | 44 | performance of the process does not sink dramatically. Also the pages |
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt index 7b4596ac4120..e0203662f9e9 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt | |||
@@ -158,7 +158,7 @@ Offset Proto Name Meaning | |||
158 | 0202/4 2.00+ header Magic signature "HdrS" | 158 | 0202/4 2.00+ header Magic signature "HdrS" |
159 | 0206/2 2.00+ version Boot protocol version supported | 159 | 0206/2 2.00+ version Boot protocol version supported |
160 | 0208/4 2.00+ realmode_swtch Boot loader hook (see below) | 160 | 0208/4 2.00+ realmode_swtch Boot loader hook (see below) |
161 | 020C/2 2.00+ start_sys The load-low segment (0x1000) (obsolete) | 161 | 020C/2 2.00+ start_sys_seg The load-low segment (0x1000) (obsolete) |
162 | 020E/2 2.00+ kernel_version Pointer to kernel version string | 162 | 020E/2 2.00+ kernel_version Pointer to kernel version string |
163 | 0210/1 2.00+ type_of_loader Boot loader identifier | 163 | 0210/1 2.00+ type_of_loader Boot loader identifier |
164 | 0211/1 2.00+ loadflags Boot protocol option flags | 164 | 0211/1 2.00+ loadflags Boot protocol option flags |
@@ -170,10 +170,11 @@ Offset Proto Name Meaning | |||
170 | 0224/2 2.01+ heap_end_ptr Free memory after setup end | 170 | 0224/2 2.01+ heap_end_ptr Free memory after setup end |
171 | 0226/2 N/A pad1 Unused | 171 | 0226/2 N/A pad1 Unused |
172 | 0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line | 172 | 0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line |
173 | 022C/4 2.03+ initrd_addr_max Highest legal initrd address | 173 | 022C/4 2.03+ ramdisk_max Highest legal initrd address |
174 | 0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel | 174 | 0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel |
175 | 0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not | 175 | 0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not |
176 | 0235/3 N/A pad2 Unused | 176 | 0235/1 N/A pad2 Unused |
177 | 0236/2 N/A pad3 Unused | ||
177 | 0238/4 2.06+ cmdline_size Maximum size of the kernel command line | 178 | 0238/4 2.06+ cmdline_size Maximum size of the kernel command line |
178 | 023C/4 2.07+ hardware_subarch Hardware subarchitecture | 179 | 023C/4 2.07+ hardware_subarch Hardware subarchitecture |
179 | 0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data | 180 | 0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data |
@@ -299,14 +300,14 @@ Protocol: 2.00+ | |||
299 | e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version | 300 | e.g. 0x0204 for version 2.04, and 0x0a11 for a hypothetical version |
300 | 10.17. | 301 | 10.17. |
301 | 302 | ||
302 | Field name: readmode_swtch | 303 | Field name: realmode_swtch |
303 | Type: modify (optional) | 304 | Type: modify (optional) |
304 | Offset/size: 0x208/4 | 305 | Offset/size: 0x208/4 |
305 | Protocol: 2.00+ | 306 | Protocol: 2.00+ |
306 | 307 | ||
307 | Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.) | 308 | Boot loader hook (see ADVANCED BOOT LOADER HOOKS below.) |
308 | 309 | ||
309 | Field name: start_sys | 310 | Field name: start_sys_seg |
310 | Type: read | 311 | Type: read |
311 | Offset/size: 0x20c/2 | 312 | Offset/size: 0x20c/2 |
312 | Protocol: 2.00+ | 313 | Protocol: 2.00+ |
@@ -468,7 +469,7 @@ Protocol: 2.02+ | |||
468 | zero, the kernel will assume that your boot loader does not support | 469 | zero, the kernel will assume that your boot loader does not support |
469 | the 2.02+ protocol. | 470 | the 2.02+ protocol. |
470 | 471 | ||
471 | Field name: initrd_addr_max | 472 | Field name: ramdisk_max |
472 | Type: read | 473 | Type: read |
473 | Offset/size: 0x22c/4 | 474 | Offset/size: 0x22c/4 |
474 | Protocol: 2.03+ | 475 | Protocol: 2.03+ |
@@ -542,7 +543,10 @@ Protocol: 2.08+ | |||
542 | 543 | ||
543 | The payload may be compressed. The format of both the compressed and | 544 | The payload may be compressed. The format of both the compressed and |
544 | uncompressed data should be determined using the standard magic | 545 | uncompressed data should be determined using the standard magic |
545 | numbers. Currently only gzip compressed ELF is used. | 546 | numbers. The currently supported compression formats are gzip |
547 | (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A) and LZMA | ||
548 | (magic number 5D 00). The uncompressed payload is currently always ELF | ||
549 | (magic number 7F 45 4C 46). | ||
546 | 550 | ||
547 | Field name: payload_length | 551 | Field name: payload_length |
548 | Type: read | 552 | Type: read |
diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt new file mode 100644 index 000000000000..607b1a016064 --- /dev/null +++ b/Documentation/x86/earlyprintk.txt | |||
@@ -0,0 +1,101 @@ | |||
1 | |||
2 | Mini-HOWTO for using the earlyprintk=dbgp boot option with a | ||
3 | USB2 Debug port key and a debug cable, on x86 systems. | ||
4 | |||
5 | You need two computers, the 'USB debug key' special gadget and | ||
6 | and two USB cables, connected like this: | ||
7 | |||
8 | [host/target] <-------> [USB debug key] <-------> [client/console] | ||
9 | |||
10 | 1. There are three specific hardware requirements: | ||
11 | |||
12 | a.) Host/target system needs to have USB debug port capability. | ||
13 | |||
14 | You can check this capability by looking at a 'Debug port' bit in | ||
15 | the lspci -vvv output: | ||
16 | |||
17 | # lspci -vvv | ||
18 | ... | ||
19 | 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) (prog-if 20 [EHCI]) | ||
20 | Subsystem: Lenovo ThinkPad T61 | ||
21 | Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- | ||
22 | Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- | ||
23 | Latency: 0 | ||
24 | Interrupt: pin D routed to IRQ 19 | ||
25 | Region 0: Memory at fe227000 (32-bit, non-prefetchable) [size=1K] | ||
26 | Capabilities: [50] Power Management version 2 | ||
27 | Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+) | ||
28 | Status: D0 PME-Enable- DSel=0 DScale=0 PME+ | ||
29 | Capabilities: [58] Debug port: BAR=1 offset=00a0 | ||
30 | ^^^^^^^^^^^ <==================== [ HERE ] | ||
31 | Kernel driver in use: ehci_hcd | ||
32 | Kernel modules: ehci-hcd | ||
33 | ... | ||
34 | |||
35 | ( If your system does not list a debug port capability then you probably | ||
36 | wont be able to use the USB debug key. ) | ||
37 | |||
38 | b.) You also need a Netchip USB debug cable/key: | ||
39 | |||
40 | http://www.plxtech.com/products/NET2000/NET20DC/default.asp | ||
41 | |||
42 | This is a small blue plastic connector with two USB connections, | ||
43 | it draws power from its USB connections. | ||
44 | |||
45 | c.) Thirdly, you need a second client/console system with a regular USB port. | ||
46 | |||
47 | 2. Software requirements: | ||
48 | |||
49 | a.) On the host/target system: | ||
50 | |||
51 | You need to enable the following kernel config option: | ||
52 | |||
53 | CONFIG_EARLY_PRINTK_DBGP=y | ||
54 | |||
55 | And you need to add the boot command line: "earlyprintk=dbgp". | ||
56 | (If you are using Grub, append it to the 'kernel' line in | ||
57 | /etc/grub.conf) | ||
58 | |||
59 | NOTE: normally earlyprintk console gets turned off once the | ||
60 | regular console is alive - use "earlyprintk=dbgp,keep" to keep | ||
61 | this channel open beyond early bootup. This can be useful for | ||
62 | debugging crashes under Xorg, etc. | ||
63 | |||
64 | b.) On the client/console system: | ||
65 | |||
66 | You should enable the following kernel config option: | ||
67 | |||
68 | CONFIG_USB_SERIAL_DEBUG=y | ||
69 | |||
70 | On the next bootup with the modified kernel you should | ||
71 | get a /dev/ttyUSBx device(s). | ||
72 | |||
73 | Now this channel of kernel messages is ready to be used: start | ||
74 | your favorite terminal emulator (minicom, etc.) and set | ||
75 | it up to use /dev/ttyUSB0 - or use a raw 'cat /dev/ttyUSBx' to | ||
76 | see the raw output. | ||
77 | |||
78 | c.) On Nvidia Southbridge based systems: the kernel will try to probe | ||
79 | and find out which port has debug device connected. | ||
80 | |||
81 | 3. Testing that it works fine: | ||
82 | |||
83 | You can test the output by using earlyprintk=dbgp,keep and provoking | ||
84 | kernel messages on the host/target system. You can provoke a harmless | ||
85 | kernel message by for example doing: | ||
86 | |||
87 | echo h > /proc/sysrq-trigger | ||
88 | |||
89 | On the host/target system you should see this help line in "dmesg" output: | ||
90 | |||
91 | SysRq : HELP : loglevel(0-9) reBoot Crashdump terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z) | ||
92 | |||
93 | On the client/console system do: | ||
94 | |||
95 | cat /dev/ttyUSB0 | ||
96 | |||
97 | And you should see the help line above displayed shortly after you've | ||
98 | provoked it on the host system. | ||
99 | |||
100 | If it does not work then please ask about it on the linux-kernel@vger.kernel.org | ||
101 | mailing list or contact the x86 maintainers. | ||
diff --git a/Documentation/x86/x86_64/fake-numa-for-cpusets b/Documentation/x86/x86_64/fake-numa-for-cpusets index 33bb56655991..0f11d9becb0b 100644 --- a/Documentation/x86/x86_64/fake-numa-for-cpusets +++ b/Documentation/x86/x86_64/fake-numa-for-cpusets | |||
@@ -7,7 +7,8 @@ you can create fake NUMA nodes that represent contiguous chunks of memory and | |||
7 | assign them to cpusets and their attached tasks. This is a way of limiting the | 7 | assign them to cpusets and their attached tasks. This is a way of limiting the |
8 | amount of system memory that are available to a certain class of tasks. | 8 | amount of system memory that are available to a certain class of tasks. |
9 | 9 | ||
10 | For more information on the features of cpusets, see Documentation/cpusets.txt. | 10 | For more information on the features of cpusets, see |
11 | Documentation/cgroups/cpusets.txt. | ||
11 | There are a number of different configurations you can use for your needs. For | 12 | There are a number of different configurations you can use for your needs. For |
12 | more information on the numa=fake command line option and its various ways of | 13 | more information on the numa=fake command line option and its various ways of |
13 | configuring fake nodes, see Documentation/x86/x86_64/boot-options.txt. | 14 | configuring fake nodes, see Documentation/x86/x86_64/boot-options.txt. |
@@ -32,7 +33,7 @@ A machine may be split as follows with "numa=fake=4*512," as reported by dmesg: | |||
32 | On node 3 totalpages: 131072 | 33 | On node 3 totalpages: 131072 |
33 | 34 | ||
34 | Now following the instructions for mounting the cpusets filesystem from | 35 | Now following the instructions for mounting the cpusets filesystem from |
35 | Documentation/cpusets.txt, you can assign fake nodes (i.e. contiguous memory | 36 | Documentation/cgroups/cpusets.txt, you can assign fake nodes (i.e. contiguous memory |
36 | address spaces) to individual cpusets: | 37 | address spaces) to individual cpusets: |
37 | 38 | ||
38 | [root@xroads /]# mkdir exampleset | 39 | [root@xroads /]# mkdir exampleset |