All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <pmoore@redhat.com>
To: Joe Perches <joe@perches.com>
Cc: Richard Guy Briggs <rgb@redhat.com>,
	linux-audit@redhat.com, linux-kernel@vger.kernel.org,
	sgrubb@redhat.com, eparis@parisplace.org
Subject: Re: [PATCH] audit: convert status version to a feature bitmap
Date: Thu, 13 Nov 2014 17:00:07 -0500	[thread overview]
Message-ID: <2576097.lHYG4OpOLo@sifl> (raw)
In-Reply-To: <1415911097.4223.13.camel@perches.com>

On Thursday, November 13, 2014 12:38:17 PM Joe Perches wrote:
> On Thu, 2014-11-13 at 15:29 -0500, Richard Guy Briggs wrote:
> > The version field defined in the audit status structure was found to have
> > limitations in terms of its expressibility of features supported.  This is
> > distict from the get/set features call to be able to command those
> > features
> > that are present.
> > 
> > Converting this field from a version number to a feature bitmap will allow
> > distributions to selectively backport and support certain features and
> > will
> > allow upstream to be able to deprecate features in the future.  It will
> > allow userspace clients to first query the kernel for which features are
> > actually present and supported.  Currently, EINVAL is returned rather
> > than EOPNOTSUP, which isn't helpful in determining if there was an error
> > in the command, or if it simply isn't supported yet.  Past features are
> > not represented by this bitmap, but their use may be converted to
> > EOPNOTSUP if needed in the future.
>
> Maybe use DECLARE_BITMAP instead of u32 and test_bit/set_bit

The audit_status struct is user visible and the version field is currently a 
u32 where DECLARE_BITMAP is an unsigned long.

-- 
paul moore
security and virtualization @ redhat

  reply	other threads:[~2014-11-13 22:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-13 20:29 [PATCH] audit: convert status version to a feature bitmap Richard Guy Briggs
2014-11-13 20:38 ` Joe Perches
2014-11-13 22:00   ` Paul Moore [this message]
2014-11-14  1:01   ` Richard Guy Briggs
2014-11-13 22:12 ` Paul Moore
2014-11-14  1:08   ` Richard Guy Briggs
2014-11-14  2:51     ` Steve Grubb
2014-11-15  3:32       ` Richard Guy Briggs
2014-11-17 16:09         ` Paul Moore
2014-11-17 17:23           ` Steve Grubb
2014-11-17 18:08             ` Richard Guy Briggs
2014-11-17 18:11               ` Steve Grubb
2014-11-17 18:16                 ` Richard Guy Briggs
2014-11-17 19:48               ` Paul Moore
2014-11-17 20:51                 ` Richard Guy Briggs
2014-11-17 21:59                   ` Paul Moore
2014-11-14 13:32     ` Paul Moore
2014-11-14 13:32       ` Paul Moore

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=2576097.lHYG4OpOLo@sifl \
    --to=pmoore@redhat.com \
    --cc=eparis@parisplace.org \
    --cc=joe@perches.com \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgb@redhat.com \
    --cc=sgrubb@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.