On Sat, Nov 12, 2022 at 08:20:30PM +0100, Borislav Petkov wrote: > On Sat, Nov 12, 2022 at 10:21:35AM -0800, Thiago Macieira wrote: > > Not exactly. That's what this file is there for. It allows the algorithm to > > read the current batch file, add 1, then echo back. If the load succeeds, the > > the batch exists; if not, then the algorithm should simply go back to 0. > > This sounds to me like there's a special order in which those batches > should be executed? There is no special sequence required. Idea is that user would like to run all tests, so simply going through them works. User has no idea what the test content is for each file, unless there is a case where they like to repeat a specific batch on one core, they can simply skip and do one specific batch, they don't need to go through in sequence. > > I thought they're simply collections of test sequences which can be run > in any order... > > > First, there's the question of the ability to see into /lib/firmware. I'm not a > > kernel dev but I'm told that request_firmware() only operates on the root > > container's filesystem view. We're expecting that the application may get > > deployed as a container (with full privileges so it can write to /sys, sure), > > so it won't be able to see the host system's /lib to know what files are > > available. It could "guess" at the file names, based on the current processor's > > family/model/stepping and a natural number, but that's sub-optimal. > > It is not about seeing - you simply give it the filename - > request_firmware* does the "seeing". Either the file's there or it > isn't. Link to Tony's last post before changing the file formats to accomodate Greg's feedback. https://lore.kernel.org/lkml/SJ1PR11MB6083263E8EEBF106B6B61B24FC969@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ Cheers, Ashok
