Commit 175833635fe6e96548ccab802ed0b0f25251cbbe
Committed by
Linus Torvalds
1 parent
c31e74c4c3
Exists in
master
and in
4 other branches
pci: add PCI DMA unamp state API to feature-removal-schedule.txt
It was replaced with the DMA unamp state API (which can be used for any bus). Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Showing 1 changed file with 9 additions and 0 deletions Inline Diff
Documentation/feature-removal-schedule.txt
1 | The following is a list of files and features that are going to be | 1 | The following is a list of files and features that are going to be |
2 | removed in the kernel source tree. Every entry should contain what | 2 | removed in the kernel source tree. Every entry should contain what |
3 | exactly is going away, why it is happening, and who is going to be doing | 3 | exactly is going away, why it is happening, and who is going to be doing |
4 | the work. When the feature is removed from the kernel, it should also | 4 | the work. When the feature is removed from the kernel, it should also |
5 | be removed from this file. | 5 | be removed from this file. |
6 | 6 | ||
7 | --------------------------- | 7 | --------------------------- |
8 | 8 | ||
9 | What: PRISM54 | 9 | What: PRISM54 |
10 | When: 2.6.34 | 10 | When: 2.6.34 |
11 | 11 | ||
12 | Why: prism54 FullMAC PCI / Cardbus devices used to be supported only by the | 12 | Why: prism54 FullMAC PCI / Cardbus devices used to be supported only by the |
13 | prism54 wireless driver. After Intersil stopped selling these | 13 | prism54 wireless driver. After Intersil stopped selling these |
14 | devices in preference for the newer more flexible SoftMAC devices | 14 | devices in preference for the newer more flexible SoftMAC devices |
15 | a SoftMAC device driver was required and prism54 did not support | 15 | a SoftMAC device driver was required and prism54 did not support |
16 | them. The p54pci driver now exists and has been present in the kernel for | 16 | them. The p54pci driver now exists and has been present in the kernel for |
17 | a while. This driver supports both SoftMAC devices and FullMAC devices. | 17 | a while. This driver supports both SoftMAC devices and FullMAC devices. |
18 | The main difference between these devices was the amount of memory which | 18 | The main difference between these devices was the amount of memory which |
19 | could be used for the firmware. The SoftMAC devices support a smaller | 19 | could be used for the firmware. The SoftMAC devices support a smaller |
20 | amount of memory. Because of this the SoftMAC firmware fits into FullMAC | 20 | amount of memory. Because of this the SoftMAC firmware fits into FullMAC |
21 | devices's memory. p54pci supports not only PCI / Cardbus but also USB | 21 | devices's memory. p54pci supports not only PCI / Cardbus but also USB |
22 | and SPI. Since p54pci supports all devices prism54 supports | 22 | and SPI. Since p54pci supports all devices prism54 supports |
23 | you will have a conflict. I'm not quite sure how distributions are | 23 | you will have a conflict. I'm not quite sure how distributions are |
24 | handling this conflict right now. prism54 was kept around due to | 24 | handling this conflict right now. prism54 was kept around due to |
25 | claims users may experience issues when using the SoftMAC driver. | 25 | claims users may experience issues when using the SoftMAC driver. |
26 | Time has passed users have not reported issues. If you use prism54 | 26 | Time has passed users have not reported issues. If you use prism54 |
27 | and for whatever reason you cannot use p54pci please let us know! | 27 | and for whatever reason you cannot use p54pci please let us know! |
28 | E-mail us at: linux-wireless@vger.kernel.org | 28 | E-mail us at: linux-wireless@vger.kernel.org |
29 | 29 | ||
30 | For more information see the p54 wiki page: | 30 | For more information see the p54 wiki page: |
31 | 31 | ||
32 | http://wireless.kernel.org/en/users/Drivers/p54 | 32 | http://wireless.kernel.org/en/users/Drivers/p54 |
33 | 33 | ||
34 | Who: Luis R. Rodriguez <lrodriguez@atheros.com> | 34 | Who: Luis R. Rodriguez <lrodriguez@atheros.com> |
35 | 35 | ||
36 | --------------------------- | 36 | --------------------------- |
37 | 37 | ||
38 | What: IRQF_SAMPLE_RANDOM | 38 | What: IRQF_SAMPLE_RANDOM |
39 | Check: IRQF_SAMPLE_RANDOM | 39 | Check: IRQF_SAMPLE_RANDOM |
40 | When: July 2009 | 40 | When: July 2009 |
41 | 41 | ||
42 | Why: Many of IRQF_SAMPLE_RANDOM users are technically bogus as entropy | 42 | Why: Many of IRQF_SAMPLE_RANDOM users are technically bogus as entropy |
43 | sources in the kernel's current entropy model. To resolve this, every | 43 | sources in the kernel's current entropy model. To resolve this, every |
44 | input point to the kernel's entropy pool needs to better document the | 44 | input point to the kernel's entropy pool needs to better document the |
45 | type of entropy source it actually is. This will be replaced with | 45 | type of entropy source it actually is. This will be replaced with |
46 | additional add_*_randomness functions in drivers/char/random.c | 46 | additional add_*_randomness functions in drivers/char/random.c |
47 | 47 | ||
48 | Who: Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com> | 48 | Who: Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com> |
49 | 49 | ||
50 | --------------------------- | 50 | --------------------------- |
51 | 51 | ||
52 | What: Deprecated snapshot ioctls | 52 | What: Deprecated snapshot ioctls |
53 | When: 2.6.36 | 53 | When: 2.6.36 |
54 | 54 | ||
55 | Why: The ioctls in kernel/power/user.c were marked as deprecated long time | 55 | Why: The ioctls in kernel/power/user.c were marked as deprecated long time |
56 | ago. Now they notify users about that so that they need to replace | 56 | ago. Now they notify users about that so that they need to replace |
57 | their userspace. After some more time, remove them completely. | 57 | their userspace. After some more time, remove them completely. |
58 | 58 | ||
59 | Who: Jiri Slaby <jirislaby@gmail.com> | 59 | Who: Jiri Slaby <jirislaby@gmail.com> |
60 | 60 | ||
61 | --------------------------- | 61 | --------------------------- |
62 | 62 | ||
63 | What: The ieee80211_regdom module parameter | 63 | What: The ieee80211_regdom module parameter |
64 | When: March 2010 / desktop catchup | 64 | When: March 2010 / desktop catchup |
65 | 65 | ||
66 | Why: This was inherited by the CONFIG_WIRELESS_OLD_REGULATORY code, | 66 | Why: This was inherited by the CONFIG_WIRELESS_OLD_REGULATORY code, |
67 | and currently serves as an option for users to define an | 67 | and currently serves as an option for users to define an |
68 | ISO / IEC 3166 alpha2 code for the country they are currently | 68 | ISO / IEC 3166 alpha2 code for the country they are currently |
69 | present in. Although there are userspace API replacements for this | 69 | present in. Although there are userspace API replacements for this |
70 | through nl80211 distributions haven't yet caught up with implementing | 70 | through nl80211 distributions haven't yet caught up with implementing |
71 | decent alternatives through standard GUIs. Although available as an | 71 | decent alternatives through standard GUIs. Although available as an |
72 | option through iw or wpa_supplicant its just a matter of time before | 72 | option through iw or wpa_supplicant its just a matter of time before |
73 | distributions pick up good GUI options for this. The ideal solution | 73 | distributions pick up good GUI options for this. The ideal solution |
74 | would actually consist of intelligent designs which would do this for | 74 | would actually consist of intelligent designs which would do this for |
75 | the user automatically even when travelling through different countries. | 75 | the user automatically even when travelling through different countries. |
76 | Until then we leave this module parameter as a compromise. | 76 | Until then we leave this module parameter as a compromise. |
77 | 77 | ||
78 | When userspace improves with reasonable widely-available alternatives for | 78 | When userspace improves with reasonable widely-available alternatives for |
79 | this we will no longer need this module parameter. This entry hopes that | 79 | this we will no longer need this module parameter. This entry hopes that |
80 | by the super-futuristically looking date of "March 2010" we will have | 80 | by the super-futuristically looking date of "March 2010" we will have |
81 | such replacements widely available. | 81 | such replacements widely available. |
82 | 82 | ||
83 | Who: Luis R. Rodriguez <lrodriguez@atheros.com> | 83 | Who: Luis R. Rodriguez <lrodriguez@atheros.com> |
84 | 84 | ||
85 | --------------------------- | 85 | --------------------------- |
86 | 86 | ||
87 | What: dev->power.power_state | 87 | What: dev->power.power_state |
88 | When: July 2007 | 88 | When: July 2007 |
89 | Why: Broken design for runtime control over driver power states, confusing | 89 | Why: Broken design for runtime control over driver power states, confusing |
90 | driver-internal runtime power management with: mechanisms to support | 90 | driver-internal runtime power management with: mechanisms to support |
91 | system-wide sleep state transitions; event codes that distinguish | 91 | system-wide sleep state transitions; event codes that distinguish |
92 | different phases of swsusp "sleep" transitions; and userspace policy | 92 | different phases of swsusp "sleep" transitions; and userspace policy |
93 | inputs. This framework was never widely used, and most attempts to | 93 | inputs. This framework was never widely used, and most attempts to |
94 | use it were broken. Drivers should instead be exposing domain-specific | 94 | use it were broken. Drivers should instead be exposing domain-specific |
95 | interfaces either to kernel or to userspace. | 95 | interfaces either to kernel or to userspace. |
96 | Who: Pavel Machek <pavel@ucw.cz> | 96 | Who: Pavel Machek <pavel@ucw.cz> |
97 | 97 | ||
98 | --------------------------- | 98 | --------------------------- |
99 | 99 | ||
100 | What: Video4Linux API 1 ioctls and from Video devices. | 100 | What: Video4Linux API 1 ioctls and from Video devices. |
101 | When: July 2009 | 101 | When: July 2009 |
102 | Files: include/linux/videodev.h | 102 | Files: include/linux/videodev.h |
103 | Check: include/linux/videodev.h | 103 | Check: include/linux/videodev.h |
104 | Why: V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6 | 104 | Why: V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6 |
105 | series. The old API have lots of drawbacks and don't provide enough | 105 | series. The old API have lots of drawbacks and don't provide enough |
106 | means to work with all video and audio standards. The newer API is | 106 | means to work with all video and audio standards. The newer API is |
107 | already available on the main drivers and should be used instead. | 107 | already available on the main drivers and should be used instead. |
108 | Newer drivers should use v4l_compat_translate_ioctl function to handle | 108 | Newer drivers should use v4l_compat_translate_ioctl function to handle |
109 | old calls, replacing to newer ones. | 109 | old calls, replacing to newer ones. |
110 | Decoder iocts are using internally to allow video drivers to | 110 | Decoder iocts are using internally to allow video drivers to |
111 | communicate with video decoders. This should also be improved to allow | 111 | communicate with video decoders. This should also be improved to allow |
112 | V4L2 calls being translated into compatible internal ioctls. | 112 | V4L2 calls being translated into compatible internal ioctls. |
113 | Compatibility ioctls will be provided, for a while, via | 113 | Compatibility ioctls will be provided, for a while, via |
114 | v4l1-compat module. | 114 | v4l1-compat module. |
115 | Who: Mauro Carvalho Chehab <mchehab@infradead.org> | 115 | Who: Mauro Carvalho Chehab <mchehab@infradead.org> |
116 | 116 | ||
117 | --------------------------- | 117 | --------------------------- |
118 | 118 | ||
119 | What: sys_sysctl | 119 | What: sys_sysctl |
120 | When: September 2010 | 120 | When: September 2010 |
121 | Option: CONFIG_SYSCTL_SYSCALL | 121 | Option: CONFIG_SYSCTL_SYSCALL |
122 | Why: The same information is available in a more convenient from | 122 | Why: The same information is available in a more convenient from |
123 | /proc/sys, and none of the sysctl variables appear to be | 123 | /proc/sys, and none of the sysctl variables appear to be |
124 | important performance wise. | 124 | important performance wise. |
125 | 125 | ||
126 | Binary sysctls are a long standing source of subtle kernel | 126 | Binary sysctls are a long standing source of subtle kernel |
127 | bugs and security issues. | 127 | bugs and security issues. |
128 | 128 | ||
129 | When I looked several months ago all I could find after | 129 | When I looked several months ago all I could find after |
130 | searching several distributions were 5 user space programs and | 130 | searching several distributions were 5 user space programs and |
131 | glibc (which falls back to /proc/sys) using this syscall. | 131 | glibc (which falls back to /proc/sys) using this syscall. |
132 | 132 | ||
133 | The man page for sysctl(2) documents it as unusable for user | 133 | The man page for sysctl(2) documents it as unusable for user |
134 | space programs. | 134 | space programs. |
135 | 135 | ||
136 | sysctl(2) is not generally ABI compatible to a 32bit user | 136 | sysctl(2) is not generally ABI compatible to a 32bit user |
137 | space application on a 64bit and a 32bit kernel. | 137 | space application on a 64bit and a 32bit kernel. |
138 | 138 | ||
139 | For the last several months the policy has been no new binary | 139 | For the last several months the policy has been no new binary |
140 | sysctls and no one has put forward an argument to use them. | 140 | sysctls and no one has put forward an argument to use them. |
141 | 141 | ||
142 | Binary sysctls issues seem to keep happening appearing so | 142 | Binary sysctls issues seem to keep happening appearing so |
143 | properly deprecating them (with a warning to user space) and a | 143 | properly deprecating them (with a warning to user space) and a |
144 | 2 year grace warning period will mean eventually we can kill | 144 | 2 year grace warning period will mean eventually we can kill |
145 | them and end the pain. | 145 | them and end the pain. |
146 | 146 | ||
147 | In the mean time individual binary sysctls can be dealt with | 147 | In the mean time individual binary sysctls can be dealt with |
148 | in a piecewise fashion. | 148 | in a piecewise fashion. |
149 | 149 | ||
150 | Who: Eric Biederman <ebiederm@xmission.com> | 150 | Who: Eric Biederman <ebiederm@xmission.com> |
151 | 151 | ||
152 | --------------------------- | 152 | --------------------------- |
153 | 153 | ||
154 | What: /proc/<pid>/oom_adj | 154 | What: /proc/<pid>/oom_adj |
155 | When: August 2012 | 155 | When: August 2012 |
156 | Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's | 156 | Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's |
157 | badness heuristic used to determine which task to kill when the kernel | 157 | badness heuristic used to determine which task to kill when the kernel |
158 | is out of memory. | 158 | is out of memory. |
159 | 159 | ||
160 | The badness heuristic has since been rewritten since the introduction of | 160 | The badness heuristic has since been rewritten since the introduction of |
161 | this tunable such that its meaning is deprecated. The value was | 161 | this tunable such that its meaning is deprecated. The value was |
162 | implemented as a bitshift on a score generated by the badness() | 162 | implemented as a bitshift on a score generated by the badness() |
163 | function that did not have any precise units of measure. With the | 163 | function that did not have any precise units of measure. With the |
164 | rewrite, the score is given as a proportion of available memory to the | 164 | rewrite, the score is given as a proportion of available memory to the |
165 | task allocating pages, so using a bitshift which grows the score | 165 | task allocating pages, so using a bitshift which grows the score |
166 | exponentially is, thus, impossible to tune with fine granularity. | 166 | exponentially is, thus, impossible to tune with fine granularity. |
167 | 167 | ||
168 | A much more powerful interface, /proc/<pid>/oom_score_adj, was | 168 | A much more powerful interface, /proc/<pid>/oom_score_adj, was |
169 | introduced with the oom killer rewrite that allows users to increase or | 169 | introduced with the oom killer rewrite that allows users to increase or |
170 | decrease the badness() score linearly. This interface will replace | 170 | decrease the badness() score linearly. This interface will replace |
171 | /proc/<pid>/oom_adj. | 171 | /proc/<pid>/oom_adj. |
172 | 172 | ||
173 | A warning will be emitted to the kernel log if an application uses this | 173 | A warning will be emitted to the kernel log if an application uses this |
174 | deprecated interface. After it is printed once, future warnings will be | 174 | deprecated interface. After it is printed once, future warnings will be |
175 | suppressed until the kernel is rebooted. | 175 | suppressed until the kernel is rebooted. |
176 | 176 | ||
177 | --------------------------- | 177 | --------------------------- |
178 | 178 | ||
179 | What: remove EXPORT_SYMBOL(kernel_thread) | 179 | What: remove EXPORT_SYMBOL(kernel_thread) |
180 | When: August 2006 | 180 | When: August 2006 |
181 | Files: arch/*/kernel/*_ksyms.c | 181 | Files: arch/*/kernel/*_ksyms.c |
182 | Check: kernel_thread | 182 | Check: kernel_thread |
183 | Why: kernel_thread is a low-level implementation detail. Drivers should | 183 | Why: kernel_thread is a low-level implementation detail. Drivers should |
184 | use the <linux/kthread.h> API instead which shields them from | 184 | use the <linux/kthread.h> API instead which shields them from |
185 | implementation details and provides a higherlevel interface that | 185 | implementation details and provides a higherlevel interface that |
186 | prevents bugs and code duplication | 186 | prevents bugs and code duplication |
187 | Who: Christoph Hellwig <hch@lst.de> | 187 | Who: Christoph Hellwig <hch@lst.de> |
188 | 188 | ||
189 | --------------------------- | 189 | --------------------------- |
190 | 190 | ||
191 | What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports | 191 | What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports |
192 | (temporary transition config option provided until then) | 192 | (temporary transition config option provided until then) |
193 | The transition config option will also be removed at the same time. | 193 | The transition config option will also be removed at the same time. |
194 | When: before 2.6.19 | 194 | When: before 2.6.19 |
195 | Why: Unused symbols are both increasing the size of the kernel binary | 195 | Why: Unused symbols are both increasing the size of the kernel binary |
196 | and are often a sign of "wrong API" | 196 | and are often a sign of "wrong API" |
197 | Who: Arjan van de Ven <arjan@linux.intel.com> | 197 | Who: Arjan van de Ven <arjan@linux.intel.com> |
198 | 198 | ||
199 | --------------------------- | 199 | --------------------------- |
200 | 200 | ||
201 | What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment | 201 | What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment |
202 | When: October 2008 | 202 | When: October 2008 |
203 | Why: The stacking of class devices makes these values misleading and | 203 | Why: The stacking of class devices makes these values misleading and |
204 | inconsistent. | 204 | inconsistent. |
205 | Class devices should not carry any of these properties, and bus | 205 | Class devices should not carry any of these properties, and bus |
206 | devices have SUBSYTEM and DRIVER as a replacement. | 206 | devices have SUBSYTEM and DRIVER as a replacement. |
207 | Who: Kay Sievers <kay.sievers@suse.de> | 207 | Who: Kay Sievers <kay.sievers@suse.de> |
208 | 208 | ||
209 | --------------------------- | 209 | --------------------------- |
210 | 210 | ||
211 | What: ACPI procfs interface | 211 | What: ACPI procfs interface |
212 | When: July 2008 | 212 | When: July 2008 |
213 | Why: ACPI sysfs conversion should be finished by January 2008. | 213 | Why: ACPI sysfs conversion should be finished by January 2008. |
214 | ACPI procfs interface will be removed in July 2008 so that | 214 | ACPI procfs interface will be removed in July 2008 so that |
215 | there is enough time for the user space to catch up. | 215 | there is enough time for the user space to catch up. |
216 | Who: Zhang Rui <rui.zhang@intel.com> | 216 | Who: Zhang Rui <rui.zhang@intel.com> |
217 | 217 | ||
218 | --------------------------- | 218 | --------------------------- |
219 | 219 | ||
220 | What: /proc/acpi/button | 220 | What: /proc/acpi/button |
221 | When: August 2007 | 221 | When: August 2007 |
222 | Why: /proc/acpi/button has been replaced by events to the input layer | 222 | Why: /proc/acpi/button has been replaced by events to the input layer |
223 | since 2.6.20. | 223 | since 2.6.20. |
224 | Who: Len Brown <len.brown@intel.com> | 224 | Who: Len Brown <len.brown@intel.com> |
225 | 225 | ||
226 | --------------------------- | 226 | --------------------------- |
227 | 227 | ||
228 | What: /proc/acpi/event | 228 | What: /proc/acpi/event |
229 | When: February 2008 | 229 | When: February 2008 |
230 | Why: /proc/acpi/event has been replaced by events via the input layer | 230 | Why: /proc/acpi/event has been replaced by events via the input layer |
231 | and netlink since 2.6.23. | 231 | and netlink since 2.6.23. |
232 | Who: Len Brown <len.brown@intel.com> | 232 | Who: Len Brown <len.brown@intel.com> |
233 | 233 | ||
234 | --------------------------- | 234 | --------------------------- |
235 | 235 | ||
236 | What: i386/x86_64 bzImage symlinks | 236 | What: i386/x86_64 bzImage symlinks |
237 | When: April 2010 | 237 | When: April 2010 |
238 | 238 | ||
239 | Why: The i386/x86_64 merge provides a symlink to the old bzImage | 239 | Why: The i386/x86_64 merge provides a symlink to the old bzImage |
240 | location so not yet updated user space tools, e.g. package | 240 | location so not yet updated user space tools, e.g. package |
241 | scripts, do not break. | 241 | scripts, do not break. |
242 | Who: Thomas Gleixner <tglx@linutronix.de> | 242 | Who: Thomas Gleixner <tglx@linutronix.de> |
243 | 243 | ||
244 | --------------------------- | 244 | --------------------------- |
245 | 245 | ||
246 | What: GPIO autorequest on gpio_direction_{input,output}() in gpiolib | 246 | What: GPIO autorequest on gpio_direction_{input,output}() in gpiolib |
247 | When: February 2010 | 247 | When: February 2010 |
248 | Why: All callers should use explicit gpio_request()/gpio_free(). | 248 | Why: All callers should use explicit gpio_request()/gpio_free(). |
249 | The autorequest mechanism in gpiolib was provided mostly as a | 249 | The autorequest mechanism in gpiolib was provided mostly as a |
250 | migration aid for legacy GPIO interfaces (for SOC based GPIOs). | 250 | migration aid for legacy GPIO interfaces (for SOC based GPIOs). |
251 | Those users have now largely migrated. Platforms implementing | 251 | Those users have now largely migrated. Platforms implementing |
252 | the GPIO interfaces without using gpiolib will see no changes. | 252 | the GPIO interfaces without using gpiolib will see no changes. |
253 | Who: David Brownell <dbrownell@users.sourceforge.net> | 253 | Who: David Brownell <dbrownell@users.sourceforge.net> |
254 | --------------------------- | 254 | --------------------------- |
255 | 255 | ||
256 | What: b43 support for firmware revision < 410 | 256 | What: b43 support for firmware revision < 410 |
257 | When: The schedule was July 2008, but it was decided that we are going to keep the | 257 | When: The schedule was July 2008, but it was decided that we are going to keep the |
258 | code as long as there are no major maintanance headaches. | 258 | code as long as there are no major maintanance headaches. |
259 | So it _could_ be removed _any_ time now, if it conflicts with something new. | 259 | So it _could_ be removed _any_ time now, if it conflicts with something new. |
260 | Why: The support code for the old firmware hurts code readability/maintainability | 260 | Why: The support code for the old firmware hurts code readability/maintainability |
261 | and slightly hurts runtime performance. Bugfixes for the old firmware | 261 | and slightly hurts runtime performance. Bugfixes for the old firmware |
262 | are not provided by Broadcom anymore. | 262 | are not provided by Broadcom anymore. |
263 | Who: Michael Buesch <mb@bu3sch.de> | 263 | Who: Michael Buesch <mb@bu3sch.de> |
264 | 264 | ||
265 | --------------------------- | 265 | --------------------------- |
266 | 266 | ||
267 | What: /sys/o2cb symlink | 267 | What: /sys/o2cb symlink |
268 | When: January 2010 | 268 | When: January 2010 |
269 | Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb | 269 | Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb |
270 | exists as a symlink for backwards compatibility for old versions of | 270 | exists as a symlink for backwards compatibility for old versions of |
271 | ocfs2-tools. 2 years should be sufficient time to phase in new versions | 271 | ocfs2-tools. 2 years should be sufficient time to phase in new versions |
272 | which know to look in /sys/fs/o2cb. | 272 | which know to look in /sys/fs/o2cb. |
273 | Who: ocfs2-devel@oss.oracle.com | 273 | Who: ocfs2-devel@oss.oracle.com |
274 | 274 | ||
275 | --------------------------- | 275 | --------------------------- |
276 | 276 | ||
277 | What: Ability for non root users to shm_get hugetlb pages based on mlock | 277 | What: Ability for non root users to shm_get hugetlb pages based on mlock |
278 | resource limits | 278 | resource limits |
279 | When: 2.6.31 | 279 | When: 2.6.31 |
280 | Why: Non root users need to be part of /proc/sys/vm/hugetlb_shm_group or | 280 | Why: Non root users need to be part of /proc/sys/vm/hugetlb_shm_group or |
281 | have CAP_IPC_LOCK to be able to allocate shm segments backed by | 281 | have CAP_IPC_LOCK to be able to allocate shm segments backed by |
282 | huge pages. The mlock based rlimit check to allow shm hugetlb is | 282 | huge pages. The mlock based rlimit check to allow shm hugetlb is |
283 | inconsistent with mmap based allocations. Hence it is being | 283 | inconsistent with mmap based allocations. Hence it is being |
284 | deprecated. | 284 | deprecated. |
285 | Who: Ravikiran Thirumalai <kiran@scalex86.org> | 285 | Who: Ravikiran Thirumalai <kiran@scalex86.org> |
286 | 286 | ||
287 | --------------------------- | 287 | --------------------------- |
288 | 288 | ||
289 | What: CONFIG_THERMAL_HWMON | 289 | What: CONFIG_THERMAL_HWMON |
290 | When: January 2009 | 290 | When: January 2009 |
291 | Why: This option was introduced just to allow older lm-sensors userspace | 291 | Why: This option was introduced just to allow older lm-sensors userspace |
292 | to keep working over the upgrade to 2.6.26. At the scheduled time of | 292 | to keep working over the upgrade to 2.6.26. At the scheduled time of |
293 | removal fixed lm-sensors (2.x or 3.x) should be readily available. | 293 | removal fixed lm-sensors (2.x or 3.x) should be readily available. |
294 | Who: Rene Herman <rene.herman@gmail.com> | 294 | Who: Rene Herman <rene.herman@gmail.com> |
295 | 295 | ||
296 | --------------------------- | 296 | --------------------------- |
297 | 297 | ||
298 | What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS | 298 | What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS |
299 | (in net/core/net-sysfs.c) | 299 | (in net/core/net-sysfs.c) |
300 | When: After the only user (hal) has seen a release with the patches | 300 | When: After the only user (hal) has seen a release with the patches |
301 | for enough time, probably some time in 2010. | 301 | for enough time, probably some time in 2010. |
302 | Why: Over 1K .text/.data size reduction, data is available in other | 302 | Why: Over 1K .text/.data size reduction, data is available in other |
303 | ways (ioctls) | 303 | ways (ioctls) |
304 | Who: Johannes Berg <johannes@sipsolutions.net> | 304 | Who: Johannes Berg <johannes@sipsolutions.net> |
305 | 305 | ||
306 | --------------------------- | 306 | --------------------------- |
307 | 307 | ||
308 | What: sysfs ui for changing p4-clockmod parameters | 308 | What: sysfs ui for changing p4-clockmod parameters |
309 | When: September 2009 | 309 | When: September 2009 |
310 | Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and | 310 | Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and |
311 | e088e4c9cdb618675874becb91b2fd581ee707e6. | 311 | e088e4c9cdb618675874becb91b2fd581ee707e6. |
312 | Removal is subject to fixing any remaining bugs in ACPI which may | 312 | Removal is subject to fixing any remaining bugs in ACPI which may |
313 | cause the thermal throttling not to happen at the right time. | 313 | cause the thermal throttling not to happen at the right time. |
314 | Who: Dave Jones <davej@redhat.com>, Matthew Garrett <mjg@redhat.com> | 314 | Who: Dave Jones <davej@redhat.com>, Matthew Garrett <mjg@redhat.com> |
315 | 315 | ||
316 | ----------------------------- | 316 | ----------------------------- |
317 | 317 | ||
318 | What: __do_IRQ all in one fits nothing interrupt handler | 318 | What: __do_IRQ all in one fits nothing interrupt handler |
319 | When: 2.6.32 | 319 | When: 2.6.32 |
320 | Why: __do_IRQ was kept for easy migration to the type flow handlers. | 320 | Why: __do_IRQ was kept for easy migration to the type flow handlers. |
321 | More than two years of migration time is enough. | 321 | More than two years of migration time is enough. |
322 | Who: Thomas Gleixner <tglx@linutronix.de> | 322 | Who: Thomas Gleixner <tglx@linutronix.de> |
323 | 323 | ||
324 | ----------------------------- | 324 | ----------------------------- |
325 | 325 | ||
326 | What: fakephp and associated sysfs files in /sys/bus/pci/slots/ | 326 | What: fakephp and associated sysfs files in /sys/bus/pci/slots/ |
327 | When: 2011 | 327 | When: 2011 |
328 | Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to | 328 | Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to |
329 | represent a machine's physical PCI slots. The change in semantics | 329 | represent a machine's physical PCI slots. The change in semantics |
330 | had userspace implications, as the hotplug core no longer allowed | 330 | had userspace implications, as the hotplug core no longer allowed |
331 | drivers to create multiple sysfs files per physical slot (required | 331 | drivers to create multiple sysfs files per physical slot (required |
332 | for multi-function devices, e.g.). fakephp was seen as a developer's | 332 | for multi-function devices, e.g.). fakephp was seen as a developer's |
333 | tool only, and its interface changed. Too late, we learned that | 333 | tool only, and its interface changed. Too late, we learned that |
334 | there were some users of the fakephp interface. | 334 | there were some users of the fakephp interface. |
335 | 335 | ||
336 | In 2.6.30, the original fakephp interface was restored. At the same | 336 | In 2.6.30, the original fakephp interface was restored. At the same |
337 | time, the PCI core gained the ability that fakephp provided, namely | 337 | time, the PCI core gained the ability that fakephp provided, namely |
338 | function-level hot-remove and hot-add. | 338 | function-level hot-remove and hot-add. |
339 | 339 | ||
340 | Since the PCI core now provides the same functionality, exposed in: | 340 | Since the PCI core now provides the same functionality, exposed in: |
341 | 341 | ||
342 | /sys/bus/pci/rescan | 342 | /sys/bus/pci/rescan |
343 | /sys/bus/pci/devices/.../remove | 343 | /sys/bus/pci/devices/.../remove |
344 | /sys/bus/pci/devices/.../rescan | 344 | /sys/bus/pci/devices/.../rescan |
345 | 345 | ||
346 | there is no functional reason to maintain fakephp as well. | 346 | there is no functional reason to maintain fakephp as well. |
347 | 347 | ||
348 | We will keep the existing module so that 'modprobe fakephp' will | 348 | We will keep the existing module so that 'modprobe fakephp' will |
349 | present the old /sys/bus/pci/slots/... interface for compatibility, | 349 | present the old /sys/bus/pci/slots/... interface for compatibility, |
350 | but users are urged to migrate their applications to the API above. | 350 | but users are urged to migrate their applications to the API above. |
351 | 351 | ||
352 | After a reasonable transition period, we will remove the legacy | 352 | After a reasonable transition period, we will remove the legacy |
353 | fakephp interface. | 353 | fakephp interface. |
354 | Who: Alex Chiang <achiang@hp.com> | 354 | Who: Alex Chiang <achiang@hp.com> |
355 | 355 | ||
356 | --------------------------- | 356 | --------------------------- |
357 | 357 | ||
358 | What: CONFIG_RFKILL_INPUT | 358 | What: CONFIG_RFKILL_INPUT |
359 | When: 2.6.33 | 359 | When: 2.6.33 |
360 | Why: Should be implemented in userspace, policy daemon. | 360 | Why: Should be implemented in userspace, policy daemon. |
361 | Who: Johannes Berg <johannes@sipsolutions.net> | 361 | Who: Johannes Berg <johannes@sipsolutions.net> |
362 | 362 | ||
363 | ---------------------------- | 363 | ---------------------------- |
364 | 364 | ||
365 | What: sound-slot/service-* module aliases and related clutters in | 365 | What: sound-slot/service-* module aliases and related clutters in |
366 | sound/sound_core.c | 366 | sound/sound_core.c |
367 | When: August 2010 | 367 | When: August 2010 |
368 | Why: OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR | 368 | Why: OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR |
369 | (14) and requests modules using custom sound-slot/service-* | 369 | (14) and requests modules using custom sound-slot/service-* |
370 | module aliases. The only benefit of doing this is allowing | 370 | module aliases. The only benefit of doing this is allowing |
371 | use of custom module aliases which might as well be considered | 371 | use of custom module aliases which might as well be considered |
372 | a bug at this point. This preemptive claiming prevents | 372 | a bug at this point. This preemptive claiming prevents |
373 | alternative OSS implementations. | 373 | alternative OSS implementations. |
374 | 374 | ||
375 | Till the feature is removed, the kernel will be requesting | 375 | Till the feature is removed, the kernel will be requesting |
376 | both sound-slot/service-* and the standard char-major-* module | 376 | both sound-slot/service-* and the standard char-major-* module |
377 | aliases and allow turning off the pre-claiming selectively via | 377 | aliases and allow turning off the pre-claiming selectively via |
378 | CONFIG_SOUND_OSS_CORE_PRECLAIM and soundcore.preclaim_oss | 378 | CONFIG_SOUND_OSS_CORE_PRECLAIM and soundcore.preclaim_oss |
379 | kernel parameter. | 379 | kernel parameter. |
380 | 380 | ||
381 | After the transition phase is complete, both the custom module | 381 | After the transition phase is complete, both the custom module |
382 | aliases and switches to disable it will go away. This removal | 382 | aliases and switches to disable it will go away. This removal |
383 | will also allow making ALSA OSS emulation independent of | 383 | will also allow making ALSA OSS emulation independent of |
384 | sound_core. The dependency will be broken then too. | 384 | sound_core. The dependency will be broken then too. |
385 | Who: Tejun Heo <tj@kernel.org> | 385 | Who: Tejun Heo <tj@kernel.org> |
386 | 386 | ||
387 | ---------------------------- | 387 | ---------------------------- |
388 | 388 | ||
389 | What: Support for VMware's guest paravirtuliazation technique [VMI] will be | 389 | What: Support for VMware's guest paravirtuliazation technique [VMI] will be |
390 | dropped. | 390 | dropped. |
391 | When: 2.6.37 or earlier. | 391 | When: 2.6.37 or earlier. |
392 | Why: With the recent innovations in CPU hardware acceleration technologies | 392 | Why: With the recent innovations in CPU hardware acceleration technologies |
393 | from Intel and AMD, VMware ran a few experiments to compare these | 393 | from Intel and AMD, VMware ran a few experiments to compare these |
394 | techniques to guest paravirtualization technique on VMware's platform. | 394 | techniques to guest paravirtualization technique on VMware's platform. |
395 | These hardware assisted virtualization techniques have outperformed the | 395 | These hardware assisted virtualization techniques have outperformed the |
396 | performance benefits provided by VMI in most of the workloads. VMware | 396 | performance benefits provided by VMI in most of the workloads. VMware |
397 | expects that these hardware features will be ubiquitous in a couple of | 397 | expects that these hardware features will be ubiquitous in a couple of |
398 | years, as a result, VMware has started a phased retirement of this | 398 | years, as a result, VMware has started a phased retirement of this |
399 | feature from the hypervisor. We will be removing this feature from the | 399 | feature from the hypervisor. We will be removing this feature from the |
400 | Kernel too. Right now we are targeting 2.6.37 but can retire earlier if | 400 | Kernel too. Right now we are targeting 2.6.37 but can retire earlier if |
401 | technical reasons (read opportunity to remove major chunk of pvops) | 401 | technical reasons (read opportunity to remove major chunk of pvops) |
402 | arise. | 402 | arise. |
403 | 403 | ||
404 | Please note that VMI has always been an optimization and non-VMI kernels | 404 | Please note that VMI has always been an optimization and non-VMI kernels |
405 | still work fine on VMware's platform. | 405 | still work fine on VMware's platform. |
406 | Latest versions of VMware's product which support VMI are, | 406 | Latest versions of VMware's product which support VMI are, |
407 | Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence | 407 | Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence |
408 | releases for these products will continue supporting VMI. | 408 | releases for these products will continue supporting VMI. |
409 | 409 | ||
410 | For more details about VMI retirement take a look at this, | 410 | For more details about VMI retirement take a look at this, |
411 | http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html | 411 | http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html |
412 | 412 | ||
413 | Who: Alok N Kataria <akataria@vmware.com> | 413 | Who: Alok N Kataria <akataria@vmware.com> |
414 | 414 | ||
415 | ---------------------------- | 415 | ---------------------------- |
416 | 416 | ||
417 | What: Support for lcd_switch and display_get in asus-laptop driver | 417 | What: Support for lcd_switch and display_get in asus-laptop driver |
418 | When: March 2010 | 418 | When: March 2010 |
419 | Why: These two features use non-standard interfaces. There are the | 419 | Why: These two features use non-standard interfaces. There are the |
420 | only features that really need multiple path to guess what's | 420 | only features that really need multiple path to guess what's |
421 | the right method name on a specific laptop. | 421 | the right method name on a specific laptop. |
422 | 422 | ||
423 | Removing them will allow to remove a lot of code an significantly | 423 | Removing them will allow to remove a lot of code an significantly |
424 | clean the drivers. | 424 | clean the drivers. |
425 | 425 | ||
426 | This will affect the backlight code which won't be able to know | 426 | This will affect the backlight code which won't be able to know |
427 | if the backlight is on or off. The platform display file will also be | 427 | if the backlight is on or off. The platform display file will also be |
428 | write only (like the one in eeepc-laptop). | 428 | write only (like the one in eeepc-laptop). |
429 | 429 | ||
430 | This should'nt affect a lot of user because they usually know | 430 | This should'nt affect a lot of user because they usually know |
431 | when their display is on or off. | 431 | when their display is on or off. |
432 | 432 | ||
433 | Who: Corentin Chary <corentin.chary@gmail.com> | 433 | Who: Corentin Chary <corentin.chary@gmail.com> |
434 | 434 | ||
435 | ---------------------------- | 435 | ---------------------------- |
436 | 436 | ||
437 | What: sysfs-class-rfkill state file | 437 | What: sysfs-class-rfkill state file |
438 | When: Feb 2014 | 438 | When: Feb 2014 |
439 | Files: net/rfkill/core.c | 439 | Files: net/rfkill/core.c |
440 | Why: Documented as obsolete since Feb 2010. This file is limited to 3 | 440 | Why: Documented as obsolete since Feb 2010. This file is limited to 3 |
441 | states while the rfkill drivers can have 4 states. | 441 | states while the rfkill drivers can have 4 states. |
442 | Who: anybody or Florian Mickler <florian@mickler.org> | 442 | Who: anybody or Florian Mickler <florian@mickler.org> |
443 | 443 | ||
444 | ---------------------------- | 444 | ---------------------------- |
445 | 445 | ||
446 | What: sysfs-class-rfkill claim file | 446 | What: sysfs-class-rfkill claim file |
447 | When: Feb 2012 | 447 | When: Feb 2012 |
448 | Files: net/rfkill/core.c | 448 | Files: net/rfkill/core.c |
449 | Why: It is not possible to claim an rfkill driver since 2007. This is | 449 | Why: It is not possible to claim an rfkill driver since 2007. This is |
450 | Documented as obsolete since Feb 2010. | 450 | Documented as obsolete since Feb 2010. |
451 | Who: anybody or Florian Mickler <florian@mickler.org> | 451 | Who: anybody or Florian Mickler <florian@mickler.org> |
452 | 452 | ||
453 | ---------------------------- | 453 | ---------------------------- |
454 | 454 | ||
455 | What: capifs | 455 | What: capifs |
456 | When: February 2011 | 456 | When: February 2011 |
457 | Files: drivers/isdn/capi/capifs.* | 457 | Files: drivers/isdn/capi/capifs.* |
458 | Why: udev fully replaces this special file system that only contains CAPI | 458 | Why: udev fully replaces this special file system that only contains CAPI |
459 | NCCI TTY device nodes. User space (pppdcapiplugin) works without | 459 | NCCI TTY device nodes. User space (pppdcapiplugin) works without |
460 | noticing the difference. | 460 | noticing the difference. |
461 | Who: Jan Kiszka <jan.kiszka@web.de> | 461 | Who: Jan Kiszka <jan.kiszka@web.de> |
462 | 462 | ||
463 | ---------------------------- | 463 | ---------------------------- |
464 | 464 | ||
465 | What: KVM paravirt mmu host support | 465 | What: KVM paravirt mmu host support |
466 | When: January 2011 | 466 | When: January 2011 |
467 | Why: The paravirt mmu host support is slower than non-paravirt mmu, both | 467 | Why: The paravirt mmu host support is slower than non-paravirt mmu, both |
468 | on newer and older hardware. It is already not exposed to the guest, | 468 | on newer and older hardware. It is already not exposed to the guest, |
469 | and kept only for live migration purposes. | 469 | and kept only for live migration purposes. |
470 | Who: Avi Kivity <avi@redhat.com> | 470 | Who: Avi Kivity <avi@redhat.com> |
471 | 471 | ||
472 | ---------------------------- | 472 | ---------------------------- |
473 | 473 | ||
474 | What: iwlwifi 50XX module parameters | 474 | What: iwlwifi 50XX module parameters |
475 | When: 2.6.40 | 475 | When: 2.6.40 |
476 | Why: The "..50" modules parameters were used to configure 5000 series and | 476 | Why: The "..50" modules parameters were used to configure 5000 series and |
477 | up devices; different set of module parameters also available for 4965 | 477 | up devices; different set of module parameters also available for 4965 |
478 | with same functionalities. Consolidate both set into single place | 478 | with same functionalities. Consolidate both set into single place |
479 | in drivers/net/wireless/iwlwifi/iwl-agn.c | 479 | in drivers/net/wireless/iwlwifi/iwl-agn.c |
480 | 480 | ||
481 | Who: Wey-Yi Guy <wey-yi.w.guy@intel.com> | 481 | Who: Wey-Yi Guy <wey-yi.w.guy@intel.com> |
482 | 482 | ||
483 | ---------------------------- | 483 | ---------------------------- |
484 | 484 | ||
485 | What: iwl4965 alias support | 485 | What: iwl4965 alias support |
486 | When: 2.6.40 | 486 | When: 2.6.40 |
487 | Why: Internal alias support has been present in module-init-tools for some | 487 | Why: Internal alias support has been present in module-init-tools for some |
488 | time, the MODULE_ALIAS("iwl4965") boilerplate aliases can be removed | 488 | time, the MODULE_ALIAS("iwl4965") boilerplate aliases can be removed |
489 | with no impact. | 489 | with no impact. |
490 | 490 | ||
491 | Who: Wey-Yi Guy <wey-yi.w.guy@intel.com> | 491 | Who: Wey-Yi Guy <wey-yi.w.guy@intel.com> |
492 | 492 | ||
493 | --------------------------- | 493 | --------------------------- |
494 | 494 | ||
495 | What: xt_NOTRACK | 495 | What: xt_NOTRACK |
496 | Files: net/netfilter/xt_NOTRACK.c | 496 | Files: net/netfilter/xt_NOTRACK.c |
497 | When: April 2011 | 497 | When: April 2011 |
498 | Why: Superseded by xt_CT | 498 | Why: Superseded by xt_CT |
499 | Who: Netfilter developer team <netfilter-devel@vger.kernel.org> | 499 | Who: Netfilter developer team <netfilter-devel@vger.kernel.org> |
500 | 500 | ||
501 | --------------------------- | 501 | --------------------------- |
502 | 502 | ||
503 | What: video4linux /dev/vtx teletext API support | 503 | What: video4linux /dev/vtx teletext API support |
504 | When: 2.6.35 | 504 | When: 2.6.35 |
505 | Files: drivers/media/video/saa5246a.c drivers/media/video/saa5249.c | 505 | Files: drivers/media/video/saa5246a.c drivers/media/video/saa5249.c |
506 | include/linux/videotext.h | 506 | include/linux/videotext.h |
507 | Why: The vtx device nodes have been superseded by vbi device nodes | 507 | Why: The vtx device nodes have been superseded by vbi device nodes |
508 | for many years. No applications exist that use the vtx support. | 508 | for many years. No applications exist that use the vtx support. |
509 | Of the two i2c drivers that actually support this API the saa5249 | 509 | Of the two i2c drivers that actually support this API the saa5249 |
510 | has been impossible to use for a year now and no known hardware | 510 | has been impossible to use for a year now and no known hardware |
511 | that supports this device exists. The saa5246a is theoretically | 511 | that supports this device exists. The saa5246a is theoretically |
512 | supported by the old mxb boards, but it never actually worked. | 512 | supported by the old mxb boards, but it never actually worked. |
513 | 513 | ||
514 | In summary: there is no hardware that can use this API and there | 514 | In summary: there is no hardware that can use this API and there |
515 | are no applications actually implementing this API. | 515 | are no applications actually implementing this API. |
516 | 516 | ||
517 | The vtx support still reserves minors 192-223 and we would really | 517 | The vtx support still reserves minors 192-223 and we would really |
518 | like to reuse those for upcoming new functionality. In the unlikely | 518 | like to reuse those for upcoming new functionality. In the unlikely |
519 | event that new hardware appears that wants to use the functionality | 519 | event that new hardware appears that wants to use the functionality |
520 | provided by the vtx API, then that functionality should be build | 520 | provided by the vtx API, then that functionality should be build |
521 | around the sliced VBI API instead. | 521 | around the sliced VBI API instead. |
522 | Who: Hans Verkuil <hverkuil@xs4all.nl> | 522 | Who: Hans Verkuil <hverkuil@xs4all.nl> |
523 | 523 | ||
524 | ---------------------------- | 524 | ---------------------------- |
525 | 525 | ||
526 | What: IRQF_DISABLED | 526 | What: IRQF_DISABLED |
527 | When: 2.6.36 | 527 | When: 2.6.36 |
528 | Why: The flag is a NOOP as we run interrupt handlers with interrupts disabled | 528 | Why: The flag is a NOOP as we run interrupt handlers with interrupts disabled |
529 | Who: Thomas Gleixner <tglx@linutronix.de> | 529 | Who: Thomas Gleixner <tglx@linutronix.de> |
530 | 530 | ||
531 | ---------------------------- | 531 | ---------------------------- |
532 | 532 | ||
533 | What: old ieee1394 subsystem (CONFIG_IEEE1394) | 533 | What: old ieee1394 subsystem (CONFIG_IEEE1394) |
534 | When: 2.6.37 | 534 | When: 2.6.37 |
535 | Files: drivers/ieee1394/ except init_ohci1394_dma.c | 535 | Files: drivers/ieee1394/ except init_ohci1394_dma.c |
536 | Why: superseded by drivers/firewire/ (CONFIG_FIREWIRE) which offers more | 536 | Why: superseded by drivers/firewire/ (CONFIG_FIREWIRE) which offers more |
537 | features, better performance, and better security, all with smaller | 537 | features, better performance, and better security, all with smaller |
538 | and more modern code base | 538 | and more modern code base |
539 | Who: Stefan Richter <stefanr@s5r6.in-berlin.de> | 539 | Who: Stefan Richter <stefanr@s5r6.in-berlin.de> |
540 | 540 | ||
541 | ---------------------------- | 541 | ---------------------------- |
542 | 542 | ||
543 | What: The acpi_sleep=s4_nonvs command line option | 543 | What: The acpi_sleep=s4_nonvs command line option |
544 | When: 2.6.37 | 544 | When: 2.6.37 |
545 | Files: arch/x86/kernel/acpi/sleep.c | 545 | Files: arch/x86/kernel/acpi/sleep.c |
546 | Why: superseded by acpi_sleep=nonvs | 546 | Why: superseded by acpi_sleep=nonvs |
547 | Who: Rafael J. Wysocki <rjw@sisk.pl> | 547 | Who: Rafael J. Wysocki <rjw@sisk.pl> |
548 | 548 | ||
549 | ---------------------------- | 549 | ---------------------------- |
550 | |||
551 | What: PCI DMA unmap state API | ||
552 | When: August 2012 | ||
553 | Why: PCI DMA unmap state API (include/linux/pci-dma.h) was replaced | ||
554 | with DMA unmap state API (DMA unmap state API can be used for | ||
555 | any bus). | ||
556 | Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> | ||
557 | |||
558 | ---------------------------- | ||
550 | 559 |