On Sun, Feb 17, 2013 at 6:02 PM, Wolfgang Denk <[email protected]> wrote: > Dear Otavio Salvador, > > In message > <cap9odkr3xau_vg7ygjyosntd03yvlaygrdszc-y4jqgdi+d...@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). > > [1] http://article.gmane.org/gmane.linux.kernel/1414106
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. -- Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
