X-Git-Url: http://git.agner.ch/gitweb/?a=blobdiff_plain;f=Documentation%2Ffeature-removal-schedule.txt;h=2dc5e5da8f88c69360e9f5e85b38861cd932f308;hb=f2aca47dc3c2d0c2d5dbd972558557e74232bbce;hp=226ecf2ffd568158a2927b24e27e21bde00b6d30;hpb=f1ff0fdc353ca00ff43b7b039944b8070da22242;p=linux-drm-fsl-dcu.git diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 226ecf2ffd56..2dc5e5da8f88 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -30,11 +30,39 @@ Who: Adrian Bunk --------------------------- 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 +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 , Stefan Richter + +--------------------------- + +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 , Stefan Richter + +--------------------------- + +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 + +--------------------------- + +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 --------------------------- @@ -123,15 +151,6 @@ Who: Thomas Gleixner --------------------------- -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 - ---------------------------- - 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. @@ -188,33 +207,6 @@ Who: Thomas Gleixner --------------------------- -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 - ---------------------------- - -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 - ---------------------------- - What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment When: October 2008 Why: The stacking of class devices makes these values misleading and @@ -234,6 +226,23 @@ Who: Jean Delvare --------------------------- +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 , + David Brownell + +--------------------------- + What: IPv4 only connection tracking/NAT/helpers When: 2.6.22 Why: The new layer 3 independant connection tracking replaces the old @@ -242,3 +251,92 @@ Why: The new layer 3 independant connection tracking replaces the old Who: Patrick McHardy --------------------------- + +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 + +--------------------------- + +<<<<<<< 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 + +--------------------------- + +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 + +--------------------------- + +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 + +--------------------------- + +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 + +--------------------------- + +What: JFFS (version 1) +When: 2.6.21 +Why: Unmaintained for years, superceded by JFFS2 for years. +Who: Jeff Garzik + +--------------------------- + +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 +