From: Steve Grubb <sgrubb@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>, Paul Moore <paul@paul-moore.com>
Cc: linux-audit@redhat.com
Subject: Re: [PATCH v2] audit: report audit wait metric in audit status reply
Date: Thu, 03 Dec 2020 18:55:49 -0500 [thread overview]
Message-ID: <20883376.EfDdHjke4D@x2> (raw)
In-Reply-To: <CAHC9VhR91u2VKy3RwxB4_bs3GdZupyq6oWKg5hPvacssc6tuOQ@mail.gmail.com>
On Thursday, December 3, 2020 6:43:11 PM EST Paul Moore wrote:
> > So far there are only seven bits used out of 32, so it does not appear we
> > are in danger of running out anytime soon.
Exactly. Even capability bits are easier to get assigned. :-)
> > It was introduced with commit 0288d7183c41c0192d2963d44590f346f4aee917
> > Author: Richard Guy Briggs <rgb@redhat.com>
> > AuthorDate: 2014-11-17 15:51:01 -0500
> > Commit: Paul Moore <pmoore@redhat.com>
> > CommitDate: 2014-11-17 16:53:51 -0500
> > ("audit: convert status version to a feature bitmap")
> > It was introduced specifically to enable distributions to selectively
> > backport features. It was converted away from AUDIT_VERSION.
> >
> > There are other ways to detect the presence of backlog_wait_time_actual
> > as I mentioned above.
>
> Let me be blunt - I honestly don't care what Steve's audit userspace
> does to detect this. I've got my own opinion, but Steve's audit
> userspace is not my project to manage and I think we've established
> over the years that Steve and I have very different views on what
> constitutes good design.
And guessing what might be in buffers of different sizes is good design? The
FEATURE_BITMAP was introduced to get rid of this ambiguity.
-Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2020-12-03 23:56 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 21:32 [PATCH v2] audit: report audit wait metric in audit status reply Max Englander
2020-07-02 20:42 ` Paul Moore
2020-07-03 21:29 ` Richard Guy Briggs
2020-07-03 22:36 ` Max Englander
2020-07-03 22:31 ` Max Englander
2020-12-03 3:52 ` Steve Grubb
2020-12-03 4:12 ` Paul Moore
2020-12-03 12:37 ` Richard Guy Briggs
2020-12-03 15:37 ` Paul Moore
2020-12-03 23:10 ` Richard Guy Briggs
2020-12-03 23:43 ` Paul Moore
2020-12-03 23:55 ` Steve Grubb [this message]
2020-12-04 2:16 ` Paul Moore
2020-12-04 2:47 ` Steve Grubb
2020-12-04 20:41 ` Paul Moore
2020-12-07 21:13 ` Max Englander
2020-12-07 21:17 ` Paul Moore
2020-12-07 21:21 ` Richard Guy Briggs
2020-12-07 21:28 ` Max Englander
2020-12-07 23:28 ` Steve Grubb
2020-12-08 1:34 ` Richard Guy Briggs
2020-12-08 3:34 ` Steve Grubb
2020-12-08 13:20 ` Richard Guy Briggs
2020-12-08 13:44 ` Steve Grubb
2020-12-08 23:08 ` Paul Moore
2020-12-03 13:31 ` Steve Grubb
2020-12-07 19:43 ` Lenny Bruzenak
2020-12-07 21:14 ` Paul Moore
2020-12-03 4:33 ` Joe Wulf
2020-12-07 21:48 ` Max Englander
2020-12-08 16:57 ` Lenny Bruzenak
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=20883376.EfDdHjke4D@x2 \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=paul@paul-moore.com \
--cc=rgb@redhat.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.