Input: HIL - cleanup coding style
[safe/jmp/linux-2.6] / Documentation / feature-removal-schedule.txt
index b3949cd..c585aa8 100644 (file)
@@ -30,11 +30,23 @@ Who:        Adrian Bunk <bunk@stusta.de>
 ---------------------------
 
 What:  raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
-When:  November 2006
-Why:   Deprecated in favour of the new ioctl-based rawiso interface, which is
-       more efficient.  You should really be using libraw1394 for raw1394
-       access anyway.
-Who:   Jody McIntyre <scjody@modernduck.com>
+When:  June 2007
+Why:   Deprecated in favour of the more efficient and robust rawiso interface.
+       Affected are applications which use the deprecated part of libraw1394
+       (raw1394_iso_write, raw1394_start_iso_write, raw1394_start_iso_rcv,
+       raw1394_stop_iso_rcv) or bypass libraw1394.
+Who:   Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+---------------------------
+
+What:  dv1394 driver (CONFIG_IEEE1394_DV1394)
+When:  June 2007
+Why:   Replaced by raw1394 + userspace libraries, notably libiec61883.  This
+       shift of application support has been indicated on www.linux1394.org
+       and developers' mailinglists for quite some time.  Major applications
+       have been converted, with the exception of ffmpeg and hence xine.
+       Piped output of dvgrab2 is a partial equivalent to dv1394.
+Who:   Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
 
 ---------------------------
 
@@ -70,18 +82,6 @@ Who: Dominik Brodowski <linux@brodo.de>
 
 ---------------------------
 
-What:  ip_queue and ip6_queue (old ipv4-only and ipv6-only netfilter queue)
-When:  December 2005
-Why:   This interface has been obsoleted by the new layer3-independent
-       "nfnetlink_queue".  The Kernel interface is compatible, so the old
-       ip[6]tables "QUEUE" targets still work and will transparently handle
-       all packets into nfnetlink queue number 0.  Userspace users will have
-       to link against API-compatible library on top of libnfnetlink_queue 
-       instead of the current 'libipq'.
-Who:   Harald Welte <laforge@netfilter.org>
-
----------------------------
-
 What:  remove EXPORT_SYMBOL(kernel_thread)
 When:  August 2006
 Files: arch/*/kernel/*_ksyms.c
@@ -135,15 +135,6 @@ Who:       Thomas Gleixner <tglx@linutronix.de>
 
 ---------------------------
 
-What:  I2C interface of the it87 driver
-When:  January 2007
-Why:   The ISA interface is faster and should be always available. The I2C
-       probing is also known to cause trouble in at least one case (see
-       bug #5889.)
-Who:   Jean Delvare <khali@linux-fr.org>
-
----------------------------
-
 What:  Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
        (temporary transition config option provided until then)
        The transition config option will also be removed at the same time.
@@ -179,18 +170,6 @@ Who:       Greg Kroah-Hartman <gregkh@suse.de>
 
 ---------------------------
 
-What:  find_trylock_page
-When:  January 2007
-Why:   The interface no longer has any callers left in the kernel. It
-       is an odd interface (compared with other find_*_page functions), in
-       that it does not take a refcount to the page, only the page lock.
-       It should be replaced with find_get_page or find_lock_page if possible.
-       This feature removal can be reevaluated if users of the interface
-       cannot cleanly use something else.
-Who:   Nick Piggin <npiggin@suse.de>
-
----------------------------
-
 What:  Interrupt only SA_* flags
 When:  Januar 2007
 Why:   The interrupt related SA_* flags are replaced by IRQF_* to move them
@@ -200,33 +179,6 @@ Who:       Thomas Gleixner <tglx@linutronix.de>
 
 ---------------------------
 
-What:  i2c-ite and i2c-algo-ite drivers
-When:  September 2006
-Why:   These drivers never compiled since they were added to the kernel
-       tree 5 years ago. This feature removal can be reevaluated if
-       someone shows interest in the drivers, fixes them and takes over
-       maintenance.
-       http://marc.theaimsgroup.com/?l=linux-mips&m=115040510817448
-Who:   Jean Delvare <khali@linux-fr.org>
-
----------------------------
-
-What:  Bridge netfilter deferred IPv4/IPv6 output hook calling
-When:  January 2007
-Why:   The deferred output hooks are a layering violation causing unusual
-       and broken behaviour on bridge devices. Examples of things they
-       break include QoS classifation using the MARK or CLASSIFY targets,
-       the IPsec policy match and connection tracking with VLANs on a
-       bridge. Their only use is to enable bridge output port filtering
-       within iptables with the physdev match, which can also be done by
-       combining iptables and ebtables using netfilter marks. Until it
-       will get removed the hook deferral is disabled by default and is
-       only enabled when needed.
-
-Who:   Patrick McHardy <kaber@trash.net>
-
----------------------------
-
 What:  PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
 When:  October 2008
 Why:   The stacking of class devices makes these values misleading and
@@ -246,10 +198,139 @@ Who:     Jean Delvare <khali@linux-fr.org>
 
 ---------------------------
 
-What:  ftape
-When:  2.6.20
-Why:   Orphaned for ages.  SMP bugs long unfixed.  Few users left
-       in the world.
+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:  IPv4 only connection tracking/NAT/helpers
+When:  2.6.22
+Why:   The new layer 3 independant connection tracking replaces the old
+       IPv4 only version. After some stabilization of the new code the
+       old one will be removed.
+Who:   Patrick McHardy <kaber@trash.net>
+
+---------------------------
+
+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>
+
+---------------------------
+
+<<<<<<< test:Documentation/feature-removal-schedule.txt
+What:  ACPI hotkey driver (CONFIG_ACPI_HOTKEY)
+When:  2.6.21
+Why:   hotkey.c was an attempt to consolidate multiple drivers that use
+       ACPI to implement hotkeys.  However, hotkeys are not documented
+       in the ACPI specification, so the drivers used undocumented
+       vendor-specific hooks and turned out to be more different than
+       the same.
+
+       Further, the keys and the features supplied by each platform
+       are different, so there will always be a need for
+       platform-specific drivers.
+
+       So the new plan is to delete hotkey.c and instead, work on the
+       platform specific drivers to try to make them look the same
+       to the user when they supply the same features.
+
+       hotkey.c has always depended on CONFIG_EXPERIMENTAL
+
+Who:   Len Brown <len.brown@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:  JFFS (version 1)
+When:  2.6.21
+Why:   Unmaintained for years, superceded by JFFS2 for years.
 Who:   Jeff Garzik <jeff@garzik.org>
 
 ---------------------------
+
+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>
+
+---------------------------