Dear Francois,
it would have been _very_ helpful to keep the Subject: and the Cc: list in place.
In message CAHFG_=Vhn3YtyxOZQSMbG52Gp5wkfiAx1VguGC6XwishLN_zHg@mail.gmail.com you wrote:
On one side we have UEFI have objects that can be persistent and/or secure. More importantly, a UEFI application can register a storage backend to perform UEFI variable persistence on specific hardware. This facility is used to manage persistent/secure variables in TrustZone. Verification of secure variables can also depend on application registered UEFI protocols: we would import the new security protocol, or the hardware accelerated protocol verification in the U-Boot UEFI environment rather than re-implement the U-Boot way.
I can understand yoiur argument, but I'm not happy about it. Why implement a UEFI only way, when it seems it would be possible to have a slotion that is useful for others, too? This is an narrow-minded, sellfish approach and not commuinity-oriented. And I don;t think you can save any efforts that way.
On the other side, U-Boot has a super lightweight variable system that is used to control boot sequence and hence variable performance has an impact on boot delay and jitter.
Ideed.
Because the UEFI variables has additional dependencies on those other UEFI constructs (protocol registration for storage back end, crypto and signature stuff for secure variables) and its easier to allow code import from other UEFI implementations, I would tend to segregate u-boot variables from UEFI objects (I think the term object is more appropriate). In other words UEFI objects shall be say self-contained in the UEFI "subsystem".
Your decision, then. But in this case the submitted pacches make no sense either, and should be discarded.
Combined with the performance goal, and code size (if we do not want the UEFI stuff), I have a second reason to keep them separate.
To be honest - fast boot times and UEFI have always been an oxymoron to me. What is the performance goal you mention?
Best regards,
Wolfgang Denk