inotify 0.5

Inotify is a replacement for dnotify.

The main difference between this and my earlier inotify design, is that device numbers and inode numbers are no longer used. The interface between user and kernel space uses a watcher descriptor.

inotify is a char device with two ioctls

WATCH
which takes

struct inotify_watch_request {
char *dirname; // directory name
unsigned long mask; // event mask
};

and returns a watcher descriptor (int)

IGNORE
which takes a watcher descriptor and returns nothing.

After you WATCH a directory, and events that happen on the inode for the directory that match the mask you asked for will be available to read from the char device. You read this structure from the character device.

struct inotify_event {
        int wd;
        int mask;
};

When a directory you are watching is unmounted, you will get a UNMOUNT event.

When a directory is unmounted or you use the IGNORE ioctl on the char dev. You will get a IGNORED event.

I have attached a tarball, which includes the patch for linux 2.6.7 and a small test app.

I have tested this on my system and AFAIK it is working. No doubt it has plenty of bugs.

I plan on adding an inotify backend to gamin soon.

John

What about support for fam?

Thanks,

Martin Schlemmer

I have been getting the impression that fam is going to be replaced by gamin.

John

Right, but kde also works with fam, and I assume the gamin support will only be in 2.[78] gnome-vfs? Also, it would be nice to test currently with fam enabled stuff, as I want to remember inotify do not have issues with locking mounts like dnotify have? Or is it rather a fam-related issue ?

Thanks,

Martin Schlemmer

Gamin is a API/ABI stable replacement for FAM. Just dropping in gamin instead of fam should just work with all current software. Inotify does not have the umount blocking problem. In fact it lets FAM/Gamin no that a particular directory has been unmounted and is no longer available. This will let konquerer/nautilus provide more user friendly clues to users.

John

Does such descriptor supports poll(2) (... f_op->poll())?

- Davide

You don't use the watcher descriptor to read the events. You use the fd from opening up the inotify device (/dev/inotify). The inotify character device does support the poll op.

The watcher descriptor is used for communication between the app and the device driver.

For example,
you perform the watch ioctl on "/tmp/" the ioctl returns '2'. Then when reading from the char device, any event with wd == 2 is referring to the the "/tmp/" directory.

the character device produces inotify events

struct inotify_event {
	int wd;
	int mask;
}

John

So the number of watches is restricted to the max number of file handles/process?

Ian

Note: I have not read the code. We should probably do so before speculating.

However, it looks like you have one fd, and reading from it gives you a data structure of information about the event. The max number of watches could be as high as INT_MAX depending on implementation.

Chris

Yes you are right. The maximum number of watchers is per-device. I have it defined as 256 now. Also the maximum number of devices that can be opened at a time is 8.

John

Why is that limit there? There doesn't seem to be any particular need for it in the code... Why not remove watcher_count altogether?

Eric

The limits are there to control the amount of kernel resources used by inotify. They are not meant to be anything but a guesstimate.

John

Read the code last time it was posted. I'll get around to reading the update.

But I'm a bit slow and I've probably asked before anyway.

Ho Hum.

Ian

On Sun, Jul 18, 2004 at 03:49:27PM -0400, John McCutchan wrote:
[...]

I take patches :-)
But I think it misses the really good point of inotify as I see it, i.e. there is no need anymore of a daemon outside the application space, in practice I would rather see inotify plugged at the gnome-vfs level. The reason is that you will just need to monitor the inotify file descriptor, which is easy to do at the gnome-vfs level since you have glib and loop access, while in libgamin this would either require disabling dnotify if inotify is available (FAM has only one fd registered at the application layer), or use the daemon for inotify too. The only advantage of using the daemon would be for advanced features like congestion control, which are not available (yet ?) in gamin.

inotify sounds good to me, I hope it won't be bounced by the kernels
people.

Daniel

Daniel Veillard      | Red Hat Desktop team http://redhat.com/
[email protected]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/