public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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>

  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