On Fri, Nov 22, 2019 at 12:42:49PM +0100, Heinrich Schuchardt wrote: > 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. > > > > Soeren > > > > > Hello Soeren, > > what is your view on changing CONFIG_ENV_OFFSET=0x60000 to > CONFIG_ENV_OFFSET=0xC0000?
I am still against that move as we need to address the real underlying problem of size growth. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot