On Sun, Feb 17, 2013 at 6:02 PM, Wolfgang Denk wd@denx.de wrote:
Dear Otavio Salvador,
In message CAP9ODKr3xaU_Vg7YgjYOsntD03YvLaygRdSZC-Y4jQgDi+D7sw@mail.gmail.com you wrote:
include/configs/RPXsuper.h:#define CONFIG_BOOTDELAY -1 include/configs/ep8260.h:#define CONFIG_BOOTDELAY -1 include/configs/espt.h:#define CONFIG_BOOTDELAY -1 include/configs/scb9328.h:#define CONFIG_BOOTDELAY -1 include/configs/sh7763rdp.h:#define CONFIG_BOOTDELAY -1
So maybe those could have CONFIG_BOOTDELAY undefined keeping them working as before?
Yes, they could. But it is a change of a long-standing behaviour, and we try to avoid breaking existing boards. At minimum this needs to be announced, the respective board maintainers need to be modified, and given sufficient time to react.
Yes; I agree but breaking out of tree boards ... well, it is the price of not working upstream so I think it cannot be a blocker for U-Boot improvements and cleanups.
You also change behaviour (and thus potentially break) at least 5 boards in mainline. See also [1] about breaking user space in Linux (which is pretty much equivalent to what would happen here).
I see it different; I understand we cannot break current boards so a patch should also convert the boards to the new behavior.
I also don't see a compare it to user space in Linux fair, I think it'd be more like a driver API change in Linux and Linux breaks API for out of tree drivers very ofthen so I think same fits here.