splinter work on generic fs notification framework

[Timothy R. Chavez]

On Tuesday 12 July 2005 14:18, Timothy R. Chavez wrote:
> Hi,
> 
> I've CCed some folks that I thought might be interested in this update and may
> not be on linux-audit.
> 
> Based on recent discussion on LKML and some IRC conversations, a generic file 
> system notification framework is being written to merge common functionality 
> between the "auditfs" component of the audit framework and Inotify.  This 
> framework will be mostly comprised of the watch logic implemented by the 
> "auditfs" component (I_AUDIT, hash table, update hook, helper functions, etc) 
> and the fsnotify hooks written by Robert Love.  User's of this framework will 
> pass their own callback functions in when adding a watch via this framework 
> which will effectively be stored on the watch and called from the watch hook 
> that discovers it.

I should be clear that an inode will keep a list of watches on it as more then
one user may be interested in it in addition to a single user being interested 
in from several locations (ie: a hardlink to a watched file in another watched 
location). 

> 
> We introduce fs/watch.c and include/linux/watch.h
> 
> Some of the oustanding issues:
> 
> o The fsnotify hooks will need to be expanded to cover more of the file system 
> to fufill CAPP's needs.
> 
> o The way we did "movement" notifications is different how Inotify did them.  
> The trick is to do it such that its mutually beneficial.
> 
> o The interface for adding and removing watches should be the same for every 
> user.  I think that the audit_receive_watch|audit_insert/remove_watch bit was 
> quite slopply done *pats self on back*, so I think this gives me a chance to 
> redeem myself and make something functional and slightly more sexy.
> 
> o Filtering.  Should the MAY_* stuff be scrapped... How important is it?  I 
> think it's a bit sloppy and contrived too.  It's a fine concept.  We'd 
> ideally like to mitigate throughput where possible, but I think the 
> 'ausearch' tool should work fine for looking only and what's "interesting" 
> and the netlink speed-up coupled with the backlogs work should help buffer 
> any impact introduced by the extra records.  Opinions?
> 
> o I'd like to place an extra field in the record that tells you exactly what 
> type of action it was... trying to deduce from system call is a bit... 
> cumbersome... might be nice to have in the log, "action=MODIFIED" or 
> something.

I should have been more explicit.  This is more an audit-only related issue.
Presumably the callback would be interested from what hook it was called.
We let the user decide whether its important or not.  For audit do we think 
this is something that'd be useful (especially when trying to decipher the
meaning of the record in a _meaningful_ way)?

-tim

> 
> Feel free to add something..
> 
> I'm sure I'm forgetting some things, but I really should get back to work :)
> 
> Anyway... it's a start
> 
> -tim
>