On 11/22/19 11:29 AM, Soeren Moch wrote: > > > On 22.11.19 04:58, 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. > > What a long discussion over night, so only a general answer: > > Once upon a time there was plenty of space for tbs2910 u-boot. > Then we had to convert everything to DM, for whatever reason. This > increased the binary size a lot, had absolutely no advantage for u-boot > users, was huge effort for board maintainers, and is still going on. > (DM_VIDEO conversion still pending for this board, probably more to > come, DM_SERIAL?). For all that additional space is required, apparently > nobody tries to cleanup the non-DM code for converted subsystems to > reclaim some of the space. > > Several times I tried to disable unneeded functions to trim the binary > size. After a few weeks the gained space was eaten up, apparently nobody > cares about binary size anymore as long as there is no build failure. > Even worse, since imx format is padded, people claim to not increase the > binary size with there patches (what in fact is not true), and then some > simple change / tool update again breaks everything. > > What is the solution to that? I don't see much what _I_ can do. If I > find some option to disable again, what is increasingly difficult, then > this removes the last opportunity for upcoming DM conversions. > For the "bloat" vs. "features" discussion: on long existing boards no > user expects new features in defconfig, especially if they only come > with reduced functionality somewhere else. And as hobbyist board > maintainer I don't know which features existing users actually use. I > only get bug reports about bricked boards when something is missing.
Thank you for spelling this out, I fully agree with these sentiments. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
