diff options
Diffstat (limited to 'Documentation/feature-removal-schedule.txt')
| -rw-r--r-- | Documentation/feature-removal-schedule.txt | 62 |
1 files changed, 62 insertions, 0 deletions
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 30f3c8c9c12a..fc532395d116 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
| @@ -226,6 +226,23 @@ Who: Jean Delvare <khali@linux-fr.org> | |||
| 226 | 226 | ||
| 227 | --------------------------- | 227 | --------------------------- |
| 228 | 228 | ||
| 229 | What: i2c_adapter.dev | ||
| 230 | i2c_adapter.list | ||
| 231 | When: July 2007 | ||
| 232 | Why: Superfluous, given i2c_adapter.class_dev: | ||
| 233 | * The "dev" was a stand-in for the physical device node that legacy | ||
| 234 | drivers would not have; but now it's almost always present. Any | ||
| 235 | remaining legacy drivers must upgrade (they now trigger warnings). | ||
| 236 | * The "list" duplicates class device children. | ||
| 237 | The delay in removing this is so upgraded lm_sensors and libsensors | ||
| 238 | can get deployed. (Removal causes minor changes in the sysfs layout, | ||
| 239 | notably the location of the adapter type name and parenting the i2c | ||
| 240 | client hardware directly from their controller.) | ||
| 241 | Who: Jean Delvare <khali@linux-fr.org>, | ||
| 242 | David Brownell <dbrownell@users.sourceforge.net> | ||
| 243 | |||
| 244 | --------------------------- | ||
| 245 | |||
| 229 | What: IPv4 only connection tracking/NAT/helpers | 246 | What: IPv4 only connection tracking/NAT/helpers |
| 230 | When: 2.6.22 | 247 | When: 2.6.22 |
| 231 | Why: The new layer 3 independant connection tracking replaces the old | 248 | Why: The new layer 3 independant connection tracking replaces the old |
| @@ -256,3 +273,48 @@ Why: Speedstep-centrino driver with ACPI hooks and acpi-cpufreq driver are | |||
| 256 | Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> | 273 | Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> |
| 257 | 274 | ||
| 258 | --------------------------- | 275 | --------------------------- |
| 276 | |||
| 277 | What: ACPI hotkey driver (CONFIG_ACPI_HOTKEY) | ||
| 278 | When: 2.6.21 | ||
| 279 | Why: hotkey.c was an attempt to consolidate multiple drivers that use | ||
| 280 | ACPI to implement hotkeys. However, hotkeys are not documented | ||
| 281 | in the ACPI specification, so the drivers used undocumented | ||
| 282 | vendor-specific hooks and turned out to be more different than | ||
| 283 | the same. | ||
| 284 | |||
| 285 | Further, the keys and the features supplied by each platform | ||
| 286 | are different, so there will always be a need for | ||
| 287 | platform-specific drivers. | ||
| 288 | |||
| 289 | So the new plan is to delete hotkey.c and instead, work on the | ||
| 290 | platform specific drivers to try to make them look the same | ||
| 291 | to the user when they supply the same features. | ||
| 292 | |||
| 293 | hotkey.c has always depended on CONFIG_EXPERIMENTAL | ||
| 294 | |||
| 295 | Who: Len Brown <len.brown@intel.com> | ||
| 296 | |||
| 297 | --------------------------- | ||
| 298 | |||
| 299 | What: /sys/firmware/acpi/namespace | ||
| 300 | When: 2.6.21 | ||
| 301 | Why: The ACPI namespace is effectively the symbol list for | ||
| 302 | the BIOS. The device names are completely arbitrary | ||
| 303 | and have no place being exposed to user-space. | ||
| 304 | |||
| 305 | For those interested in the BIOS ACPI namespace, | ||
| 306 | the BIOS can be extracted and disassembled with acpidump | ||
| 307 | and iasl as documented in the pmtools package here: | ||
| 308 | http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils | ||
| 309 | |||
| 310 | Who: Len Brown <len.brown@intel.com> | ||
| 311 | |||
| 312 | --------------------------- | ||
| 313 | |||
| 314 | What: /proc/acpi/button | ||
| 315 | When: August 2007 | ||
| 316 | Why: /proc/acpi/button has been replaced by events to the input layer | ||
| 317 | since 2.6.20. | ||
| 318 | Who: Len Brown <len.brown@intel.com> | ||
| 319 | |||
| 320 | --------------------------- | ||
