diff options
| author | Wolfgang Denk <wd@denx.de> | 2013-03-08 10:51:32 +0000 |
|---|---|---|
| committer | Tom Rini <trini@ti.com> | 2013-03-11 15:26:59 -0400 |
| commit | a2681707b2478abef34b8c403e7ab52daae9c331 (patch) | |
| tree | 5f3893c85d1122fb9734eb8406e75b70b89264b8 /doc/feature-removal-schedule.txt | |
| parent | c02bff361794cff181bd3eca0ec1edce636f8dd4 (diff) | |
| download | blackbird-obmc-uboot-a2681707b2478abef34b8c403e7ab52daae9c331.tar.gz blackbird-obmc-uboot-a2681707b2478abef34b8c403e7ab52daae9c331.zip | |
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>
Diffstat (limited to 'doc/feature-removal-schedule.txt')
| -rw-r--r-- | doc/feature-removal-schedule.txt | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/doc/feature-removal-schedule.txt b/doc/feature-removal-schedule.txt index e04ba2dda5..d9a0cc267b 100644 --- a/doc/feature-removal-schedule.txt +++ b/doc/feature-removal-schedule.txt @@ -7,6 +7,23 @@ 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 |
