Dear Francois, it would have been _very_ helpful to keep the Subject: and the Cc: list in place.
In message <CAHFG_=vhn3ytyxozqsmbg52gp5wkfiax1vgugc6xwishln_...@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 -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Q: Why do PCs have a reset button on the front? A: Because they are expected to run Microsoft operating systems. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
