[PATCH 00/52] expo: Various features and improvements

[Simon Glass]

Hi Tom,

On Thu, 27 Mar 2025 at 08:17, Tom Rini <trini at konsulko.com> wrote:
>
> On Thu, Mar 27, 2025 at 07:36:02AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 25 Mar 2025 at 10:24, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Fri, Mar 21, 2025 at 07:38:45PM +0100, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 20 Mar 2025 at 15:21, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Thu, Mar 20, 2025 at 03:39:26AM +0000, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Wed, 19 Mar 2025 at 15:57, Tom Rini <trini at konsulko.com> wrote:
> > > > > > >
> > > > > > > On Wed, Mar 19, 2025 at 03:54:05PM +0100, Simon Glass wrote:
> > > > > > >
> > > > > > > > This series collects together some new features for expo to make it more
> > > > > > > > useful for boot menus:
> > > > > > > >
> > > > > > > > - measurement and display of multi-line text objects
> > > > > > > > - internal alignment for objects (e.g. centred text)
> > > > > > > > - editable strings in text fields
> > > > > > > > - new 'box' object to draw a rectangle
> > > > > > > > - highlighting of menu items, rather than just relying on a pointer
> > > > > > > >
> > > > > > > > Expo's boot menu is restructured so that it is possible to iterate
> > > > > > > > through various bootdevs and update the menu as new ones are found. This
> > > > > > > > is more in keeping with how bootstd works.
> > > > > > > >
> > > > > > > > A new textedit object is added, intended to provide a simple text
> > > > > > > > editor. Future work will complete this.
> > > > > > > >
> > > > > > > > With this series the boot menu has a better layout and appearance.
> > > > > > > >
> > > > > > > >
> > > > > > > > Simon Glass (52):
> > > > > > >
> > > > > > > I see you haven't internalized the "don't post massive series" feedback
> > > > > > > yet. Please, stop posting massive patch series. Figure out how to
> > > > > > > logically break things down in to smaller chunks that can be
> > > > > > > meaningfully reviewed.
> > > > > >
> > > > > > I could split this into two series of ~25 patches, perhaps. Would that be OK?
> > > > > >
> > > > > > I believe no one else is using expo yet, apart from postmarketOS,
> > > > > > except the trivial case of 'bootflow scan -m' but I'm hoping that will
> > > > > > change in the future. I believe that Linaro is mostly encouraging EFI
> > > > > > bootmgr and the text-based menu. That could be converted to use expo
> > > > > > but I doubt anyone has looked into that, particularly as grub is being
> > > > > > pushed as well. I did look at converting the existing menu code a year
> > > > > > or two ago, but it seemed better to eventually deprecate it.
> > > > > >
> > > > > > Also, there is a following series which I split out and will post
> > > > > > separately, but not for a while as I have a lot outstanding.
> > > > > >
> > > > >
> > > > > It would make sense to split expo out to its own series as there's not
> > > > > likely to be any feedback there. All of the other parts of the series
> > > > > already have something else in their subject and that would be logical
> > > > > places to split this up more and then assign to the appropriate
> > > > > custodian. Thanks.
> > > >
> > > > This is the expo series and it only has expo patches, so I believe we
> > > > are OK there.
> > > >
> > > > The bootstd series is small and its own thing.
> > >
> > > OK.
> > >
> > > > I can split up the strim() / test series,
> > >
> > > OK.
> > >
> > > > but I'm still unsure what
> > > > you are asking for with respect to code which is not yet used. I can't
> > > > reasonably do all of a) send code only when it is needed by later
> > > > patches in the series and b) keep series sizes small and c) keep
> > > > series related to a single topic.
> > >
> > > I don't see why you can't do that. It is in fact really hard to review
> > > how useful some library functions you write without seeing how they're
> > > used and if in turn we should be doing something different. You might
> > > need to defer or break out as it's own some refactoring changes in order
> > > to meet 'b' above. However "here is a thing" and "here's using a thing"
> > > are still a single topic.
> >
> > You could just review the code itself, perhaps, rather than worrying
> > whether it will never be used? For me, creating and maintaining a
> > series through acceptance into your tree is still a lot of effort,
> > unfortunately.
>
> No, that's a no-go. Reviewing a library without knowing how it's going
> to be used is not effective.
>
> > While on that topic, it seems that the sunxi and rpi series have still
> > not been applied to your tree. It would really help to see some
> > movement on those after all these months.
>
> I provided a detailed explanation of what's still wrong with the sunxi
> series.

>From what I recall this is that you want Heinrich to do a workaround
with bootmgr and bootstd, but you don't want to disable bootmgr from
sunxi. In either case, there's nothing I can do here. The series is
probably getting more and more out of date anyway. Andre might pick it
up, but I doubt it, given all the arguments about it.

> The Pi maintainers are still actively working their way through
> things.

Is there any ETA?

I'm sending a v2 of this series as I found some other problems.

Regards,
Simon