123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591 |
- 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: PRISM54
- When: 2.6.34
- Why: prism54 FullMAC PCI / Cardbus devices used to be supported only by the
- prism54 wireless driver. After Intersil stopped selling these
- devices in preference for the newer more flexible SoftMAC devices
- a SoftMAC device driver was required and prism54 did not support
- them. The p54pci driver now exists and has been present in the kernel for
- a while. This driver supports both SoftMAC devices and FullMAC devices.
- The main difference between these devices was the amount of memory which
- could be used for the firmware. The SoftMAC devices support a smaller
- amount of memory. Because of this the SoftMAC firmware fits into FullMAC
- devices's memory. p54pci supports not only PCI / Cardbus but also USB
- and SPI. Since p54pci supports all devices prism54 supports
- you will have a conflict. I'm not quite sure how distributions are
- handling this conflict right now. prism54 was kept around due to
- claims users may experience issues when using the SoftMAC driver.
- Time has passed users have not reported issues. If you use prism54
- and for whatever reason you cannot use p54pci please let us know!
- E-mail us at: linux-wireless@vger.kernel.org
- For more information see the p54 wiki page:
- http://wireless.kernel.org/en/users/Drivers/p54
- Who: Luis R. Rodriguez <lrodriguez@atheros.com>
- ---------------------------
- What: IRQF_SAMPLE_RANDOM
- Check: IRQF_SAMPLE_RANDOM
- When: July 2009
- Why: Many of IRQF_SAMPLE_RANDOM users are technically bogus as entropy
- sources in the kernel's current entropy model. To resolve this, every
- input point to the kernel's entropy pool needs to better document the
- type of entropy source it actually is. This will be replaced with
- additional add_*_randomness functions in drivers/char/random.c
- Who: Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com>
- ---------------------------
- What: Deprecated snapshot ioctls
- When: 2.6.36
- Why: The ioctls in kernel/power/user.c were marked as deprecated long time
- ago. Now they notify users about that so that they need to replace
- their userspace. After some more time, remove them completely.
- Who: Jiri Slaby <jirislaby@gmail.com>
- ---------------------------
- What: The ieee80211_regdom module parameter
- When: March 2010 / desktop catchup
- Why: This was inherited by the CONFIG_WIRELESS_OLD_REGULATORY code,
- and currently serves as an option for users to define an
- ISO / IEC 3166 alpha2 code for the country they are currently
- present in. Although there are userspace API replacements for this
- through nl80211 distributions haven't yet caught up with implementing
- decent alternatives through standard GUIs. Although available as an
- option through iw or wpa_supplicant its just a matter of time before
- distributions pick up good GUI options for this. The ideal solution
- would actually consist of intelligent designs which would do this for
- the user automatically even when travelling through different countries.
- Until then we leave this module parameter as a compromise.
- When userspace improves with reasonable widely-available alternatives for
- this we will no longer need this module parameter. This entry hopes that
- by the super-futuristically looking date of "March 2010" we will have
- such replacements widely available.
- Who: Luis R. Rodriguez <lrodriguez@atheros.com>
- ---------------------------
- What: dev->power.power_state
- 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@ucw.cz>
- ---------------------------
- What: sys_sysctl
- When: September 2010
- Option: CONFIG_SYSCTL_SYSCALL
- Why: The same information is available in a more convenient from
- /proc/sys, and none of the sysctl variables appear to be
- important performance wise.
- Binary sysctls are a long standing source of subtle kernel
- bugs and security issues.
- When I looked several months ago all I could find after
- searching several distributions were 5 user space programs and
- glibc (which falls back to /proc/sys) using this syscall.
- The man page for sysctl(2) documents it as unusable for user
- space programs.
- sysctl(2) is not generally ABI compatible to a 32bit user
- space application on a 64bit and a 32bit kernel.
- For the last several months the policy has been no new binary
- sysctls and no one has put forward an argument to use them.
- Binary sysctls issues seem to keep happening appearing so
- properly deprecating them (with a warning to user space) and a
- 2 year grace warning period will mean eventually we can kill
- them and end the pain.
- In the mean time individual binary sysctls can be dealt with
- in a piecewise fashion.
- Who: Eric Biederman <ebiederm@xmission.com>
- ---------------------------
- What: /proc/<pid>/oom_adj
- When: August 2012
- Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
- badness heuristic used to determine which task to kill when the kernel
- is out of memory.
- The badness heuristic has since been rewritten since the introduction of
- this tunable such that its meaning is deprecated. The value was
- implemented as a bitshift on a score generated by the badness()
- function that did not have any precise units of measure. With the
- rewrite, the score is given as a proportion of available memory to the
- task allocating pages, so using a bitshift which grows the score
- exponentially is, thus, impossible to tune with fine granularity.
- A much more powerful interface, /proc/<pid>/oom_score_adj, was
- introduced with the oom killer rewrite that allows users to increase or
- decrease the badness() score linearly. This interface will replace
- /proc/<pid>/oom_adj.
- A warning will be emitted to the kernel log if an application uses this
- deprecated interface. After it is printed once, future warnings will be
- suppressed until the kernel is rebooted.
- ---------------------------
- What: CS5535/CS5536 obsolete GPIO driver
- When: June 2011
- Files: drivers/staging/cs5535_gpio/*
- Check: drivers/staging/cs5535_gpio/cs5535_gpio.c
- Why: A newer driver replaces this; it is drivers/gpio/cs5535-gpio.c, and
- integrates with the Linux GPIO subsystem. The old driver has been
- moved to staging, and will be removed altogether around 2.6.40.
- Please test the new driver, and ensure that the functionality you
- need and any bugfixes from the old driver are available in the new
- one.
- Who: Andres Salomon <dilinger@queued.net>
- --------------------------
- What: remove EXPORT_SYMBOL(kernel_thread)
- When: August 2006
- Files: arch/*/kernel/*_ksyms.c
- Check: kernel_thread
- 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: 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: 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: ACPI procfs interface
- When: July 2008
- Why: ACPI sysfs conversion should be finished by January 2008.
- ACPI procfs interface will be removed in July 2008 so that
- there is enough time for the user space to catch up.
- Who: Zhang Rui <rui.zhang@intel.com>
- ---------------------------
- What: CONFIG_ACPI_PROCFS_POWER
- When: 2.6.39
- Why: sysfs I/F for ACPI power devices, including AC and Battery,
- has been working in upstream kenrel since 2.6.24, Sep 2007.
- In 2.6.37, we make the sysfs I/F always built in and this option
- disabled by default.
- Remove this option and the ACPI power procfs interface in 2.6.39.
- Who: Zhang Rui <rui.zhang@intel.com>
- ---------------------------
- What: /proc/acpi/event
- When: February 2008
- Why: /proc/acpi/event has been replaced by events via the input layer
- and netlink since 2.6.23.
- Who: Len Brown <len.brown@intel.com>
- ---------------------------
- What: i386/x86_64 bzImage symlinks
- When: April 2010
- Why: The i386/x86_64 merge provides a symlink to the old bzImage
- location so not yet updated user space tools, e.g. package
- scripts, do not break.
- Who: Thomas Gleixner <tglx@linutronix.de>
- ---------------------------
- What: GPIO autorequest on gpio_direction_{input,output}() in gpiolib
- When: February 2010
- Why: All callers should use explicit gpio_request()/gpio_free().
- The autorequest mechanism in gpiolib was provided mostly as a
- migration aid for legacy GPIO interfaces (for SOC based GPIOs).
- Those users have now largely migrated. Platforms implementing
- the GPIO interfaces without using gpiolib will see no changes.
- Who: David Brownell <dbrownell@users.sourceforge.net>
- ---------------------------
- What: b43 support for firmware revision < 410
- When: The schedule was July 2008, but it was decided that we are going to keep the
- code as long as there are no major maintanance headaches.
- So it _could_ be removed _any_ time now, if it conflicts with something new.
- Why: The support code for the old firmware hurts code readability/maintainability
- and slightly hurts runtime performance. Bugfixes for the old firmware
- are not provided by Broadcom anymore.
- Who: Michael Buesch <mb@bu3sch.de>
- ---------------------------
- What: /sys/o2cb symlink
- When: January 2010
- Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb
- exists as a symlink for backwards compatibility for old versions of
- ocfs2-tools. 2 years should be sufficient time to phase in new versions
- which know to look in /sys/fs/o2cb.
- Who: ocfs2-devel@oss.oracle.com
- ---------------------------
- What: Ability for non root users to shm_get hugetlb pages based on mlock
- resource limits
- When: 2.6.31
- Why: Non root users need to be part of /proc/sys/vm/hugetlb_shm_group or
- have CAP_IPC_LOCK to be able to allocate shm segments backed by
- huge pages. The mlock based rlimit check to allow shm hugetlb is
- inconsistent with mmap based allocations. Hence it is being
- deprecated.
- Who: Ravikiran Thirumalai <kiran@scalex86.org>
- ---------------------------
- What: CONFIG_THERMAL_HWMON
- When: January 2009
- Why: This option was introduced just to allow older lm-sensors userspace
- to keep working over the upgrade to 2.6.26. At the scheduled time of
- removal fixed lm-sensors (2.x or 3.x) should be readily available.
- Who: Rene Herman <rene.herman@gmail.com>
- ---------------------------
- What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS
- (in net/core/net-sysfs.c)
- When: After the only user (hal) has seen a release with the patches
- for enough time, probably some time in 2010.
- Why: Over 1K .text/.data size reduction, data is available in other
- ways (ioctls)
- Who: Johannes Berg <johannes@sipsolutions.net>
- ---------------------------
- What: sysfs ui for changing p4-clockmod parameters
- When: September 2009
- Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and
- e088e4c9cdb618675874becb91b2fd581ee707e6.
- Removal is subject to fixing any remaining bugs in ACPI which may
- cause the thermal throttling not to happen at the right time.
- Who: Dave Jones <davej@redhat.com>, Matthew Garrett <mjg@redhat.com>
- -----------------------------
- What: fakephp and associated sysfs files in /sys/bus/pci/slots/
- When: 2011
- Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to
- represent a machine's physical PCI slots. The change in semantics
- had userspace implications, as the hotplug core no longer allowed
- drivers to create multiple sysfs files per physical slot (required
- for multi-function devices, e.g.). fakephp was seen as a developer's
- tool only, and its interface changed. Too late, we learned that
- there were some users of the fakephp interface.
- In 2.6.30, the original fakephp interface was restored. At the same
- time, the PCI core gained the ability that fakephp provided, namely
- function-level hot-remove and hot-add.
- Since the PCI core now provides the same functionality, exposed in:
- /sys/bus/pci/rescan
- /sys/bus/pci/devices/.../remove
- /sys/bus/pci/devices/.../rescan
- there is no functional reason to maintain fakephp as well.
- We will keep the existing module so that 'modprobe fakephp' will
- present the old /sys/bus/pci/slots/... interface for compatibility,
- but users are urged to migrate their applications to the API above.
- After a reasonable transition period, we will remove the legacy
- fakephp interface.
- Who: Alex Chiang <achiang@hp.com>
- ---------------------------
- What: CONFIG_RFKILL_INPUT
- When: 2.6.33
- Why: Should be implemented in userspace, policy daemon.
- Who: Johannes Berg <johannes@sipsolutions.net>
- ----------------------------
- What: sound-slot/service-* module aliases and related clutters in
- sound/sound_core.c
- When: August 2010
- Why: OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR
- (14) and requests modules using custom sound-slot/service-*
- module aliases. The only benefit of doing this is allowing
- use of custom module aliases which might as well be considered
- a bug at this point. This preemptive claiming prevents
- alternative OSS implementations.
- Till the feature is removed, the kernel will be requesting
- both sound-slot/service-* and the standard char-major-* module
- aliases and allow turning off the pre-claiming selectively via
- CONFIG_SOUND_OSS_CORE_PRECLAIM and soundcore.preclaim_oss
- kernel parameter.
- After the transition phase is complete, both the custom module
- aliases and switches to disable it will go away. This removal
- will also allow making ALSA OSS emulation independent of
- sound_core. The dependency will be broken then too.
- Who: Tejun Heo <tj@kernel.org>
- ----------------------------
- What: Support for lcd_switch and display_get in asus-laptop driver
- When: March 2010
- Why: These two features use non-standard interfaces. There are the
- only features that really need multiple path to guess what's
- the right method name on a specific laptop.
- Removing them will allow to remove a lot of code an significantly
- clean the drivers.
- This will affect the backlight code which won't be able to know
- if the backlight is on or off. The platform display file will also be
- write only (like the one in eeepc-laptop).
- This should'nt affect a lot of user because they usually know
- when their display is on or off.
- Who: Corentin Chary <corentin.chary@gmail.com>
- ----------------------------
- What: sysfs-class-rfkill state file
- When: Feb 2014
- Files: net/rfkill/core.c
- Why: Documented as obsolete since Feb 2010. This file is limited to 3
- states while the rfkill drivers can have 4 states.
- Who: anybody or Florian Mickler <florian@mickler.org>
- ----------------------------
- What: sysfs-class-rfkill claim file
- When: Feb 2012
- Files: net/rfkill/core.c
- Why: It is not possible to claim an rfkill driver since 2007. This is
- Documented as obsolete since Feb 2010.
- Who: anybody or Florian Mickler <florian@mickler.org>
- ----------------------------
- What: capifs
- When: February 2011
- Files: drivers/isdn/capi/capifs.*
- Why: udev fully replaces this special file system that only contains CAPI
- NCCI TTY device nodes. User space (pppdcapiplugin) works without
- noticing the difference.
- Who: Jan Kiszka <jan.kiszka@web.de>
- ----------------------------
- What: KVM paravirt mmu host support
- When: January 2011
- Why: The paravirt mmu host support is slower than non-paravirt mmu, both
- on newer and older hardware. It is already not exposed to the guest,
- and kept only for live migration purposes.
- Who: Avi Kivity <avi@redhat.com>
- ----------------------------
- What: iwlwifi 50XX module parameters
- When: 2.6.40
- Why: The "..50" modules parameters were used to configure 5000 series and
- up devices; different set of module parameters also available for 4965
- with same functionalities. Consolidate both set into single place
- in drivers/net/wireless/iwlwifi/iwl-agn.c
- Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
- ----------------------------
- What: iwl4965 alias support
- When: 2.6.40
- Why: Internal alias support has been present in module-init-tools for some
- time, the MODULE_ALIAS("iwl4965") boilerplate aliases can be removed
- with no impact.
- Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
- ---------------------------
- What: xt_NOTRACK
- Files: net/netfilter/xt_NOTRACK.c
- When: April 2011
- Why: Superseded by xt_CT
- Who: Netfilter developer team <netfilter-devel@vger.kernel.org>
- ----------------------------
- What: IRQF_DISABLED
- When: 2.6.36
- Why: The flag is a NOOP as we run interrupt handlers with interrupts disabled
- Who: Thomas Gleixner <tglx@linutronix.de>
- ----------------------------
- What: The acpi_sleep=s4_nonvs command line option
- When: 2.6.37
- Files: arch/x86/kernel/acpi/sleep.c
- Why: superseded by acpi_sleep=nonvs
- Who: Rafael J. Wysocki <rjw@sisk.pl>
- ----------------------------
- What: PCI DMA unmap state API
- When: August 2012
- Why: PCI DMA unmap state API (include/linux/pci-dma.h) was replaced
- with DMA unmap state API (DMA unmap state API can be used for
- any bus).
- Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
- ----------------------------
- What: DMA_xxBIT_MASK macros
- When: Jun 2011
- Why: DMA_xxBIT_MASK macros were replaced with DMA_BIT_MASK() macros.
- Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
- ----------------------------
- What: namespace cgroup (ns_cgroup)
- When: 2.6.38
- Why: The ns_cgroup leads to some problems:
- * cgroup creation is out-of-control
- * cgroup name can conflict when pids are looping
- * it is not possible to have a single process handling
- a lot of namespaces without falling in a exponential creation time
- * we may want to create a namespace without creating a cgroup
- The ns_cgroup is replaced by a compatibility flag 'clone_children',
- where a newly created cgroup will copy the parent cgroup values.
- The userspace has to manually create a cgroup and add a task to
- the 'tasks' file.
- Who: Daniel Lezcano <daniel.lezcano@free.fr>
- ----------------------------
- What: iwlwifi disable_hw_scan module parameters
- When: 2.6.40
- Why: Hareware scan is the prefer method for iwlwifi devices for
- scanning operation. Remove software scan support for all the
- iwlwifi devices.
- Who: Wey-Yi Guy <wey-yi.w.guy@intel.com>
- ----------------------------
- What: access to nfsd auth cache through sys_nfsservctl or '.' files
- in the 'nfsd' filesystem.
- When: 2.6.40
- Why: This is a legacy interface which have been replaced by a more
- dynamic cache. Continuing to maintain this interface is an
- unnecessary burden.
- Who: NeilBrown <neilb@suse.de>
- ----------------------------
- What: cancel_rearming_delayed_work[queue]()
- When: 2.6.39
- Why: The functions have been superceded by cancel_delayed_work_sync()
- quite some time ago. The conversion is trivial and there is no
- in-kernel user left.
- Who: Tejun Heo <tj@kernel.org>
- ----------------------------
- What: Legacy, non-standard chassis intrusion detection interface.
- When: June 2011
- Why: The adm9240, w83792d and w83793 hardware monitoring drivers have
- legacy interfaces for chassis intrusion detection. A standard
- interface has been added to each driver, so the legacy interface
- can be removed.
- Who: Jean Delvare <khali@linux-fr.org>
- ----------------------------
- What: xt_connlimit rev 0
- When: 2012
- Who: Jan Engelhardt <jengelh@medozas.de>
- Files: net/netfilter/xt_connlimit.c
- ----------------------------
- What: noswapaccount kernel command line parameter
- When: 2.6.40
- Why: The original implementation of memsw feature enabled by
- CONFIG_CGROUP_MEM_RES_CTLR_SWAP could be disabled by the noswapaccount
- kernel parameter (introduced in 2.6.29-rc1). Later on, this decision
- turned out to be not ideal because we cannot have the feature compiled
- in and disabled by default and let only interested to enable it
- (e.g. general distribution kernels might need it). Therefore we have
- added swapaccount[=0|1] parameter (introduced in 2.6.37) which provides
- the both possibilities. If we remove noswapaccount we will have
- less command line parameters with the same functionality and we
- can also cleanup the parameter handling a bit ().
- Who: Michal Hocko <mhocko@suse.cz>
- ----------------------------
- What: ipt_addrtype match include file
- When: 2012
- Why: superseded by xt_addrtype
- Who: Florian Westphal <fw@strlen.de>
- Files: include/linux/netfilter_ipv4/ipt_addrtype.h
- ----------------------------
- What: i2c_driver.attach_adapter
- i2c_driver.detach_adapter
- When: September 2011
- Why: These legacy callbacks should no longer be used as i2c-core offers
- a variety of preferable alternative ways to instantiate I2C devices.
- Who: Jean Delvare <khali@linux-fr.org>
- ----------------------------
|