| 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:	Video4Linux obsolete drivers using V4L1 API | 
 | When:	kernel 2.6.39 | 
 | Files:	drivers/staging/se401/* drivers/staging/usbvideo/* | 
 | Check:	drivers/staging/se401/se401.c drivers/staging/usbvideo/usbvideo.c | 
 | Why:	There are some drivers still using V4L1 API, despite all efforts we've done | 
 | 	to migrate. Those drivers are for obsolete hardware that the old maintainer | 
 | 	didn't care (or not have the hardware anymore), and that no other developer | 
 | 	could find any hardware to buy. They probably have no practical usage today, | 
 | 	and people with such old hardware could probably keep using an older version | 
 | 	of the kernel. Those drivers will be moved to staging on 2.6.38 and, if nobody | 
 | 	cares enough to port and test them with V4L2 API, they'll be removed on 2.6.39. | 
 | Who:	Mauro Carvalho Chehab <mchehab@infradead.org> | 
 |  | 
 | --------------------------- | 
 |  | 
 | What:	Video4Linux: Remove obsolete ioctl's | 
 | When:	kernel 2.6.39 | 
 | Files:	include/media/videodev2.h | 
 | Why:	Some ioctl's were defined wrong on 2.6.2 and 2.6.6, using the wrong | 
 | 	type of R/W arguments. They were fixed, but the old ioctl names are | 
 | 	still there, maintained to avoid breaking binary compatibility: | 
 | 	  #define VIDIOC_OVERLAY_OLD   	_IOWR('V', 14, int) | 
 | 	  #define VIDIOC_S_PARM_OLD	_IOW('V', 22, struct v4l2_streamparm) | 
 | 	  #define VIDIOC_S_CTRL_OLD	_IOW('V', 28, struct v4l2_control) | 
 | 	  #define VIDIOC_G_AUDIO_OLD	_IOWR('V', 33, struct v4l2_audio) | 
 | 	  #define VIDIOC_G_AUDOUT_OLD	_IOWR('V', 49, struct v4l2_audioout) | 
 | 	  #define VIDIOC_CROPCAP_OLD	_IOR('V', 58, struct v4l2_cropcap) | 
 | 	There's no sense on preserving those forever, as it is very doubtful | 
 | 	that someone would try to use a such old binary with a modern kernel. | 
 | 	Removing them will allow us to remove some magic done at the V4L ioctl | 
 | 	handler. | 
 |  | 
 | Who:	Mauro Carvalho Chehab <mchehab@infradead.org> | 
 |  | 
 | --------------------------- | 
 |  | 
 | 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/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:	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:	__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:	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:	i2c_adapter.id | 
 | When:	June 2011 | 
 | Why:	This field is deprecated. I2C device drivers shouldn't change their | 
 | 	behavior based on the underlying I2C adapter. Instead, the I2C | 
 | 	adapter driver should instantiate the I2C devices and provide the | 
 | 	needed platform-specific information. | 
 | Who:	Jean Delvare <khali@linux-fr.org> | 
 |  | 
 | ---------------------------- | 
 |  | 
 | 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> | 
 |  | 
 | ---------------------------- |