Documentation/feature-removal-schedule.txt

   1 The following is a list of files and features that are going to be
   2 removed in the kernel source tree.  Every entry should contain what
   3 exactly is going away, why it is happening, and who is going to be doing
   4 the work.  When the feature is removed from the kernel, it should also
   5 be removed from this file.
   6
   7 ---------------------------
   8
   9 What:   USER_SCHED
  10 When:   2.6.34
  11
  12 Why:    USER_SCHED was implemented as a proof of concept for group scheduling.
  13         The effect of USER_SCHED can already be achieved from userspace with
  14         the help of libcgroup. The removal of USER_SCHED will also simplify
  15         the scheduler code with the removal of one major ifdef. There are also
  16         issues USER_SCHED has with USER_NS. A decision was taken not to fix
  17         those and instead remove USER_SCHED. Also new group scheduling
  18         features will not be implemented for USER_SCHED.
  19
  20 Who:    Dhaval Giani <dhaval@linux.vnet.ibm.com>
  21
  22 ---------------------------
  23
  24 What:   PRISM54
  25 When:   2.6.34
  26
  27 Why:    prism54 FullMAC PCI / Cardbus devices used to be supported only by the
  28         prism54 wireless driver. After Intersil stopped selling these
  29         devices in preference for the newer more flexible SoftMAC devices
  30         a SoftMAC device driver was required and prism54 did not support
  31         them. The p54pci driver now exists and has been present in the kernel for
  32         a while. This driver supports both SoftMAC devices and FullMAC devices.
  33         The main difference between these devices was the amount of memory which
  34         could be used for the firmware. The SoftMAC devices support a smaller
  35         amount of memory. Because of this the SoftMAC firmware fits into FullMAC
  36         devices's memory. p54pci supports not only PCI / Cardbus but also USB
  37         and SPI. Since p54pci supports all devices prism54 supports
  38         you will have a conflict. I'm not quite sure how distributions are
  39         handling this conflict right now. prism54 was kept around due to
  40         claims users may experience issues when using the SoftMAC driver.
  41         Time has passed users have not reported issues. If you use prism54
  42         and for whatever reason you cannot use p54pci please let us know!
  43         E-mail us at: linux-wireless@vger.kernel.org
  44
  45         For more information see the p54 wiki page:
  46
  47         http://wireless.kernel.org/en/users/Drivers/p54
  48
  49 Who:    Luis R. Rodriguez <lrodriguez@atheros.com>
  50
  51 ---------------------------
  52
  53 What:   IRQF_SAMPLE_RANDOM
  54 Check:  IRQF_SAMPLE_RANDOM
  55 When:   July 2009
  56
  57 Why:    Many of IRQF_SAMPLE_RANDOM users are technically bogus as entropy
  58         sources in the kernel's current entropy model. To resolve this, every
  59         input point to the kernel's entropy pool needs to better document the
  60         type of entropy source it actually is. This will be replaced with
  61         additional add_*_randomness functions in drivers/char/random.c
  62
  63 Who:    Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com>
  64
  65 ---------------------------
  66
  67 What:   Deprecated snapshot ioctls
  68 When:   2.6.36
  69
  70 Why:    The ioctls in kernel/power/user.c were marked as deprecated long time
  71         ago. Now they notify users about that so that they need to replace
  72         their userspace. After some more time, remove them completely.
  73
  74 Who:    Jiri Slaby <jirislaby@gmail.com>
  75
  76 ---------------------------
  77
  78 What:   The ieee80211_regdom module parameter
  79 When:   March 2010 / desktop catchup
  80
  81 Why:    This was inherited by the CONFIG_WIRELESS_OLD_REGULATORY code,
  82         and currently serves as an option for users to define an
  83         ISO / IEC 3166 alpha2 code for the country they are currently
  84         present in. Although there are userspace API replacements for this
  85         through nl80211 distributions haven't yet caught up with implementing
  86         decent alternatives through standard GUIs. Although available as an
  87         option through iw or wpa_supplicant its just a matter of time before
  88         distributions pick up good GUI options for this. The ideal solution
  89         would actually consist of intelligent designs which would do this for
  90         the user automatically even when travelling through different countries.
  91         Until then we leave this module parameter as a compromise.
  92
  93         When userspace improves with reasonable widely-available alternatives for
  94         this we will no longer need this module parameter. This entry hopes that
  95         by the super-futuristically looking date of "March 2010" we will have
  96         such replacements widely available.
  97
  98 Who:    Luis R. Rodriguez <lrodriguez@atheros.com>
  99
 100 ---------------------------
 101
 102 What:   CONFIG_WIRELESS_OLD_REGULATORY - old static regulatory information
 103 When:   March 2010 / desktop catchup
 104
 105 Why:    The old regulatory infrastructure has been replaced with a new one
 106         which does not require statically defined regulatory domains. We do
 107         not want to keep static regulatory domains in the kernel due to the
 108         the dynamic nature of regulatory law and localization. We kept around
 109         the old static definitions for the regulatory domains of:
 110
 111                 * US
 112                 * JP
 113                 * EU
 114
 115         and used by default the US when CONFIG_WIRELESS_OLD_REGULATORY was
 116         set. We will remove this option once the standard Linux desktop catches
 117         up with the new userspace APIs we have implemented.
 118
 119 Who:    Luis R. Rodriguez <lrodriguez@atheros.com>
 120
 121 ---------------------------
 122
 123 What:   dev->power.power_state
 124 When:   July 2007
 125 Why:    Broken design for runtime control over driver power states, confusing
 126         driver-internal runtime power management with:  mechanisms to support
 127         system-wide sleep state transitions; event codes that distinguish
 128         different phases of swsusp "sleep" transitions; and userspace policy
 129         inputs.  This framework was never widely used, and most attempts to
 130         use it were broken.  Drivers should instead be exposing domain-specific
 131         interfaces either to kernel or to userspace.
 132 Who:    Pavel Machek <pavel@suse.cz>
 133
 134 ---------------------------
 135
 136 What:   Video4Linux API 1 ioctls and from Video devices.
 137 When:   July 2009
 138 Files:  include/linux/videodev.h
 139 Check:  include/linux/videodev.h
 140 Why:    V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6
 141         series. The old API have lots of drawbacks and don't provide enough
 142         means to work with all video and audio standards. The newer API is
 143         already available on the main drivers and should be used instead.
 144         Newer drivers should use v4l_compat_translate_ioctl function to handle
 145         old calls, replacing to newer ones.
 146         Decoder iocts are using internally to allow video drivers to
 147         communicate with video decoders. This should also be improved to allow
 148         V4L2 calls being translated into compatible internal ioctls.
 149         Compatibility ioctls will be provided, for a while, via
 150         v4l1-compat module.
 151 Who:    Mauro Carvalho Chehab <mchehab@infradead.org>
 152
 153 ---------------------------
 154
 155 What:   PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
 156 When:   November 2005
 157 Files:  drivers/pcmcia/: pcmcia_ioctl.c
 158 Why:    With the 16-bit PCMCIA subsystem now behaving (almost) like a
 159         normal hotpluggable bus, and with it using the default kernel
 160         infrastructure (hotplug, driver core, sysfs) keeping the PCMCIA
 161         control ioctl needed by cardmgr and cardctl from pcmcia-cs is
 162         unnecessary, and makes further cleanups and integration of the
 163         PCMCIA subsystem into the Linux kernel device driver model more
 164         difficult. The features provided by cardmgr and cardctl are either
 165         handled by the kernel itself now or are available in the new
 166         pcmciautils package available at
 167         http://kernel.org/pub/linux/utils/kernel/pcmcia/
 168 Who:    Dominik Brodowski <linux@brodo.de>
 169
 170 ---------------------------
 171
 172 What:   sys_sysctl
 173 When:   September 2010
 174 Option: CONFIG_SYSCTL_SYSCALL
 175 Why:    The same information is available in a more convenient from
 176         /proc/sys, and none of the sysctl variables appear to be
 177         important performance wise.
 178
 179         Binary sysctls are a long standing source of subtle kernel
 180         bugs and security issues.
 181
 182         When I looked several months ago all I could find after
 183         searching several distributions were 5 user space programs and
 184         glibc (which falls back to /proc/sys) using this syscall.
 185
 186         The man page for sysctl(2) documents it as unusable for user
 187         space programs.
 188
 189         sysctl(2) is not generally ABI compatible to a 32bit user
 190         space application on a 64bit and a 32bit kernel.
 191
 192         For the last several months the policy has been no new binary
 193         sysctls and no one has put forward an argument to use them.
 194
 195         Binary sysctls issues seem to keep happening appearing so
 196         properly deprecating them (with a warning to user space) and a
 197         2 year grace warning period will mean eventually we can kill
 198         them and end the pain.
 199
 200         In the mean time individual binary sysctls can be dealt with
 201         in a piecewise fashion.
 202
 203 Who:    Eric Biederman <ebiederm@xmission.com>
 204
 205 ---------------------------
 206
 207 What:   remove EXPORT_SYMBOL(kernel_thread)
 208 When:   August 2006
 209 Files:  arch/*/kernel/*_ksyms.c
 210 Check:  kernel_thread
 211 Why:    kernel_thread is a low-level implementation detail.  Drivers should
 212         use the <linux/kthread.h> API instead which shields them from
 213         implementation details and provides a higherlevel interface that
 214         prevents bugs and code duplication
 215 Who:    Christoph Hellwig <hch@lst.de>
 216
 217 ---------------------------
 218
 219 What:   Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
 220         (temporary transition config option provided until then)
 221         The transition config option will also be removed at the same time.
 222 When:   before 2.6.19
 223 Why:    Unused symbols are both increasing the size of the kernel binary
 224         and are often a sign of "wrong API"
 225 Who:    Arjan van de Ven <arjan@linux.intel.com>
 226
 227 ---------------------------
 228
 229 What:   PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
 230 When:   October 2008
 231 Why:    The stacking of class devices makes these values misleading and
 232         inconsistent.
 233         Class devices should not carry any of these properties, and bus
 234         devices have SUBSYTEM and DRIVER as a replacement.
 235 Who:    Kay Sievers <kay.sievers@suse.de>
 236
 237 ---------------------------
 238
 239 What:   ACPI procfs interface
 240 When:   July 2008
 241 Why:    ACPI sysfs conversion should be finished by January 2008.
 242         ACPI procfs interface will be removed in July 2008 so that
 243         there is enough time for the user space to catch up.
 244 Who:    Zhang Rui <rui.zhang@intel.com>
 245
 246 ---------------------------
 247
 248 What:   /proc/acpi/button
 249 When:   August 2007
 250 Why:    /proc/acpi/button has been replaced by events to the input layer
 251         since 2.6.20.
 252 Who:    Len Brown <len.brown@intel.com>
 253
 254 ---------------------------
 255
 256 What:   /proc/acpi/event
 257 When:   February 2008
 258 Why:    /proc/acpi/event has been replaced by events via the input layer
 259         and netlink since 2.6.23.
 260 Who:    Len Brown <len.brown@intel.com>
 261
 262 ---------------------------
 263
 264 What:   i386/x86_64 bzImage symlinks
 265 When:   April 2010
 266
 267 Why:    The i386/x86_64 merge provides a symlink to the old bzImage
 268         location so not yet updated user space tools, e.g. package
 269         scripts, do not break.
 270 Who:    Thomas Gleixner <tglx@linutronix.de>
 271
 272 ---------------------------
 273
 274 What (Why):
 275         - xt_recent: the old ipt_recent proc dir
 276           (superseded by /proc/net/xt_recent)
 277
 278 When:   January 2009 or Linux 2.7.0, whichever comes first
 279 Why:    Superseded by newer revisions or modules
 280 Who:    Jan Engelhardt <jengelh@computergmbh.de>
 281
 282 ---------------------------
 283
 284 What:   GPIO autorequest on gpio_direction_{input,output}() in gpiolib
 285 When:   February 2010
 286 Why:    All callers should use explicit gpio_request()/gpio_free().
 287         The autorequest mechanism in gpiolib was provided mostly as a
 288         migration aid for legacy GPIO interfaces (for SOC based GPIOs).
 289         Those users have now largely migrated.  Platforms implementing
 290         the GPIO interfaces without using gpiolib will see no changes.
 291 Who:    David Brownell <dbrownell@users.sourceforge.net>
 292 ---------------------------
 293
 294 What:   b43 support for firmware revision < 410
 295 When:   The schedule was July 2008, but it was decided that we are going to keep the
 296         code as long as there are no major maintanance headaches.
 297         So it _could_ be removed _any_ time now, if it conflicts with something new.
 298 Why:    The support code for the old firmware hurts code readability/maintainability
 299         and slightly hurts runtime performance. Bugfixes for the old firmware
 300         are not provided by Broadcom anymore.
 301 Who:    Michael Buesch <mb@bu3sch.de>
 302
 303 ---------------------------
 304
 305 What:   /sys/o2cb symlink
 306 When:   January 2010
 307 Why:    /sys/fs/o2cb is the proper location for this information - /sys/o2cb
 308         exists as a symlink for backwards compatibility for old versions of
 309         ocfs2-tools. 2 years should be sufficient time to phase in new versions
 310         which know to look in /sys/fs/o2cb.
 311 Who:    ocfs2-devel@oss.oracle.com
 312
 313 ---------------------------
 314
 315 What:   Ability for non root users to shm_get hugetlb pages based on mlock
 316         resource limits
 317 When:   2.6.31
 318 Why:    Non root users need to be part of /proc/sys/vm/hugetlb_shm_group or
 319         have CAP_IPC_LOCK to be able to allocate shm segments backed by
 320         huge pages.  The mlock based rlimit check to allow shm hugetlb is
 321         inconsistent with mmap based allocations.  Hence it is being
 322         deprecated.
 323 Who:    Ravikiran Thirumalai <kiran@scalex86.org>
 324
 325 ---------------------------
 326
 327 What:   CONFIG_THERMAL_HWMON
 328 When:   January 2009
 329 Why:    This option was introduced just to allow older lm-sensors userspace
 330         to keep working over the upgrade to 2.6.26. At the scheduled time of
 331         removal fixed lm-sensors (2.x or 3.x) should be readily available.
 332 Who:    Rene Herman <rene.herman@gmail.com>
 333
 334 ---------------------------
 335
 336 What:   Code that is now under CONFIG_WIRELESS_EXT_SYSFS
 337         (in net/core/net-sysfs.c)
 338 When:   After the only user (hal) has seen a release with the patches
 339         for enough time, probably some time in 2010.
 340 Why:    Over 1K .text/.data size reduction, data is available in other
 341         ways (ioctls)
 342 Who:    Johannes Berg <johannes@sipsolutions.net>
 343
 344 ---------------------------
 345
 346 What: CONFIG_NF_CT_ACCT
 347 When: 2.6.29
 348 Why:  Accounting can now be enabled/disabled without kernel recompilation.
 349       Currently used only to set a default value for a feature that is also
 350       controlled by a kernel/module/sysfs/sysctl parameter.
 351 Who:  Krzysztof Piotr Oledzki <ole@ans.pl>
 352
 353 ---------------------------
 354
 355 What:   sysfs ui for changing p4-clockmod parameters
 356 When:   September 2009
 357 Why:    See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and
 358         e088e4c9cdb618675874becb91b2fd581ee707e6.
 359         Removal is subject to fixing any remaining bugs in ACPI which may
 360         cause the thermal throttling not to happen at the right time.
 361 Who:    Dave Jones <davej@redhat.com>, Matthew Garrett <mjg@redhat.com>
 362
 363 -----------------------------
 364
 365 What:   __do_IRQ all in one fits nothing interrupt handler
 366 When:   2.6.32
 367 Why:    __do_IRQ was kept for easy migration to the type flow handlers.
 368         More than two years of migration time is enough.
 369 Who:    Thomas Gleixner <tglx@linutronix.de>
 370
 371 -----------------------------
 372
 373 What:   fakephp and associated sysfs files in /sys/bus/pci/slots/
 374 When:   2011
 375 Why:    In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to
 376         represent a machine's physical PCI slots. The change in semantics
 377         had userspace implications, as the hotplug core no longer allowed
 378         drivers to create multiple sysfs files per physical slot (required
 379         for multi-function devices, e.g.). fakephp was seen as a developer's
 380         tool only, and its interface changed. Too late, we learned that
 381         there were some users of the fakephp interface.
 382
 383         In 2.6.30, the original fakephp interface was restored. At the same
 384         time, the PCI core gained the ability that fakephp provided, namely
 385         function-level hot-remove and hot-add.
 386
 387         Since the PCI core now provides the same functionality, exposed in:
 388
 389                 /sys/bus/pci/rescan
 390                 /sys/bus/pci/devices/.../remove
 391                 /sys/bus/pci/devices/.../rescan
 392
 393         there is no functional reason to maintain fakephp as well.
 394
 395         We will keep the existing module so that 'modprobe fakephp' will
 396         present the old /sys/bus/pci/slots/... interface for compatibility,
 397         but users are urged to migrate their applications to the API above.
 398
 399         After a reasonable transition period, we will remove the legacy
 400         fakephp interface.
 401 Who:    Alex Chiang <achiang@hp.com>
 402
 403 ---------------------------
 404
 405 What:   CONFIG_RFKILL_INPUT
 406 When:   2.6.33
 407 Why:    Should be implemented in userspace, policy daemon.
 408 Who:    Johannes Berg <johannes@sipsolutions.net>
 409
 410 ---------------------------
 411
 412 What:   CONFIG_INOTIFY
 413 When:   2.6.33
 414 Why:    last user (audit) will be converted to the newer more generic
 415         and more easily maintained fsnotify subsystem
 416 Who:    Eric Paris <eparis@redhat.com>
 417
 418 ----------------------------
 419
 420 What:   lock_policy_rwsem_* and unlock_policy_rwsem_* will not be
 421         exported interface anymore.
 422 When:   2.6.33
 423 Why:    cpu_policy_rwsem has a new cleaner definition making it local to
 424         cpufreq core and contained inside cpufreq.c. Other dependent
 425         drivers should not use it in order to safely avoid lockdep issues.
 426 Who:    Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
 427
 428 ----------------------------
 429
 430 What:   sound-slot/service-* module aliases and related clutters in
 431         sound/sound_core.c
 432 When:   August 2010
 433 Why:    OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR
 434         (14) and requests modules using custom sound-slot/service-*
 435         module aliases.  The only benefit of doing this is allowing
 436         use of custom module aliases which might as well be considered
 437         a bug at this point.  This preemptive claiming prevents
 438         alternative OSS implementations.
 439
 440         Till the feature is removed, the kernel will be requesting
 441         both sound-slot/service-* and the standard char-major-* module
 442         aliases and allow turning off the pre-claiming selectively via
 443         CONFIG_SOUND_OSS_CORE_PRECLAIM and soundcore.preclaim_oss
 444         kernel parameter.
 445
 446         After the transition phase is complete, both the custom module
 447         aliases and switches to disable it will go away.  This removal
 448         will also allow making ALSA OSS emulation independent of
 449         sound_core.  The dependency will be broken then too.
 450 Who:    Tejun Heo <tj@kernel.org>
 451
 452 ----------------------------
 453
 454 What:   Support for VMware's guest paravirtuliazation technique [VMI] will be
 455         dropped.
 456 When:   2.6.37 or earlier.
 457 Why:    With the recent innovations in CPU hardware acceleration technologies
 458         from Intel and AMD, VMware ran a few experiments to compare these
 459         techniques to guest paravirtualization technique on VMware's platform.
 460         These hardware assisted virtualization techniques have outperformed the
 461         performance benefits provided by VMI in most of the workloads. VMware
 462         expects that these hardware features will be ubiquitous in a couple of
 463         years, as a result, VMware has started a phased retirement of this
 464         feature from the hypervisor. We will be removing this feature from the
 465         Kernel too. Right now we are targeting 2.6.37 but can retire earlier if
 466         technical reasons (read opportunity to remove major chunk of pvops)
 467         arise.
 468
 469         Please note that VMI has always been an optimization and non-VMI kernels
 470         still work fine on VMware's platform.
 471         Latest versions of VMware's product which support VMI are,
 472         Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence
 473         releases for these products will continue supporting VMI.
 474
 475         For more details about VMI retirement take a look at this,
 476         http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html
 477
 478 Who:    Alok N Kataria <akataria@vmware.com>
 479
 480 ----------------------------
 481
 482 What:   adt7473 hardware monitoring driver
 483 When:   February 2010
 484 Why:    Obsoleted by the adt7475 driver.
 485 Who:    Jean Delvare <khali@linux-fr.org>
 486
 487 ---------------------------
 488 What:   Support for lcd_switch and display_get in asus-laptop driver
 489 When:   March 2010
 490 Why:    These two features use non-standard interfaces. There are the
 491         only features that really need multiple path to guess what's
 492         the right method name on a specific laptop.
 493
 494         Removing them will allow to remove a lot of code an significantly
 495         clean the drivers.
 496
 497         This will affect the backlight code which won't be able to know
 498         if the backlight is on or off. The platform display file will also be
 499         write only (like the one in eeepc-laptop).
 500
 501         This should'nt affect a lot of user because they usually know
 502         when their display is on or off.
 503
 504 Who:    Corentin Chary <corentin.chary@gmail.com>
 505
 506 ----------------------------
 507
 508 What:   usbvideo quickcam_messenger driver
 509 When:   2.6.35
 510 Files:  drivers/media/video/usbvideo/quickcam_messenger.[ch]
 511 Why:    obsolete v4l1 driver replaced by gspca_stv06xx
 512 Who:    Hans de Goede <hdegoede@redhat.com>
 513
 514 ----------------------------
 515
 516 What:   ov511 v4l1 driver
 517 When:   2.6.35
 518 Files:  drivers/media/video/ov511.[ch]
 519 Why:    obsolete v4l1 driver replaced by gspca_ov519
 520 Who:    Hans de Goede <hdegoede@redhat.com>
 521
 522 ----------------------------
 523
 524 What:   w9968cf v4l1 driver
 525 When:   2.6.35
 526 Files:  drivers/media/video/w9968cf*.[ch]
 527 Why:    obsolete v4l1 driver replaced by gspca_ov519
 528 Who:    Hans de Goede <hdegoede@redhat.com>
 529
 530 ----------------------------
 531
 532 What:   ovcamchip sensor framework
 533 When:   2.6.35
 534 Files:  drivers/media/video/ovcamchip/*
 535 Why:    Only used by obsoleted v4l1 drivers
 536 Who:    Hans de Goede <hdegoede@redhat.com>
 537
 538 ----------------------------
 539
 540 What:   stv680 v4l1 driver
 541 When:   2.6.35
 542 Files:  drivers/media/video/stv680.[ch]
 543 Why:    obsolete v4l1 driver replaced by gspca_stv0680
 544 Who:    Hans de Goede <hdegoede@redhat.com>
 545
 546 ----------------------------
 547
 548 What:   zc0301 v4l driver
 549 When:   2.6.35
 550 Files:  drivers/media/video/zc0301/*
 551 Why:    Duplicate functionality with the gspca_zc3xx driver, zc0301 only
 552         supports 2 USB-ID's (because it only supports a limited set of
 553         sensors) wich are also supported by the gspca_zc3xx driver
 554         (which supports 53 USB-ID's in total)
 555 Who:    Hans de Goede <hdegoede@redhat.com>