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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
