From: shuah at kernel.org (shuah)
Subject: [PATCH] selftests/lib.mk: Move test output to diagnostic lines
Date: Tue, 9 Apr 2019 10:56:10 -0600 [thread overview]
Message-ID: <d0647ccf-b2a2-8fd4-adc4-16914b68ffbf@kernel.org> (raw)
In-Reply-To: <CAGXu5j+_b-w+e_4rn1D5zH=KF_O=ktz-xV3hEFd1cqSmcWpWhQ@mail.gmail.com>
On 4/9/19 10:06 AM, Kees Cook wrote:
> On Mon, Apr 8, 2019 at 2:32 PM shuah <shuah at kernel.org> 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.
>> - there is the emit_tests support that creates a shell script that runs.
>> The results format should stay the is same when tests get run using
>> run_tests vs. tests are built and installed. Take a look at emit_tests
>> and EMIT_TESTS in Makefile and lib.mk
>
> Ah yeah. I will adjust EMIT_TESTS too.
>
> Thanks!
>
thanks,
-- Shuah
WARNING: multiple messages have this Message-ID (diff)
From: shuah@kernel.org (shuah)
Subject: [PATCH] selftests/lib.mk: Move test output to diagnostic lines
Date: Tue, 9 Apr 2019 10:56:10 -0600 [thread overview]
Message-ID: <d0647ccf-b2a2-8fd4-adc4-16914b68ffbf@kernel.org> (raw)
Message-ID: <20190409165610.XUJ9ERg0rPaUh5AmOUedjv9q0Hblwdy1ZTv1YS-Zc2I@z> (raw)
In-Reply-To: <CAGXu5j+_b-w+e_4rn1D5zH=KF_O=ktz-xV3hEFd1cqSmcWpWhQ@mail.gmail.com>
On 4/9/19 10:06 AM, Kees Cook wrote:
> On Mon, Apr 8, 2019@2:32 PM shuah <shuah@kernel.org> 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.
>> - there is the emit_tests support that creates a shell script that runs.
>> The results format should stay the is same when tests get run using
>> run_tests vs. tests are built and installed. Take a look at emit_tests
>> and EMIT_TESTS in Makefile and lib.mk
>
> Ah yeah. I will adjust EMIT_TESTS too.
>
> Thanks!
>
thanks,
-- Shuah
next prev parent reply other threads:[~2019-04-09 16:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-08 20:30 [PATCH] selftests/lib.mk: Move test output to diagnostic lines keescook
2019-04-08 20:30 ` Kees Cook
2019-04-08 21:32 ` shuah
2019-04-08 21:32 ` shuah
2019-04-09 16:06 ` keescook
2019-04-09 16:06 ` Kees Cook
2019-04-09 16:56 ` shuah [this message]
2019-04-09 16:56 ` shuah
2019-04-09 16:57 ` keescook
2019-04-09 16:57 ` Kees Cook
2019-04-09 17:04 ` shuah
2019-04-09 17:04 ` shuah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d0647ccf-b2a2-8fd4-adc4-16914b68ffbf@kernel.org \
--to=unknown@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.