Re: [RFC/PATCH 1/2] fsnotify

On Fri, 2005-07-08 at 18:26 -0700, Chris Wright wrote: - inode_dir_notify(dir, DN_CREATE); + fsnotify_create(dir, new_dentry->d_name.name); .... + * We don't compile any of this away in some complicated menagerie of ifdefs. + * Instead, we rely on the code inside to optimize away as needed. .... +static inline void fsnotify_create(struct inode *inode, const char *name) +{ + dnotify_create(inode, name); +} .... +static inline void dnotify_create(struct inode *inode, const char *name) +{ + inode_dir_notify(inode, DN_CREATE); +} To be honest, I don't really see that this is in any way better than what we had before. Yes, two different pieces of code actually use hooks in similar places in the VFS code. But this 'infrastructure' just to share those hooks is overkill as far as I can tell. It really isn't any better than having both inotify and audit hooks side by side where we can actually see what's going on at a glance. In fact, it's worse. What would make sense, perhaps, would be to actually merge those hooks; not just a cosmetic amalgamation of the calling sites. Currently, each of inotify and the audit code does its own filtering when its hooks are triggered, and then acts upon the event only if it affects a watched inode. To actually merge that filtering code would make sense -- and then both inotify and auditfs would just register watches on certain inodes and receive notification as appropriate. There are features of each which would probably be desirable in the merged result. The inotify version grows the inode structure by quite a lot, while the auditfs version recognises that watches will be relatively infrequent, so uses only a bit in i_flags as a quickly-accessible indication that an inode is 'interesting' and maintains its actual data for that inode elsewhere. The auditfs version is also capable of handling the "Child named 'XXXX' of this inode" kind of watch, where watches are placed on objects which don't yet exist. Also, the auditfs code already calls back to a separate function auditfs_attach_wdata() in the _real_ audit code, which actually reports when the watch is triggered; it shouldn't be hard to make it call into an inotify function instead, depending on the type of watch which is hit. On the other hand, the inotify triggers require a little more information from the original hook, which audit_notify_watch() would need to pass through if the audit code were used as the basis for a merged 'core watch' functionality. -- dwmw2