+What: i2c_adapter.dev
+ i2c_adapter.list
+When: July 2007
+Why: Superfluous, given i2c_adapter.class_dev:
+ * The "dev" was a stand-in for the physical device node that legacy
+ drivers would not have; but now it's almost always present. Any
+ remaining legacy drivers must upgrade (they now trigger warnings).
+ * The "list" duplicates class device children.
+ The delay in removing this is so upgraded lm_sensors and libsensors
+ can get deployed. (Removal causes minor changes in the sysfs layout,
+ notably the location of the adapter type name and parenting the i2c
+ client hardware directly from their controller.)
+Who: Jean Delvare <khali@linux-fr.org>,
+ David Brownell <dbrownell@users.sourceforge.net>
+
+---------------------------
+
+What: drivers depending on OBSOLETE_OSS
+When: options in 2.6.22, code in 2.6.24
+Why: OSS drivers with ALSA replacements
+Who: Adrian Bunk <bunk@stusta.de>
+
+---------------------------
+
+What: ACPI hooks (X86_SPEEDSTEP_CENTRINO_ACPI) in speedstep-centrino driver
+When: December 2006
+Why: Speedstep-centrino driver with ACPI hooks and acpi-cpufreq driver are
+ functionally very much similar. They talk to ACPI in same way. Only
+ difference between them is the way they do frequency transitions.
+ One uses MSRs and the other one uses IO ports. Functionaliy of
+ speedstep_centrino with ACPI hooks is now merged into acpi-cpufreq.
+ That means one common driver will support all Intel Enhanced Speedstep
+ capable CPUs. That means less confusion over name of
+ speedstep-centrino driver (with that driver supposed to be used on
+ non-centrino platforms). That means less duplication of code and
+ less maintenance effort and no possibility of these two drivers
+ going out of sync.
+ Current users of speedstep_centrino with ACPI hooks are requested to
+ switch over to acpi-cpufreq driver. speedstep-centrino will continue
+ to work using older non-ACPI static table based scheme even after this
+ date.
+
+Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
+
+---------------------------
+
+What: /sys/firmware/acpi/namespace
+When: 2.6.21
+Why: The ACPI namespace is effectively the symbol list for
+ the BIOS. The device names are completely arbitrary
+ and have no place being exposed to user-space.
+
+ For those interested in the BIOS ACPI namespace,
+ the BIOS can be extracted and disassembled with acpidump
+ and iasl as documented in the pmtools package here:
+ http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils
+Who: Len Brown <len.brown@intel.com>
+
+---------------------------
+
+What: ACPI procfs interface
+When: July 2007
+Why: After ACPI sysfs conversion, ACPI attributes will be duplicated
+ in sysfs and the ACPI procfs interface should be removed.
+Who: Zhang Rui <rui.zhang@intel.com>
+
+---------------------------
+
+What: /proc/acpi/button
+When: August 2007
+Why: /proc/acpi/button has been replaced by events to the input layer
+ since 2.6.20.
+Who: Len Brown <len.brown@intel.com>
+
+---------------------------
+
+What: sk98lin network driver
+When: July 2007
+Why: In kernel tree version of driver is unmaintained. Sk98lin driver
+ replaced by the skge driver.
+Who: Stephen Hemminger <shemminger@osdl.org>
+
+---------------------------
+
+What: Compaq touchscreen device emulation
+When: Oct 2007
+Files: drivers/input/tsdev.c
+Why: The code says it was obsolete when it was written in 2001.
+ tslib is a userspace library which does anything tsdev can do and
+ much more besides in userspace where this code belongs. There is no
+ longer any need for tsdev and applications should have converted to
+ use tslib by now.
+ The name "tsdev" is also extremely confusing and lots of people have
+ it loaded when they don't need/use it.
+Who: Richard Purdie <rpurdie@rpsys.net>
+
+---------------------------
+
+What: i8xx_tco watchdog driver
+When: in 2.6.22
+Why: the i8xx_tco watchdog driver has been replaced by the iTCO_wdt
+ watchdog driver.
+Who: Wim Van Sebroeck <wim@iguana.be>
+
+---------------------------
+
+What: Multipath cached routing support in ipv4
+When: in 2.6.23
+Why: Code was merged, then submitter immediately disappeared leaving
+ us with no maintainer and lots of bugs. The code should not have
+ been merged in the first place, and many aspects of it's
+ implementation are blocking more critical core networking
+ development. It's marked EXPERIMENTAL and no distribution
+ enables it because it cause obscure crashes due to unfixable bugs
+ (interfaces don't return errors so memory allocation can't be
+ handled, calling contexts of these interfaces make handling
+ errors impossible too because they get called after we've
+ totally commited to creating a route object, for example).
+ This problem has existed for years and no forward progress
+ has ever been made, and nobody steps up to try and salvage
+ this code, so we're going to finally just get rid of it.
+Who: David S. Miller <davem@davemloft.net>