From: Paul Moore <paul@paul-moore.com>
To: Richard Haines <richard_c_haines@btinternet.com>
Cc: selinux@vger.kernel.org
Subject: Re: [PATCH V2 1/2] selinux-testsuite: Add BPF tests
Date: Mon, 12 Aug 2019 18:48:59 -0400 [thread overview]
Message-ID: <CAHC9VhQixcQ2x+YLXCWZnS8Cf+wAaeTBJb9JZb8sdQR-TH97Tg@mail.gmail.com> (raw)
In-Reply-To: <644be7b7811eb9d19a55af7a13602961d138cf47.camel@btinternet.com>
On Sun, Aug 11, 2019 at 11:33 AM Richard Haines
<richard_c_haines@btinternet.com> wrote:
> On Fri, 2019-08-09 at 17:55 +0100, Richard Haines wrote:
> > On Fri, 2019-08-09 at 11:22 -0400, Paul Moore wrote:
> > > On Thu, Aug 1, 2019 at 7:12 AM Richard Haines
> > > <richard_c_haines@btinternet.com> wrote:
> > > > This adds basic BPF tests for map and prog functions.
> > > >
> > > > The check-syntax script has been modified to exclude files listed
> > > > in tools/chk_c_exclude. This is because of macros in bpf_common.c
> > > > that get horribly reformatted by check-syntax.
> > > >
> > > > Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
> > > > ---
> > > > V2 Change - Split BPF code into bpf_common.c for others to use.
> > > >
> > > > README.md | 4 +-
> > > > defconfig | 5 +++
> > > > policy/Makefile | 4 ++
> > > > policy/test_bpf.te | 77 ++++++++++++++++++++++++++++++++
> > > > tests/Makefile | 4 ++
> > > > tests/bpf/.gitignore | 2 +
> > > > tests/bpf/Makefile | 12 +++++
> > > > tests/bpf/bpf_common.c | 99
> > > > ++++++++++++++++++++++++++++++++++++++++++
> > > > tests/bpf/bpf_test.c | 83 +++++++++++++++++++++++++++++++++++
> > > > tests/bpf/test | 57 ++++++++++++++++++++++++
> > > > tools/check-syntax | 2 +-
> > > > tools/chk_c_exclude | 1 +
> > > > 12 files changed, 348 insertions(+), 2 deletions(-)
> > > > create mode 100644 policy/test_bpf.te
> > > > create mode 100644 tests/bpf/.gitignore
> > > > create mode 100644 tests/bpf/Makefile
> > > > create mode 100644 tests/bpf/bpf_common.c
> > > > create mode 100644 tests/bpf/bpf_test.c
> > > > create mode 100755 tests/bpf/test
> > > > create mode 100644 tools/chk_c_exclude
> > >
> > > ...
> > >
> > > > diff --git a/tools/check-syntax b/tools/check-syntax
> > > > index 7f9768d..5b7c211 100755
> > > > --- a/tools/check-syntax
> > > > +++ b/tools/check-syntax
> > > > @@ -11,7 +11,7 @@
> > > > #
> > > >
> > > > CHK_C_LIST="$(find tests/ -name "*.c") $(find tests/ -name
> > > > "*.h")"
> > > > -CHK_C_EXCLUDE=""
> > > > +CHK_C_EXCLUDE="$(cat tools/chk_c_exclude)"
> > > >
> > > > CHK_PERL_LIST="$(find tests/ -name "*.pl") $(find tests/ -name
> > > > "test")"
> > > > CHK_PERL_EXCLUDE=""
> > > > diff --git a/tools/chk_c_exclude b/tools/chk_c_exclude
> > > > new file mode 100644
> > > > index 0000000..20facbf
> > > > --- /dev/null
> > > > +++ b/tools/chk_c_exclude
> > > > @@ -0,0 +1 @@
> > > > +tests/bpf/bpf_common.c
> > >
> > > Why are we excluding bpf_common.c from the style checks?
> >
> > Because check-syntax reformats a macro and it is not neat and tidy
> > said Mr Neat to Mr Tidy
I was in the middle of writing a response that pushed the Mr Neat and
Mr Tidy joke to the straining point and I decided I couldn't take it
anymore ... and if I can endure my own response, how could I expect
anyone else to do it? ;)
Regardless, the problem is that style is horribly subjective, and I
really hate getting bogged down in those sorts of arguments (witness
the recent on-list discussion of comment styles) so I added the
"check-syntax" tool to settle those arguments. You run the code
through the tool, and that's your answer. Period. (I suppose it
might be "full stop" for Mr Neat and/or Mr Tidy.) Does that mean I
always like the output of the tool? No, sometimes it makes a mess of
things[1], but I'd rather have that then on-list arguments about
style.
[1] In the past I've fixed the really bad check-syntax output by
tweaking the input code ever so slightly.
> Just a thought - The patches run the fdreceive with bpf support before
> the core bpf test. I could resubmit the patches to test core bpf first
> ?? (and allow Mr Messy to format the macros in bpf_common.c)
That gets to another thing that bothers me slightly ... I didn't
mention it earlier because of the test failure, the style issue, and
lack of time, but I'm not sure what I feel about splitting the BPF
tests up like that. Duplicating code isn't a great solution either.
Thoughts?
--
paul moore
www.paul-moore.com
next prev parent reply other threads:[~2019-08-12 22:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-01 11:12 [PATCH V2 1/2] selinux-testsuite: Add BPF tests Richard Haines
2019-08-09 15:22 ` Paul Moore
2019-08-09 16:55 ` Richard Haines
2019-08-11 15:33 ` Richard Haines
2019-08-12 22:48 ` Paul Moore [this message]
2019-08-13 12:05 ` Richard Haines
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=CAHC9VhQixcQ2x+YLXCWZnS8Cf+wAaeTBJb9JZb8sdQR-TH97Tg@mail.gmail.com \
--to=paul@paul-moore.com \
--cc=richard_c_haines@btinternet.com \
--cc=selinux@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).