lkml.org 
[lkml]   [2013]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 7/8] audit: clean up AUDIT_GET/SET local variables and future-proof API
From
Date
On Thu, 2013-09-19 at 17:18 -0400, Steve Grubb wrote:
> On Wednesday, September 18, 2013 03:06:52 PM Richard Guy Briggs wrote:
> > Re-named confusing local variable names (status_set and status_get didn't
> > agree with their command type name) and reduced their scope.
> >
> > Future-proof API changes by not depending on the exact size of the
> > audit_status struct.
>
> I wished things like this were coordinated before being written. We had some
> discussion of this back in July under a topic, "audit: implement generic
> feature setting and retrieving". Maybe that API can be fixed so its not just
> set/unset but can take a number as well.

Your right, we did talk about it. Though it seems we talked past each
other. What was implemented was an on off extensible interface. The
status interface already fits for setting numbers. And because of how
it is used has been extended is is extensible for setting numbers.

>
> Also, because there is no way to query the kernel to see what kind of things
> it supports

I'll agree. Richard, can you please add a version field to the status?
Start at version 1. Any time we add a new audit feature we'll bump it.

> , we've typically defined a new message type and put into it exactly
> what we need. In other words, if you want something expandable, the define a
> new message type like AUDIT_GET_EXT and AUDIT_SET_EXT and build it to be
> expandable.

There is no reason we can't use what we have. (As we've done it before)



\
 
 \ /
  Last update: 2013-09-20 17:21    [W:0.064 / U:0.880 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site