feature-removal-schedule.txt 10.8 KB
Newer Older
L
Linus Torvalds 已提交
1 2 3 4 5 6 7 8
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.

---------------------------

A
Alan Stern 已提交
9
What:	dev->power.power_state
10 11 12 13 14 15 16 17 18 19 20 21
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>

---------------------------

22 23 24
What:	old NCR53C9x driver
When:	October 2007
Why:	Replaced by the much better esp_scsi driver.  Actual low-level
25
	driver can be ported over almost trivially.
26 27 28 29 30
Who:	David Miller <davem@davemloft.net>
	Christoph Hellwig <hch@lst.de>

---------------------------

31
What:	Video4Linux API 1 ioctls and video_decoder.h from Video devices.
32 33 34 35
When:	December 2008
Files:	include/linux/video_decoder.h include/linux/videodev.h
Check:	include/linux/video_decoder.h include/linux/videodev.h
Why:	V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6
36 37 38 39 40 41 42 43
	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.
44 45 46
	Compatibility ioctls will be provided, for a while, via 
	v4l1-compat module. 
Who:	Mauro Carvalho Chehab <mchehab@infradead.org>
47 48 49

---------------------------

50 51 52 53 54 55 56 57 58 59 60 61 62 63
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>
64 65 66

---------------------------

67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101
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>

---------------------------

102 103 104
What:	remove EXPORT_SYMBOL(kernel_thread)
When:	August 2006
Files:	arch/*/kernel/*_ksyms.c
105
Check:	kernel_thread
106 107 108 109 110 111 112 113
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>

---------------------------

114 115 116 117 118 119 120 121 122
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

---------------------------

B
Bunk 已提交
123 124 125 126
What:   eepro100 network driver
When:   January 2007
Why:    replaced by the e100 driver
Who:    Adrian Bunk <bunk@stusta.de>
J
Jeff Garzik 已提交
127 128 129

---------------------------

130 131 132 133 134 135 136 137 138 139
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>

---------------------------

140
What:	vm_ops.nopage
N
Nick Piggin 已提交
141
When:	Soon, provided in-kernel callers have been converted
142 143 144 145 146 147 148
Why:	This interface is replaced by vm_ops.fault, but it has been around
	forever, is used by a lot of drivers, and doesn't cost much to
	maintain.
Who:	Nick Piggin <npiggin@suse.de>

---------------------------

K
Kay Sievers 已提交
149
What:	PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
150
When:	October 2008
K
Kay Sievers 已提交
151 152 153 154 155 156 157
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>

---------------------------
J
Jean Delvare 已提交
158

159
What:	ACPI procfs interface
160 161 162 163
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.
164 165 166 167
Who:	Zhang Rui <rui.zhang@intel.com>

---------------------------

168 169 170 171 172 173 174
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>

---------------------------
175

176 177 178 179 180 181 182 183
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>

---------------------------

184
What: libata spindown skipping and warning
185
When: Dec 2008
186 187 188 189 190 191
Why:  Some halt(8) implementations synchronize caches for and spin
      down libata disks because libata didn't use to spin down disk on
      system halt (only synchronized caches).
      Spin down on system halt is now implemented.  sysfs node
      /sys/class/scsi_disk/h:c:i:l/manage_start_stop is present if
      spin down support is available.
192
      Because issuing spin down command to an already spun down disk
193 194 195 196 197
      makes some disks spin up just to spin down again, libata tracks
      device spindown status to skip the extra spindown command and
      warn about it.
      This is to give userspace tools the time to get updated and will
      be removed after userspace is reasonably updated.
198 199 200 201
Who:  Tejun Heo <htejun@gmail.com>

---------------------------

202 203 204 205 206 207 208 209 210 211 212 213
What: The arch/ppc and include/asm-ppc directories
When: Jun 2008
Why:  The arch/powerpc tree is the merged architecture for ppc32 and ppc64
      platforms.  Currently there are efforts underway to port the remaining
      arch/ppc platforms to the merged tree.  New submissions to the arch/ppc
      tree have been frozen with the 2.6.22 kernel release and that tree will
      remain in bug-fix only mode until its scheduled removal.  Platforms
      that are not ported by June 2008 will be removed due to the lack of an
      interested maintainer.
Who:  linuxppc-dev@ozlabs.org

---------------------------
214

S
Stephen Hemminger 已提交
215 216 217 218 219 220 221
What:   sk98lin network driver
When:   Feburary 2008
Why:    In kernel tree version of driver is unmaintained. Sk98lin driver
	replaced by the skge driver. 
Who:    Stephen Hemminger <shemminger@linux-foundation.org>

---------------------------
222 223 224 225 226 227 228 229

What:	i386/x86_64 bzImage symlinks
When:	April 2008

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>
230 231 232 233

---------------------------

---------------------------
234 235 236 237 238 239 240

What:	i2c-i810, i2c-prosavage and i2c-savage4
When:	May 2008
Why:	These drivers are superseded by i810fb, intelfb and savagefb.
Who:	Jean Delvare <khali@linux-fr.org>

---------------------------
241 242 243 244 245 246 247 248 249

What:	bcm43xx wireless network driver
When:	2.6.26
Files:	drivers/net/wireless/bcm43xx
Why:	This driver's functionality has been replaced by the
	mac80211-based b43 and b43legacy drivers.
Who:	John W. Linville <linville@tuxdriver.com>

---------------------------
250

251
What:	ieee80211 softmac wireless networking component
252 253 254 255 256 257
When:	2.6.26 (or after removal of bcm43xx and port of zd1211rw to mac80211)
Files:	net/ieee80211/softmac
Why:	No in-kernel drivers will depend on it any longer.
Who:	John W. Linville <linville@tuxdriver.com>

---------------------------
258 259 260 261 262 263 264 265

What:	rc80211-simple rate control algorithm for mac80211
When:	2.6.26
Files:	net/mac80211/rc80211-simple.c
Why:	This algorithm was provided for reference but always exhibited bad
	responsiveness and performance and has some serious flaws. It has been
	replaced by rc80211-pid.
Who:	Stefano Brivio <stefano.brivio@polimi.it>
266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297

---------------------------

What (Why):
	- include/linux/netfilter_ipv4/ipt_TOS.h ipt_tos.h header files
	  (superseded by xt_TOS/xt_tos target & match)

	- "forwarding" header files like ipt_mac.h in
	  include/linux/netfilter_ipv4/ and include/linux/netfilter_ipv6/

	- xt_CONNMARK match revision 0
	  (superseded by xt_CONNMARK match revision 1)

	- xt_MARK target revisions 0 and 1
	  (superseded by xt_MARK match revision 2)

	- xt_connmark match revision 0
	  (superseded by xt_connmark match revision 1)

	- xt_conntrack match revision 0
	  (superseded by xt_conntrack match revision 1)

	- xt_iprange match revision 0,
	  include/linux/netfilter_ipv4/ipt_iprange.h
	  (superseded by xt_iprange match revision 1)

	- xt_mark match revision 0
	  (superseded by xt_mark match revision 1)

When:	January 2009 or Linux 2.7.0, whichever comes first
Why:	Superseded by newer revisions or modules
Who:	Jan Engelhardt <jengelh@computergmbh.de>
298 299 300 301 302 303 304 305 306

---------------------------

What:	b43 support for firmware revision < 410
When:	July 2008
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>