[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Sören Moch]

On 10.01.19 16:53, Tom Rini wrote:
> On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
>> Hi Tom, Soeren,
>>
>> On 09/01/19 23:39, Tom Rini wrote:
> [snip]
>>>  Why default?  Well, "everyone"
>>> agrees that defaulting to EFI application support means the widest
>>> choice of out of the box software support.
>> I am unsure about this - just my two cents.
>>
>> I agree with you if we are talking about evaluation boards and / or
>> boards supposed to run different distros (or in any case, more flavour
>> of software).
>>
>> But there are a lot of "custom" boards (maintained in U-Boot) that runs
>> for a specific project and won't run any other kind of software. If a
>> device is a navigation system, a network controller, or whatever, it
>> will just do this job until its EOL.
>>
>> Specially for older boards, a new feature should not be activated as
>> default. At the beginning, police in U-Boot was to set just what should
>> be required in the bootloader, without setting what is not needed as
>> default. So default was off instead of on.
> So, part of what I'm taking away from all of this is that I really do
> need to see how many people I can bcc at once before gmail gets really
> mad at me,  Yes, there's a number of end-user devices we have support
> for in mainline that are intended to be re-used as the manufacturer
> intended.  Part of the Kconfig migration means that they can more easily
> remove stuff they don't want/need than before.  But there's also the
> repurposed boards, and lots of not really clear cut cases, such as the
> tbs2910 where while it's not my call, does fall into the "enable EFI
> loader support for your end users maybe?" category.  And in the end, I
> should have emailed off everyone with a gentle reminder to inspect and
> trim their configs.
>
My view on this:

The overwhelming majority of users use u-boot as _bootloader_, not as
their favorite toy to play around with every two month. Users want
stable software with bugfixes, not fancy new untested features. For a
lot of users it is a real pain if linux does not boot anymore. Often
u-boot updates are done from a running linux system. Often users don't
have access to serial adapters to re-animate bricked boards (e.g. they
are sold separately for tbs2910).

So I really prefer new features disabled on old boards. 'default y' may
be good to include modern features for new platforms. But for old boards
then include "# CONFIG_WHATEVER is not set" in defconfigs.

Let board maintainers do their job in testing new features and activate
them when properly tested on their platform and found useful. Recently a
lot of code is committed to u-boot by the original author without any
reviewed-by or tested-by tags. We should not force the testing effort on
ordinary users by activation of new features by default. Otherwise for
me the risk is too high to rendering user systems un-bootable just by
updating "stable" u-boot releases.

For me the real advantage of Kconfig is that interested users can
_enable_ new features easily, test this and maybe propose as new
defconfig to board maintainers. So there is no disadvantage for
experienced users, and no harm for users that only follow available
howtos and are not able to handle sudden changes in behavior.

Regards,
Soeren