123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315 |
- The following is a list of files and features that are going to be
- removed in the kernel source tree. Every entry should contain what
- exactly is going away, why it is happening, and who is going to be doing
- the work. When the feature is removed from the kernel, it should also
- be removed from this file.
- ---------------------------
- What: /sys/devices/.../power/state
- dev->power.power_state
- dpm_runtime_{suspend,resume)()
- When: July 2007
- Why: Broken design for runtime control over driver power states, confusing
- driver-internal runtime power management with: mechanisms to support
- system-wide sleep state transitions; event codes that distinguish
- different phases of swsusp "sleep" transitions; and userspace policy
- inputs. This framework was never widely used, and most attempts to
- use it were broken. Drivers should instead be exposing domain-specific
- interfaces either to kernel or to userspace.
- Who: Pavel Machek <pavel@suse.cz>
- ---------------------------
- What: RAW driver (CONFIG_RAW_DRIVER)
- When: December 2005
- Why: declared obsolete since kernel 2.6.3
- O_DIRECT can be used instead
- 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: Video4Linux API 1 ioctls and video_decoder.h from Video devices.
- When: December 2006
- Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6
- series. The old API have lots of drawbacks and don't provide enough
- means to work with all video and audio standards. The newer API is
- already available on the main drivers and should be used instead.
- Newer drivers should use v4l_compat_translate_ioctl function to handle
- old calls, replacing to newer ones.
- Decoder iocts are using internally to allow video drivers to
- communicate with video decoders. This should also be improved to allow
- V4L2 calls being translated into compatible internal ioctls.
- Who: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
- ---------------------------
- What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
- When: November 2005
- Files: drivers/pcmcia/: pcmcia_ioctl.c
- Why: With the 16-bit PCMCIA subsystem now behaving (almost) like a
- normal hotpluggable bus, and with it using the default kernel
- infrastructure (hotplug, driver core, sysfs) keeping the PCMCIA
- control ioctl needed by cardmgr and cardctl from pcmcia-cs is
- unnecessary, and makes further cleanups and integration of the
- PCMCIA subsystem into the Linux kernel device driver model more
- difficult. The features provided by cardmgr and cardctl are either
- handled by the kernel itself now or are available in the new
- pcmciautils package available at
- http://kernel.org/pub/linux/utils/kernel/pcmcia/
- Who: Dominik Brodowski <linux@brodo.de>
- ---------------------------
- What: remove EXPORT_SYMBOL(kernel_thread)
- When: August 2006
- Files: arch/*/kernel/*_ksyms.c
- Why: kernel_thread is a low-level implementation detail. Drivers should
- use the <linux/kthread.h> API instead which shields them from
- implementation details and provides a higherlevel interface that
- prevents bugs and code duplication
- Who: Christoph Hellwig <hch@lst.de>
- ---------------------------
- What: CONFIG_FORCED_INLINING
- When: June 2006
- Why: Config option is there to see if gcc is good enough. (in january
- 2006). If it is, the behavior should just be the default. If it's not,
- the option should just go away entirely.
- Who: Arjan van de Ven
- ---------------------------
- What: eepro100 network driver
- When: January 2007
- Why: replaced by the e100 driver
- Who: Adrian Bunk <bunk@stusta.de>
- ---------------------------
- What: drivers depending on OSS_OBSOLETE_DRIVER
- When: options in 2.6.20, code in 2.6.22
- Why: OSS drivers with ALSA replacements
- Who: Adrian Bunk <bunk@stusta.de>
- ---------------------------
- What: pci_module_init(driver)
- When: January 2007
- Why: Is replaced by pci_register_driver(pci_driver).
- Who: Richard Knutsson <ricknu-0@student.ltu.se> and Greg Kroah-Hartman <gregkh@suse.de>
- ---------------------------
- What: Usage of invalid timevals in setitimer
- When: March 2007
- Why: POSIX requires to validate timevals in the setitimer call. This
- was never done by Linux. The invalid (e.g. negative timevals) were
- silently converted to more or less random timeouts and intervals.
- Until the removal a per boot limited number of warnings is printed
- and the timevals are sanitized.
- Who: Thomas Gleixner <tglx@linutronix.de>
- ---------------------------
- 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.
- When: before 2.6.19
- Why: Unused symbols are both increasing the size of the kernel binary
- and are often a sign of "wrong API"
- Who: Arjan van de Ven <arjan@linux.intel.com>
- ---------------------------
- What: mount/umount uevents
- When: February 2007
- Why: These events are not correct, and do not properly let userspace know
- when a file system has been mounted or unmounted. Userspace should
- poll the /proc/mounts file instead to detect this properly.
- Who: Greg Kroah-Hartman <gregkh@suse.de>
- ---------------------------
- What: USB driver API moves to EXPORT_SYMBOL_GPL
- 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
- that operate as fast as the USB bus allows. Because of this, the USB
- subsystem will not be allowing closed source kernel drivers to
- register with it, after this grace period is over. If anyone needs
- any help in converting their closed source drivers over to use the
- userspace filesystems, please contact the
- linux-usb-devel@lists.sourceforge.net mailing list, and the developers
- there will be glad to help you out.
- Who: Greg Kroah-Hartman <gregkh@suse.de>
- ---------------------------
- What: Interrupt only SA_* flags
- When: Januar 2007
- Why: The interrupt related SA_* flags are replaced by IRQF_* to move them
- out of the signal namespace.
- Who: Thomas Gleixner <tglx@linutronix.de>
- ---------------------------
- What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
- 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
- devices have SUBSYTEM and DRIVER as a replacement.
- Who: Kay Sievers <kay.sievers@suse.de>
- ---------------------------
- What: i2c-isa
- When: December 2006
- Why: i2c-isa is a non-sense and doesn't fit in the device driver
- model. Drivers relying on it are better implemented as platform
- drivers.
- Who: Jean Delvare <khali@linux-fr.org>
- ---------------------------
- 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>
- ---------------------------
- 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: Wireless extensions over netlink (CONFIG_NET_WIRELESS_RTNETLINK)
- When: with the merge of wireless-dev, 2.6.22 or later
- Why: The option/code is
- * not enabled on most kernels
- * not required by any userspace tools (except an experimental one,
- and even there only for some parts, others use ioctl)
- * pointless since wext is no longer evolving and the ioctl
- interface needs to be kept
- Who: Johannes Berg <johannes@sipsolutions.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>
- ---------------------------
|