All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.