Merge branch 'hwmon-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6
[sfrench/cifs-2.6.git] / Documentation / feature-removal-schedule.txt
index 9364f47c711690e4a262ed0c93c1072ff1be181e..040f437c421bc1bb410ce2253369fa5e1cd33e64 100644 (file)
@@ -29,20 +29,40 @@ Who:        Adrian Bunk <bunk@stusta.de>
 
 ---------------------------
 
-What:  drivers that were depending on OBSOLETE_OSS_DRIVER
-        (config options already removed)
-When:  before 2.6.19
-Why:   OSS drivers with ALSA replacements
-Who:   Adrian Bunk <bunk@stusta.de>
+What:  raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
+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:  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>
+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>
+
+---------------------------
+
+What:  ieee1394 core's unused exports (CONFIG_IEEE1394_EXPORT_FULL_API)
+When:  January 2007
+Why:   There are no projects known to use these exported symbols, except
+       dfg1394 (uses one symbol whose functionality is core-internal now).
+Who:   Stefan Richter <stefanr@s5r6.in-berlin.de>
+
+---------------------------
+
+What:  ieee1394's *_oui sysfs attributes (CONFIG_IEEE1394_OUI_DB)
+When:  January 2007
+Files: drivers/ieee1394/: oui.db, oui2c.sh
+Why:   big size, little value
+Who:   Stefan Richter <stefanr@s5r6.in-berlin.de>
 
 ---------------------------
 
@@ -61,18 +81,6 @@ Who: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
 
 ---------------------------
 
-What:  sys_sysctl
-When:  January 2007
-Why:   The same information is available through /proc/sys and that is the
-       interface user space prefers to use. And there do not appear to be
-       any existing user in user space of sys_sysctl.  The additional
-       maintenance overhead of keeping a set of binary names gets
-       in the way of doing a good job of maintaining this interface.
-
-Who:   Eric Biederman <ebiederm@xmission.com>
-
----------------------------
-
 What:  PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
 When:  November 2005
 Files: drivers/pcmcia/: pcmcia_ioctl.c
@@ -90,18 +98,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
@@ -122,15 +118,6 @@ Who:    Arjan van de Ven
 
 ---------------------------
 
-What:  START_ARRAY ioctl for md
-When:  July 2006
-Files: drivers/md/md.c
-Why:   Not reliable by design - can fail when most needed.
-       Alternatives exist
-Who:   NeilBrown <neilb@suse.de>
-
----------------------------
-
 What:   eepro100 network driver
 When:   January 2007
 Why:    replaced by the e100 driver
@@ -164,15 +151,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.
@@ -193,7 +171,7 @@ Who:        Greg Kroah-Hartman <gregkh@suse.de>
 ---------------------------
 
 What:  USB driver API moves to EXPORT_SYMBOL_GPL
-When:  Febuary 2008
+When:  February 2008
 Files: include/linux/usb.h, drivers/usb/core/driver.c
 Why:   The USB subsystem has changed a lot over time, and it has been
        possible to create userspace USB drivers using usbfs/libusb/gadgetfs
@@ -220,42 +198,6 @@ Who:       Nick Piggin <npiggin@suse.de>
 
 ---------------------------
 
-What:  Support for the Momentum / PMC-Sierra Jaguar ATX evaluation board
-When:  September 2006
-Why:   Does no longer build since quite some time, and was never popular,
-       due to the platform being replaced by successor models.  Apparently
-       no user base left.  It also is one of the last users of
-       WANT_PAGE_VIRTUAL.
-Who:   Ralf Baechle <ralf@linux-mips.org>
-
----------------------------
-
-What:  Support for the Momentum Ocelot, Ocelot 3, Ocelot C and Ocelot G
-When:  September 2006
-Why:   Some do no longer build and apparently there is no user base left
-       for these platforms.
-Who:   Ralf Baechle <ralf@linux-mips.org>
-
----------------------------
-
-What:  Support for MIPS Technologies' Altas and SEAD evaluation board
-When:  September 2006
-Why:   Some do no longer build and apparently there is no user base left
-       for these platforms.  Hardware out of production since several years.
-Who:   Ralf Baechle <ralf@linux-mips.org>
-
----------------------------
-
-What:  Support for the IT8172-based platforms, ITE 8172G and Globespan IVR
-When:  September 2006
-Why:   Code does no longer build since at least 2.6.0,  apparently there is
-       no user base left for these platforms.  Hardware out of production
-       since several years and hardly a trace of the manufacturer left on
-       the net.
-Who:   Ralf Baechle <ralf@linux-mips.org>
-
----------------------------
-
 What:  Interrupt only SA_* flags
 When:  Januar 2007
 Why:   The interrupt related SA_* flags are replaced by IRQF_* to move them
@@ -265,17 +207,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
@@ -292,23 +223,8 @@ Who:       Patrick McHardy <kaber@trash.net>
 
 ---------------------------
 
-What:  frame diverter
-When:  November 2006
-Why:   The frame diverter is included in most distribution kernels, but is
-       broken. It does not correctly handle many things:
-       - IPV6
-       - non-linear skb's
-       - network device RCU on removal
-       - input frames not correctly checked for protocol errors
-       It also adds allocation overhead even if not enabled.
-       It is not clear if anyone is still using it.
-Who:   Stephen Hemminger <shemminger@osdl.org>
-
----------------------------
-
-
 What:  PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
-When:  Oktober 2008
+When:  October 2008
 Why:   The stacking of class devices makes these values misleading and
        inconsistent.
        Class devices should not carry any of these properties, and bus
@@ -325,3 +241,34 @@ Why:       i2c-isa is a non-sense and doesn't fit in the device driver
 Who:   Jean Delvare <khali@linux-fr.org>
 
 ---------------------------
+
+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>
+
+---------------------------