[PATCH v5 00/25] passage: Define a standard for firmware data flow

[Tom Rini]

On Wed, May 28, 2025 at 05:08:38PM +0100, Simon Glass wrote:
> Hi Tom,
> 
> On Wed, 28 May 2025 at 16:19, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Wed, May 28, 2025 at 03:32:12PM +0100, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Wed, 28 May 2025 at 15:25, Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Wed, May 28, 2025 at 06:32:02AM -0600, Simon Glass wrote:
> > > > >
> > > > > This series adds a standard way of passing information between different
> > > > > firmware phases. This already exists in U-Boot at a very basic level, in
> > > > > the form of a bloblist containing an spl_handoff structure, but the intent
> > > > > here is to define something useful across projects.
> > > > >
> > > > > The need for this is growing as firmware fragments into multiple binaries
> > > > > each with its own purpose. Without any run-time connection, we must rely
> > > > > on build-time settings which are brittle and painful to keep in sync.
> > > > >
> > > > > This feature is named 'standard passage' since the name is more unique
> > > > > than many others that could be chosen, it is a passage in the sense that
> > > > > information is flowing from one place to another and it is standard,
> > > > > because that is what we want to create.
> > > > >
> > > > > The implementation is mostly a pointer to a bloblist in a register, with
> > > > > an extra register to point to a devicetree, for more complex data. This
> > > > > should cover all cases (small memory footprint as well as complex data
> > > > > flow) and be easy enough to implement on all architectures.
> > > > >
> > > > > The emphasis is on enabling open communcation between binaries, not
> > > > > enabling passage of secret, undocumented data, although this is possible
> > > > > in a private environment.
> > > > >
> > > > > To try this out:
> > > > >
> > > > > $ ./scripts/build-qemu -a arm -rsx
> > > > >
> > > > > This will build and run QEMU for arm64 and you should see the standdard
> > > > > passage working:
> > > > >
> > > > >    Core:  49 devices, 13 uclasses, devicetree: passage
> > > > >
> > > > > This series is available at u-boot-dm/pass-working
> > > > >
> > > > > Changes in v5:
> > > > > - Add RFC for test script
> > > >
> > > > And this is why I question if you are working in good faith. I've
> > > > rejected this countless times. I'm still rejecting it. Stop including
> > > > it. Point at the version you could easily be maintaining in the contrib
> > > > repository where you have write access and no one will be telling you to
> > > > not do something. People would even review the patches since it would be
> > > > against mainline.
> > >
> > > I fully understand that you don't want the script and I'm only
> > > including (as an RFC) so people can actually try this series out. I
> > > didn't want to point to my tree as I thought that would annoy you. I
> > > already went through why the contrib tree is not suitable for me.
> >
> > So I have to take changes that I disagree with, but you can't work with
> > a tree for your tooling where the community would be happy to provide
> > feedback? That does not sound like compromise. Again, I have trouble
> > believing that you are working in good faith to resolve the differences
> > here.
> 
> Yes, as mentioned before I would like you to take changes you disagree
> with, at least once we have discussed alternatives and I'm sure that's
> the way I want to go. It would save a lot of grief if you could do
> that.
> 
> I could use your contrib/ repo but there isn't a lot of point, since I
> have to have my own tree anyway, due to rejected / changes-requested
> patches. It's just lots of fiddling around for no gain. I'm fine with
> your not having the scripts in your tree and I'm fine with maintaining
> the Python tools in my tree. Basically it seems my tree is the dumping
> ground for the stuff you don't want in 'pure U-Boot', or don't want
> yet. If you would like me to sync my scripts to the contrib/ tree
> every now and then, yes I can do that. I don't see much point since we
> can't reference them in docs or test them in CI, but I'm willing to do
> it.
> 
> But I do want to post patches so I can get feedback from people who
> are interested. Perhaps we could set up an 'experimental' mailing list
> for that, since you seem really unhappy when I send them to the U-Boot
> mailing list?
> 
> Re your 'good faith' thing, I'm really just trying to make progress
> and I wish there was less 'email overhead' and more action. If you
> have concerns, it would be better to discuss a resolution f2f or on a
> VC, not endless email threads which don't relate to the patches I'm
> sending. The series we are discussing here was sent in 2021 based on
> bloblist from 2018! [1]. It is why Firmware Handoff happened. Give me
> some credit for foresight, at least.

You need to decide if it's more important to work with the community or
have your way every time. You cannot have both. You need to accept that
some things you think are good ideas have been rejected or you need to
fork off from U-Boot. Or you can ask the community to take over as the
project head. If the community wants you to run things, I will step
down and just be an individual contributor again. Five months of this
experiment shows me that it's not working at all and will only be a
bigger problem as time goes on.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250528/772bbc5c/attachment.sig>