From: Richard Haines <firstname.lastname@example.org> To: Paul Moore <email@example.com> Cc: firstname.lastname@example.org Subject: Re: [PATCH V2 1/2] selinux-testsuite: Add BPF tests Date: Tue, 13 Aug 2019 13:05:29 +0100 Message-ID: <email@example.com> (raw) In-Reply-To: <CAHC9VhQixcQ2x+YLXCWZnS8Cf+wAaeTBJb9JZb8sdQR-TH97Tg@mail.gmail.com> On Mon, 2019-08-12 at 18:48 -0400, Paul Moore wrote: > On Sun, Aug 11, 2019 at 11:33 AM Richard Haines > <firstname.lastname@example.org> 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 > > > > <email@example.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 < > > > > > firstname.lastname@example.org> > > > > > --- > > > > > 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, but I'd rather have that then on-list arguments about > style. > >  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? > I can only think of two options: 1) If BPF, build tests/fdreceive and tests/binder services with bpf_common services, then in tests/bpf run the appropriate tests (by setting $fdr_basedir = "$basedir/../fdreceive/"; etc.). 2) For fdreceive I would only need to replicate and modify the client, therefore putting this code and test under the main bpf is not a problem. For binder I would probably need to copy 90% of the code, unless I can find an easier test (although with binder, you have to do a bit just to get going). Option 1 seems best.
prev parent reply index Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-01 11:12 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 2019-08-13 12:05 ` Richard Haines [this message]
Reply instructions: You may reply publically 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
SELinux Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/selinux/0 selinux/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 selinux selinux/ https://lore.kernel.org/selinux \ email@example.com firstname.lastname@example.org public-inbox-index selinux Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.selinux AGPL code for this site: git clone https://public-inbox.org/ public-inbox