From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Maximum size of u-boot.imx for TBS2910 board
Date: Fri, 22 Nov 2019 10:44:28 -0500 [thread overview]
Message-ID: <20191122154428.GE971@bill-the-cat> (raw)
In-Reply-To: <c717ddcd-bed8-ccbe-cbc7-3999c0abee4a@denx.de>
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.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191122/10714276/attachment.sig>
next prev parent reply other threads:[~2019-11-22 15:44 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-21 20:09 [U-Boot] Maximum size of u-boot.imx for TBS2910 board Heinrich Schuchardt
2019-11-21 20:12 ` Tom Rini
2019-11-21 21:59 ` Heinrich Schuchardt
2019-11-21 22:01 ` Marek Vasut
2019-11-21 22:45 ` Tom Rini
2019-11-22 0:23 ` Marek Vasut
2019-11-22 0:32 ` Tom Rini
2019-11-22 1:27 ` Marek Vasut
2019-11-22 1:30 ` Tom Rini
2019-11-22 1:38 ` Marek Vasut
2019-11-22 2:53 ` Tom Rini
2019-11-22 2:56 ` Marek Vasut
2019-11-22 3:41 ` Tom Rini
2019-11-22 3:58 ` Marek Vasut
2019-11-22 10:29 ` Soeren Moch
2019-11-22 11:42 ` Heinrich Schuchardt
2019-11-22 12:30 ` Tom Rini
2019-11-22 12:18 ` Marek Vasut
2019-12-06 11:41 ` Stefano Babic
2019-12-06 12:30 ` Anatolij Gustschin
2019-12-06 14:02 ` Tom Rini
2019-12-06 16:18 ` Soeren Moch
2019-12-06 16:43 ` Soeren Moch
2019-11-22 15:44 ` Tom Rini [this message]
2019-11-22 18:31 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191122154428.GE971@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox