On Fri, Oct 29, 2021 at 01:20:52PM +0300, Ilias Apalodimas wrote: > Hi Simon, > > [...] > > > > > > > > > Why me? Perhaps Linaro could take this on instead of working in a > > > > separate tool and domain? You guys could really pull things together > > > > and reduce the fragmentation, if you took it on. > > > > > > > > Honestly it is hard enough to even get Linaro people to write a test > > > > for code they have written. What gives? > > > > > > That's completely inaccurate. We've added selftests for *every* > > > single feature we've sent for EFI up to now. Functionality wise the > > > past 2 years we've added > > > - EFI variables > > > - EFI secure boot > > > - capsule updates > > > - initrd loading > > > - efi TCG protocol > > > - ESRT tables > > > - RNG protocol > > > > > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests > > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() > > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() > > > ce62b0f8f45f1 test/py: Fix efidebug related tests > > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule > > > de489d82e3189 test: test the ESRT creation > > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test > > > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates > > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load > > > initramfs > > > > > > and I am pretty sure I am forgetting more on functionality and selftests. > > > > > > So basically we've either contributed new selftests for *everything* > > > we've or fixed the existing ones. The only thing that's not merged is > > > the TCG selftests which are on upstream review. > > > > Er, I didn't say or mean that no tests were written, just that there > > is too much push-back on it. Heinrich put a huge amount of effort into > > There's no pushback at all, apart from the TPM one. (and for a very good > reason I've explained over and over again). In fact we add the sefltests > as part of our patchsets.
And, for that set of TPM things, I agree with NOT making sandbox the requirement there. As QEMU is able to provide a TPM that will see real world usage, that's what we need to validate against primarily. > > the tests and basically created a strong base for it. Congrats and > > huge kudos to him. As to Linaro, no offence intended, and it is great > > that all these tests have been added. Thank you for your efforts and > > it is very helpful. But I think you miss my point. Or perhaps you > > don't even agree with it? I sent an email about this on one patch just > > a day or two ago. > > I guess you mean [1]. I've lost count of how many times I responded to > this. Threads [2], [3] and [4] are just a few examples, so I just got > tired or replying the same thing over and over. > > So bottom line, we are contributing selftests as always, we just don't agree > with the way *you* want this specific TPM test, trying to force us into > sandbox. > So instead of respecting what we have (which btw is acceptable from u-boot's > perspective and cleans up a lot of the TPM crud along the way), you went ahead > making misleading statements on the selftests we contribute, in general. > What's > even more annoying is that, as I showed you, we pretty much add a selftest > for *every* feature we add. Excellent ... that's certainly ... encouraging > ... and > very productive. > > > > > As to the leadership side (my bigger point), Linaro is leading us all > > down this fragmented path, with TF-A, FIP, more and more binaries and > > larger firmware diagrams. Or do you disagree with that too? > > > > Of course I disagree. People decided not to use SPL for their own reasons. > I am certainly not qualified to answer why Arm choose to do that, but it seems > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure > U-Boot is compatible and remains the de-facto choice for embedded boot > loaders playing nicely with all the new FSBLs come up with. If you > cosinder SPL and U-Boot the center of the known universe, we certainly view > things differently. FWIW it's *our* work mostly that made U-Boot SystemReady > compliant, which is something Arm pushes for [5]. Let me say for the record that I am appreciative of the fact the Linaro has been putting so much effort in to U-Boot, both in terms of tests and also in general SystemReady compliance work. -- Tom
signature.asc
Description: PGP signature
