[PATCH] inotify 0.5

[PATCH] inotify 0.5

[John McCutchan]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

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

[-- Attachment #2: inotify-0.5.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 9296 bytes --]

Re: [PATCH] inotify 0.5

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 181 bytes --]

On Sun, 2004-07-18 at 21:49, John McCutchan wrote:

> I plan on adding an inotify backend to gamin soon.
> 

What about support for fam?


Thanks,

-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] inotify 0.5

[John McCutchan]

On Sun, 2004-07-18 at 15:53, Martin Schlemmer wrote:
> On Sun, 2004-07-18 at 21:49, John McCutchan wrote:
> 
> > I plan on adding an inotify backend to gamin soon.
> > 
> 
> What about support for fam?

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

John

Re: [PATCH] inotify 0.5

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On Sun, 2004-07-18 at 22:02, John McCutchan wrote:
> On Sun, 2004-07-18 at 15:53, Martin Schlemmer wrote:
> > On Sun, 2004-07-18 at 21:49, John McCutchan wrote:
> > 
> > > I plan on adding an inotify backend to gamin soon.
> > > 
> > 
> > What about support for fam?
> 
> I have been getting the impression that fam is going to be replaced by
> gamin.
> 

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] inotify 0.5

[John McCutchan]

On Sun, 2004-07-18 at 16:11, Martin Schlemmer wrote:
> 
> 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 ?

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

Re: [PATCH] inotify 0.5

[Davide Libenzi]

On Sun, 18 Jul 2004, John McCutchan wrote:

> 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)

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



- Davide

Re: [PATCH] inotify 0.5

[John McCutchan]

On Sun, 2004-07-18 at 19:37, Davide Libenzi wrote:
> On Sun, 18 Jul 2004, John McCutchan wrote:
> 
> > 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)
> 
> Does such descriptor supports poll(2) (... f_op->poll())?
> 

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

Re: [PATCH] inotify 0.5

[Ian Kent]

On Sun, 18 Jul 2004, John McCutchan wrote:

> On Sun, 2004-07-18 at 19:37, Davide Libenzi wrote:
> > On Sun, 18 Jul 2004, John McCutchan wrote:
> > 
> > > 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)
> > 
> > Does such descriptor supports poll(2) (... f_op->poll())?
> > 
> 
> 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.
>

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

Re: [PATCH] inotify 0.5

[Chris Friesen]

Ian Kent wrote:

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

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

Re: [PATCH] inotify 0.5

[John McCutchan]

On Mon, 2004-07-19 at 09:33, Chris Friesen wrote:
> Ian Kent wrote:
> 
> > So the number of watches is restricted to the max number of file
> > handles/process?
> 
> 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.

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

Re: [PATCH] inotify 0.5

[Eric Lammerts]

On Mon, 19 Jul 2004, John McCutchan wrote:
> Also the maximum number of devices that can be opened at a time is
> 8.

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

Re: [PATCH] inotify 0.5

[John McCutchan]

On Mon, 2004-07-19 at 22:59, Eric Lammerts wrote:
> On Mon, 19 Jul 2004, John McCutchan wrote:
> > Also the maximum number of devices that can be opened at a time is
> > 8.
> 
> 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?
> 

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

Re: [PATCH] inotify 0.5

[Ian Kent]

On Mon, 19 Jul 2004, Chris Friesen wrote:

> Ian Kent wrote:
> 
> > So the number of watches is restricted to the max number of file
> > handles/process?
> 
> Note: I have not read the code.  We should probably do so before speculating.

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

Re: [PATCH] inotify 0.5

[Daniel Veillard]

On Sun, Jul 18, 2004 at 03:49:27PM -0400, John McCutchan wrote:
[...]
> 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.

  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/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/