On Fri, Nov 22, 2019 at 04:58:29AM +0100, Marek Vasut wrote:
On 11/22/19 4:41 AM, Tom Rini wrote: [...]
>>>> I believe >>>> the specific changes in question that once again push this board over >>>> fall in to that grey area. Whatever size-trimming the board maintainer >>>> is fine with next is fine with me, but needs to get ack'd by someone. >>> >>> Or, the other option is, make these new extra features configurable and >>> disable them on this board. And so there should be no size problem. >> >> But that direction leads to saying every slight bit of functionality >> requires a new Kconfig entry. Some levels of bugfixes as well. > > The other option is, we will sink in bloat and suffer endless size problems.
Yes, it is a hard balancing act. Stepping back, perhaps a "minimal" or "complete" choice for USB HID devices would make sense and allow us further areas to reduce size, on the minimal portion.
Or maybe there is a way to help compiler optimize that USB key code handling better.
Perhaps. But my point is that every little functional change or enhancement does not need a Kconfig option.
Except this leads to slow and steady accumulation of bloat, and as we already see for quite a while, this is problematic for more and more boards.
And "bloat" and "features" are interchangable terms.
Nope, bloat is unhelpful growth of size, features are actually helpful/useful.
I really am trying to be more responsive than ever to size growth in common, rather than board specific areas. And I agree, some investigation in to ways that might reduce the size of binary support for USB HID devices is good.
So we agree that's what this series should fix ?
Figuring out if we can make this series: http://patchwork.ozlabs.org/project/uboot/list/?series=135448 not also increase the overall size, or increase it less, is good. Hiding the content of 2/5 behind a CONFIG option in turn brings us back to "the code is too messy and full of #ifdef" lines.
Which might be somewhat better than if the code is sprinkled with tiny chunks of random pieces of code which are never used, but in total add up to a lot of unused code in the binary.
If, with your USB custodian hat on, your answer to Heinrich is that his changes expose a more fundamental problem with the code that needs addressing then no, I'm not overriding your objection.