On Thu, 2015-06-25 at 11:05 -0400, Peter Jones wrote: > The thing is, *all* the library does is provide a C API for interactions > with firmware. So that's really what "make test" exercises, which is > why a) it's more useful for "did my changes break anything" during > development than anything else, b) it just shouldn't be run in a normal > package build, and c) it trips up on firmware interaction a lot when the > firmware isn't very mature. The best way to avoid b) is to rename it to something other than "test" or "check" since Debian and probably other distros automatically run those make targets. Some possible alternative options: make developer-tests make maybe-break-my-system-please ;) > > It might also be interesting for edk2 (ovmf/qemu-efi) to run efivar to > > test themselves. > > Yeah, that's definitely a good idea. My plan for "make test" has been... Sounds good, thanks. OVMF/AAVMF is unfortunately non-free due to the FAT driver license. How are RedHat, Linaro etc dealing with that issue? We had a really interesting discussion about hardware/firmware testing on the debian-derivatives list recently, folks interested in that sort of stuff might be interested in looking at these links: http://biosbits.org/ https://launchpad.net/fwts https://github.com/chipsec/chipsec https://github.com/01org/luv-yocto http://www.inquisitor.ru/doc/einarc/ http://www.phoronix-test-suite.com/ https://bugs.debian.org/748783 The discussion was in the Inquisitor thread here: https://lists.debian.org/debian-derivatives/2015/06/threads.html#00020 -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part