[PATCH] filesystem location based auditing

[Amy Griffis]

On Mon, Feb 27, 2006 at 12:24:35PM -0500, Steve Grubb wrote:
> On Monday 27 February 2006 12:06, Amy Griffis wrote:
> > What is the preferred way to update a patch which has already been
> > merged?
> 
> In the past, we've applied patches on top of patches when they've
> been out for some time. If its recent, like within a week, we've
> corrected patches since there's not much that is counting on it
> being a certain way.  An example, we've got 2 patches against
> Dustin's patch that adds contexts to syscall records.

I understand why you want to do things this way.  But I don't think it
makes it very easy for someone upstream to review our list of patches.

I thought that the branches in the git tree could handle this.  Would
it be possible to have a new branch that moves the inotify kernel api
patch and the audit watch patch to the end of the list?

If this isn't possible, then I'm afraid I don't understand the point
of the 'amg' branch.

> Under normal circumstances this normally isn't a problem. Right now
> we have a 5 month backlog of patches that haven't gone upstream.
> That represents about 17-20 individual patches. Each patch added
> makes it more and more fragile to changes that upstream is making.
>
> The functionality that you just added, the audit client, really does
> stand on its own. I don't think you need to merge it with the
> string2 patch.

The patch I just posted includes all of the AUDIT_WATCH functionality.
The previous patch (aka string2) only included functionality for
add/remove/listing rules.  The purpose of separating this piece out
was to have something stable that would enable work on the interface
changes from the userspace side.

If the AUDIT_WATCH functionality is to be reviewed by anyone further
upstream, as I expect it to be, it should be reviewed as a single
patch.  The first patch adds a chunk of code that is then removed by
the second patch.  It's pointless for anyone upstream to review that
intermediate work.

This is also going to be a problem with the inotify kernel API patch,
as it needs a re-write before it can be proposed upstream.

Regards,
Amy