| 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: CONFIG_WIRELESS_OLD_REGULATORY - old static regulatory information |
| When: March 2010 / desktop catchup |
| |
| Why: The old regulatory infrastructure has been replaced with a new one |
| which does not require statically defined regulatory domains. We do |
| not want to keep static regulatory domains in the kernel due to the |
| the dynamic nature of regulatory law and localization. We kept around |
| the old static definitions for the regulatory domains of: |
| |
| * US |
| * JP |
| * EU |
| |
| and used by default the US when CONFIG_WIRELESS_OLD_REGULATORY was |
| set. We will remove this option once the standard Linux desktop catches |
| up with the new userspace APIs we have implemented. |
| |
| 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@suse.cz> |
| |
| --------------------------- |
| |
| What: Video4Linux API 1 ioctls and from Video devices. |
| When: July 2009 |
| Files: include/linux/videodev.h |
| Check: include/linux/videodev.h |
| 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. |
| Compatibility ioctls will be provided, for a while, via |
| v4l1-compat module. |
| Who: Mauro Carvalho Chehab <mchehab@infradead.org> |
| |
| --------------------------- |
| |
| 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: 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: 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: /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: /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 (Why): |
| - xt_recent: the old ipt_recent proc dir |
| (superseded by /proc/net/xt_recent) |
| |
| When: January 2009 or Linux 2.7.0, whichever comes first |
| Why: Superseded by newer revisions or modules |
| Who: Jan Engelhardt <jengelh@computergmbh.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: CONFIG_NF_CT_ACCT |
| When: 2.6.29 |
| Why: Accounting can now be enabled/disabled without kernel recompilation. |
| Currently used only to set a default value for a feature that is also |
| controlled by a kernel/module/sysfs/sysctl parameter. |
| Who: Krzysztof Piotr Oledzki <ole@ans.pl> |
| |
| --------------------------- |
| |
| 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: __do_IRQ all in one fits nothing interrupt handler |
| When: 2.6.32 |
| Why: __do_IRQ was kept for easy migration to the type flow handlers. |
| More than two years of migration time is enough. |
| Who: Thomas Gleixner <tglx@linutronix.de> |
| |
| ----------------------------- |
| |
| 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: CONFIG_INOTIFY |
| When: 2.6.33 |
| Why: last user (audit) will be converted to the newer more generic |
| and more easily maintained fsnotify subsystem |
| Who: Eric Paris <eparis@redhat.com> |
| |
| ---------------------------- |
| |
| What: lock_policy_rwsem_* and unlock_policy_rwsem_* will not be |
| exported interface anymore. |
| When: 2.6.33 |
| Why: cpu_policy_rwsem has a new cleaner definition making it local to |
| cpufreq core and contained inside cpufreq.c. Other dependent |
| drivers should not use it in order to safely avoid lockdep issues. |
| Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> |
| |
| ---------------------------- |
| |
| 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 VMware's guest paravirtuliazation technique [VMI] will be |
| dropped. |
| When: 2.6.37 or earlier. |
| Why: With the recent innovations in CPU hardware acceleration technologies |
| from Intel and AMD, VMware ran a few experiments to compare these |
| techniques to guest paravirtualization technique on VMware's platform. |
| These hardware assisted virtualization techniques have outperformed the |
| performance benefits provided by VMI in most of the workloads. VMware |
| expects that these hardware features will be ubiquitous in a couple of |
| years, as a result, VMware has started a phased retirement of this |
| feature from the hypervisor. We will be removing this feature from the |
| Kernel too. Right now we are targeting 2.6.37 but can retire earlier if |
| technical reasons (read opportunity to remove major chunk of pvops) |
| arise. |
| |
| Please note that VMI has always been an optimization and non-VMI kernels |
| still work fine on VMware's platform. |
| Latest versions of VMware's product which support VMI are, |
| Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence |
| releases for these products will continue supporting VMI. |
| |
| For more details about VMI retirement take a look at this, |
| http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html |
| |
| Who: Alok N Kataria <akataria@vmware.com> |
| |
| ---------------------------- |
| |
| What: adt7473 hardware monitoring driver |
| When: February 2010 |
| Why: Obsoleted by the adt7475 driver. |
| Who: Jean Delvare <khali@linux-fr.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: usbvideo quickcam_messenger driver |
| When: 2.6.35 |
| Files: drivers/media/video/usbvideo/quickcam_messenger.[ch] |
| Why: obsolete v4l1 driver replaced by gspca_stv06xx |
| Who: Hans de Goede <hdegoede@redhat.com> |
| |
| ---------------------------- |
| |
| What: ov511 v4l1 driver |
| When: 2.6.35 |
| Files: drivers/media/video/ov511.[ch] |
| Why: obsolete v4l1 driver replaced by gspca_ov519 |
| Who: Hans de Goede <hdegoede@redhat.com> |
| |
| ---------------------------- |
| |
| What: w9968cf v4l1 driver |
| When: 2.6.35 |
| Files: drivers/media/video/w9968cf*.[ch] |
| Why: obsolete v4l1 driver replaced by gspca_ov519 |
| Who: Hans de Goede <hdegoede@redhat.com> |
| |
| ---------------------------- |
| |
| What: ovcamchip sensor framework |
| When: 2.6.35 |
| Files: drivers/media/video/ovcamchip/* |
| Why: Only used by obsoleted v4l1 drivers |
| Who: Hans de Goede <hdegoede@redhat.com> |
| |
| ---------------------------- |
| |
| What: stv680 v4l1 driver |
| When: 2.6.35 |
| Files: drivers/media/video/stv680.[ch] |
| Why: obsolete v4l1 driver replaced by gspca_stv0680 |
| Who: Hans de Goede <hdegoede@redhat.com> |
| |
| ---------------------------- |
| |
| What: zc0301 v4l driver |
| When: 2.6.35 |
| Files: drivers/media/video/zc0301/* |
| Why: Duplicate functionality with the gspca_zc3xx driver, zc0301 only |
| supports 2 USB-ID's (because it only supports a limited set of |
| sensors) wich are also supported by the gspca_zc3xx driver |
| (which supports 53 USB-ID's in total) |
| Who: Hans de Goede <hdegoede@redhat.com> |
| |
| ---------------------------- |
| |
| What: corgikbd, spitzkbd, tosakbd driver |
| When: 2.6.35 |
| Files: drivers/input/keyboard/{corgi,spitz,tosa}kbd.c |
| Why: We now have a generic GPIO based matrix keyboard driver that |
| are fully capable of handling all the keys on these devices. |
| The original drivers manipulate the GPIO registers directly |
| and so are difficult to maintain. |
| Who: Eric Miao <eric.y.miao@gmail.com> |
| |
| ---------------------------- |
| |
| What: corgi_ssp and corgi_ts driver |
| When: 2.6.35 |
| Files: arch/arm/mach-pxa/corgi_ssp.c, drivers/input/touchscreen/corgi_ts.c |
| Why: The corgi touchscreen is now deprecated in favour of the generic |
| ads7846.c driver. The noise reduction technique used in corgi_ts.c, |
| that's to wait till vsync before ADC sampling, is also integrated into |
| ads7846 driver now. Provided that the original driver is not generic |
| and is difficult to maintain, it will be removed later. |
| Who: Eric Miao <eric.y.miao@gmail.com> |
