On Tue, Apr 9, 2019 at 9:56 AM shuah <shuah@xxxxxxxxxx> wrote: > > On 4/9/19 10:06 AM, Kees Cook wrote: > > On Mon, Apr 8, 2019 at 2:32 PM shuah <shuah@xxxxxxxxxx> wrote: > >> Couple of things to consider: > >> - will this work on embedded test system with limited applications shell > >> support? > > > > I was assuming the availability of "stdbuf" which is part of > > coreutils, and "perl" which is already required for at least one other > > test (sysctl). What do you have in mind for the "maximum supported > > environment" (and where's best to document this)? Also, I see python > > is used by several tests. Should python be considered instead of perl? > > > >> - It does add dependecy on perl for running tests - not a problem since > >> kernel build system uses it, however it might not be the case when > >> tests get run on system without perl. > > > > I could likely rewrite the "prefix.pl" in C, and the test could use a > > built binary instead? Or in python (as noted above). Where are tests > > being run right now with such a limited environment? > > > > Some embedded systems as I recall with just busybox env. I am thinking > shell rather C/perl/python. It can't be done with shell alone if we want to retain the unbuffered output. Don't we already ship binaries in this situation, though? (i.e. such environments clearly aren't building test binaries...) Why not also ship kselftest binaries? -Kees -- Kees Cook
