On Thu, Jul 07, 2005 at 03:48:37PM -0400, Steve Grubb wrote:
 On Thursday 07 July 2005 15:04, Greg KH wrote:
 > You are adding auditfs, a new userspace access, right?
 
 Not sure what you mean. This is using the same netlink interface that all the 
 rest of the audit system is using for command and control. Nothing has 
 changed here. What is different is the message I send into the kernel. The 
 audit system dispatches it into Tim's code which in turn sets up the watch.  
What is auditfs for then?
 > His email provided no documentation that I could see.  Am I just
missing
 > something?
 
 The auditfs code is programmed by filling out the watch_transport structure 
 and sending a AUDIT_WATCH_INS message type. The perms, pathlen, & keylen are 
 all that's filled out. The path & key are stored back to back in the payload 
 section. To delete, you do the same thing and send AUDIT_WATCH_REM message. 
 Yes, this should be added to the documentation. 
So how does userspace interact with auditfs?
 Tim's code lets you say I want change notification to this file
only. The 
 notification follows the audit format with all relavant pieces of information 
 gathered at the time of the event and serialized with all other events. 
That's great, and I understand the need for it.  I just see all the
duplication between this effort and inotify, and know of Tim's
reluctance to want to work with inotify, and am objecting to that.
 > Am I correct in thinking that you all need to split this patch
into two
 > pieces, the new inode stuff, and auditfs, as neither one has anything to
 > do with the other?
 
 It could be split to make it easier to read, but one's useless without the 
 other. 
Ok, some documentation about auditfs would go a long way toward
understanding this...
thanks,
greg k-h