u-boot/doc/feature-removal-schedule.txt
Wolfgang Denk a2681707b2 Feature Removal: disable "mtest" command by default
The "mtest" command is of little practical use (if any), and
experience has shown that a large number of board configurations
define useless or even dangerous start and end addresses.  If not even
the board maintainers are able to figure out which memory range can be
reliably tested, how can we expect such from the end users?  As this
problem comes up repeatedly, we rather do not enable this command by
default, so only people who know what they are doing will be
confronted with it.

As this changes the user interface, we allow for a grace period
before this change takes effect. For now, we make "mtest"
configurable through the CONFIG_CMD_MEMTEST variable, which is defined
in include/config_cmd_default.h;  we also add an entry to
doc/feature-removal-schedule.txt which announces the removal of this
default setting in two releases from now, i. e. with v2013.07.

Signed-off-by: Wolfgang Denk <wd@denx.de>
Cc: Tom Rini <trini@ti.com>
2013-03-11 15:26:59 -04:00

64 lines
2.4 KiB
Text

The following is a list of files and features that are going to be
removed from the U-Boot source tree. Every entry should contain what
exactly is going away, when it will be gone, why it is being removed,
and who is going to be doing the work. When the feature is removed
from U-Boot, its corresponding entry should also be removed from this
file.
---------------------------
What: Remove CONFIG_CMD_MEMTEST from default list
When: Release v2013.07
Why: The "mtest" command is of little practical use (if any), and
experience has shown that a large number of board configu-
rations define useless or even dangerous start and end
addresses. If not even the board maintainers are able to
figure out which memory range can be reliably tested, how can
we expect such from the end users? As this problem comes up
repeatedly, we rather do not enable this command by default,
so only people who know what they are doing will be confronted
with it.
Who: Wolfgang Denk <wd@denx.de>
---------------------------
What: Users of the legacy miiphy_* code
When: undetermined
Why: We now have a PHY library, which allows everyone to share PHY
drivers. All new drivers should use this infrastructure, and
all old drivers should get converted to use it.
Who: Andy Fleming <afleming@freescale.com> and driver maintainers
---------------------------
What: boards with xxx_config targets in top level Makefile
When: Release v2012.03
Why: We have a boards.cfg file which the vast majority of boards have
converted over to. Boards that still manually run mkconfig in the
top level Makefile are either dead, or the maintainer doesn't care,
or they are doing something weird/wrong that should be fixed in a
different way, or they need to extend boards.cfg syntax (unlikely).
In any case, if no one cares about these boards to figure out how
to make boards.cfg work, then we'll just punt them.
Who: Mike Frysinger <vapier@gentoo.org>
---------------------------
What: GPL cleanup
When: August 2009
Why: Over time, a couple of files have sneaked in into the U-Boot
source code that are either missing a valid GPL license
header or that carry a license that is incompatible with the
GPL.
Such files shall be removed from the U-Boot source tree.
See http://www.denx.de/wiki/pub/U-Boot/TaskGplCleanup/u-boot-1.1.2-files
for an old and probably incomplete list of such files.
Who: Wolfgang Denk <wd@denx.de> and board maintainers