Re: [RFC][PATCH] Inotify kernel API
On Tue, Sep 06, 2005 at 04:58:08PM -0500, Timothy R. Chavez wrote:
On Tuesday 23 August 2005 15:37, Amy Griffis wrote:
> Attached is a patch (against Linus' git tree) that implements a basic
> kernel API for inotify. Here is a description of the patch:
>
> The Inotify kernel API provides these functions:
>
> inotify_init - initialize an inotify instance
> inotify_add_watch - add a watch on an inode
> inotify_ignore - remove a watch on an inode
> inotify_free - destroy an inotify instance
>
> The kernel API differs from the userspace API in the following ways:
>
> - Instead of a file descriptor, inotify_init() returns a pointer to
> struct inotify_dev, which is an incomplete type to kernel consumers.
>
> - The consumer provides a callback to inotify_init(), which is used
> for filesystem event notification instead of the kevents used for
> userspace.
>
> - Watches are added on inodes rather than paths.
So we're assuming that the inode must then exist. This will be awkward
when wanting to watch a file whose creation we anticipate will happen in
the future (i.e., /var/log/audit/audit.log.4) and has no inode available at
setup time to watch.
For any path to be watched, audit would add an inotify watch for the
parent's inode. If the file or directory exists, it would add an
inotify watch for the corresponding inode as well.
>
> - inotify_add_watch() takes a callback argument, which is used to
> provide the consumer with a quick-access method back to its own data
> structure, rather than needing to hash the watch descriptor or walk
> a list.
>
> - The path is given to the event callback as an additional argument
> rather than being appended to the inotify_event structure;
> inotify_event.len is unused.
I guess I'm confused on how this is going to work. We pass to the callback
on the device, a structure, which, among other things, includes the path?
The inotify_device does not contain the path. Some inotify events,
e.g. IN_MOVE_FROM, currently provide a path (dentry name) along with
the event. On closer look, I now see that audit would need the arg to
be the dentry itself, and not just the name.
Where are we setting up the parent? When we execute the callback,
we've
triggered the watch, but no setup has occured prior to this, so what are we
doing with the path here?
When we get an event callback, we would add the dentry name and inode
info to the audit_context.
>
> - User-based limits on number of watches, etc. are ignored.
>
> Here is a list of other things I've been working on, but are not
> included in this patch:
>
> - Adding inode information to the event callback.
>
> - Allowing for adding/removing inotify watches from an event callback.
>
> I've also sketched out some data structures and written some prototype
> audit code that makes use of this patch.
>
Can we see this yet? I'm particularly interested in the prototype audit code.
I would prefer to finish investigating what audit's requirements for
Inotify would be, so we can be aware of any potential hang-ups. I
expect to finish the investigation this week. If the changes audit
would need are acceptable to John and Robert, we can look at code
then.
Amy