Robert Love wrote:
> Below is inotify, diffed against 2.6.11.
>
> I greatly reworked much of the data structures and their interactions,
> to lay the groundwork for sanitizing the locking. I then, I hope,
> sanitized the locking. It looks right, I am happy. Comments welcome.
> I surely could
Robert Love wrote:
Below is inotify, diffed against 2.6.11.
I greatly reworked much of the data structures and their interactions,
to lay the groundwork for sanitizing the locking. I then, I hope,
sanitized the locking. It looks right, I am happy. Comments welcome.
I surely could of
On Thu, 2005-04-07 at 18:37 -0700, Rusty Lynch wrote:
> Looking into this a little more I realized that the lack of /proc
> notifications (for processes coming and going) is a common problem anytime
> a file is modified without going through the VFS. Other examples are
> remote file changes on a
On Thu, 2005-04-07 at 18:37 -0700, Rusty Lynch wrote:
Looking into this a little more I realized that the lack of /proc
notifications (for processes coming and going) is a common problem anytime
a file is modified without going through the VFS. Other examples are
remote file changes on a
I've been meaning to play with inotify for a while now and finally made
time for it tonight. I'm not much of a GUI guy, so I'm mostly interested
in exploring the command line applications of inotify --i.e., what sort of
havoc can I wreak with it in a script.
To that end I sat down tonight a threw
On Tue, 2005-04-05 at 17:53 -0700, Rusty Lynch wrote:
> From just a casual look, it seems like this could be used to monitor the
> comings and goings of processes by monitoring /proc. Unfortunately
> inotify doesn't seem to be getting all the events on the proc filesystem
> like it does on a
On Tue, 2005-04-05 at 19:20 +0200, Prakash Punnoor wrote:
> BTW, what else could I use to make use of inotify? I know fam, which afaik
> only uses dnotify.
Here is a little sample glib application that shows the ease-yet-power
of inotify.
Robert Love schrieb:
> On Tue, 2005-04-05 at 09:58 +0200, Prakash Punnoor wrote:
>
>>I am having a little trouble with inotify 0.22. Previous version worked w/o
>>trouble (even with nvidia and nvsound loaded) with 2.6.12-rc1-kb2 and gamin
>>
>>Now I use 2.6.12-rc2 with inotify 0.22 and got this
On Tue, 2005-04-05 at 19:20 +0200, Prakash Punnoor wrote:
> BTW, what else could I use to make use of inotify? I know fam, which afaik
> only uses dnotify.
Beagle, a desktop search infrastructure. Check out
http://www.gnome.org/projects/beagle
Some other little projects. If anyone else is
On Tue, 2005-04-05 at 09:58 +0200, Prakash Punnoor wrote:
> I am having a little trouble with inotify 0.22. Previous version worked w/o
> trouble (even with nvidia and nvsound loaded) with 2.6.12-rc1-kb2 and gamin
>
> Now I use 2.6.12-rc2 with inotify 0.22 and got this after a few minutes of
>
Hi,
I am having a little trouble with inotify 0.22. Previous version worked w/o
trouble (even with nvidia and nvsound loaded) with 2.6.12-rc1-kb2 and gamin
Now I use 2.6.12-rc2 with inotify 0.22 and got this after a few minutes of
uptime (compiling some stuff):
Apr 5 09:40:43 tachyon Unable to
On Tue, 2005-04-05 at 19:20 +0200, Prakash Punnoor wrote:
BTW, what else could I use to make use of inotify? I know fam, which afaik
only uses dnotify.
Beagle, a desktop search infrastructure. Check out
http://www.gnome.org/projects/beagle
Some other little projects. If anyone else is using
Robert Love schrieb:
On Tue, 2005-04-05 at 09:58 +0200, Prakash Punnoor wrote:
I am having a little trouble with inotify 0.22. Previous version worked w/o
trouble (even with nvidia and nvsound loaded) with 2.6.12-rc1-kb2 and gamin
Now I use 2.6.12-rc2 with inotify 0.22 and got this after a few
On Tue, 2005-04-05 at 19:20 +0200, Prakash Punnoor wrote:
BTW, what else could I use to make use of inotify? I know fam, which afaik
only uses dnotify.
Here is a little sample glib application that shows the ease-yet-power
of inotify.
On Tue, 2005-04-05 at 17:53 -0700, Rusty Lynch wrote:
From just a casual look, it seems like this could be used to monitor the
comings and goings of processes by monitoring /proc. Unfortunately
inotify doesn't seem to be getting all the events on the proc filesystem
like it does on a real
I've been meaning to play with inotify for a while now and finally made
time for it tonight. I'm not much of a GUI guy, so I'm mostly interested
in exploring the command line applications of inotify --i.e., what sort of
havoc can I wreak with it in a script.
To that end I sat down tonight a threw
Hi,
I am having a little trouble with inotify 0.22. Previous version worked w/o
trouble (even with nvidia and nvsound loaded) with 2.6.12-rc1-kb2 and gamin
Now I use 2.6.12-rc2 with inotify 0.22 and got this after a few minutes of
uptime (compiling some stuff):
Apr 5 09:40:43 tachyon Unable to
On Tue, 2005-04-05 at 09:58 +0200, Prakash Punnoor wrote:
I am having a little trouble with inotify 0.22. Previous version worked w/o
trouble (even with nvidia and nvsound loaded) with 2.6.12-rc1-kb2 and gamin
Now I use 2.6.12-rc2 with inotify 0.22 and got this after a few minutes of
uptime
On Mon, 2005-03-07 at 23:50 -0500, Robert Love wrote:
> Yah, I just missed it. It is fixed in my tree.
Following patch, against 2.6.11-mm1, fixes the hooks in fs/compat.c.
Otherwise unchanged from the previous patch.
Robert Love
inotify!
inotify is intended to correct the
On Mon, 2005-03-07 at 23:50 -0500, Robert Love wrote:
Yah, I just missed it. It is fixed in my tree.
Following patch, against 2.6.11-mm1, fixes the hooks in fs/compat.c.
Otherwise unchanged from the previous patch.
Robert Love
inotify!
inotify is intended to correct the
On Tue, 2005-03-08 at 04:40 +, Christoph Hellwig wrote:
> Why do you need the classdevice? I'm really not too eager about adding
> tons of new misdevices now that we can route directly to individual majors
> with cdev_add & stuff. Especially when you're actually relying on class
> device
> > this one seems totally unrelated.
>
> Eh? We did not add that. ;)
Sorry, I thought I saw a + somewhere there at the beggining of the line,
my fault.
> > Should probably use the /dev/mem major.
>
> Hrm, should we?
>
> Also, the memory class stuff is all local to mem.c. For example, I
>
On Maandag 07 März 2005 04:13, Albert Cahalan wrote:
> Christoph Hellwig writes:
> > See the review I sent. Write is exactly the right interface for that kind
> > of thing. For comment vs argument either put the number first so we don't
> > have the problem of finding a delinator that isn't a
On Mon, 2005-03-07 at 01:19 +, Christoph Hellwig wrote:
Hi, hch.
I went ahead and implemented all of your suggestions, save for the ones
below where I have comments or disagree (see below). Most of your
comments were straightforward and I made the changes as you suggested.
See the following
On Fri, 2005-03-04 at 13:37 -0500, Robert Love wrote:
> I greatly reworked much of the data structures and their interactions,
> to lay the groundwork for sanitizing the locking. I then, I hope,
> sanitized the locking. It looks right, I am happy. Comments welcome.
> I surely could of missed
On Fri, 2005-03-04 at 13:37 -0500, Robert Love wrote:
I greatly reworked much of the data structures and their interactions,
to lay the groundwork for sanitizing the locking. I then, I hope,
sanitized the locking. It looks right, I am happy. Comments welcome.
I surely could of missed
On Mon, 2005-03-07 at 01:19 +, Christoph Hellwig wrote:
Hi, hch.
I went ahead and implemented all of your suggestions, save for the ones
below where I have comments or disagree (see below). Most of your
comments were straightforward and I made the changes as you suggested.
See the following
On Maandag 07 März 2005 04:13, Albert Cahalan wrote:
Christoph Hellwig writes:
See the review I sent. Write is exactly the right interface for that kind
of thing. For comment vs argument either put the number first so we don't
have the problem of finding a delinator that isn't a valid
this one seems totally unrelated.
Eh? We did not add that. ;)
Sorry, I thought I saw a + somewhere there at the beggining of the line,
my fault.
Should probably use the /dev/mem major.
Hrm, should we?
Also, the memory class stuff is all local to mem.c. For example, I
cannot get
On Tue, 2005-03-08 at 04:40 +, Christoph Hellwig wrote:
Why do you need the classdevice? I'm really not too eager about adding
tons of new misdevices now that we can route directly to individual majors
with cdev_add stuff. Especially when you're actually relying on class
device you
On Mon, 2005-03-07 at 01:23 +, Christoph Hellwig wrote:
> It means that every re3vision of inotify so far has been buggy in some
> respect and ig got dropped from -mm again and again. It should get some
> more testing there and not sent firectly for mainline.
It was dropped from 2.6-mm
Christoph Hellwig writes:
> On Sat, Mar 05, 2005 at 07:40:06PM -0500, Robert Love wrote:
>> On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote:
>>> The user interface is still bogus.
>>
>> I presume you are talking about the ioctl. I have tried to engage you
>> and others on what
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> -mm has a list of inodes per superblock, which Andrew said he'd send
> along to lines, you should probably use that one.
That was merged a month or two ago.
superblock.s_inodes, linked via inode.i_sb_list, protected by inode_lock.
-
To
On Sat, Mar 05, 2005 at 07:40:06PM -0500, Robert Love wrote:
> On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote:
>
> > The user interface is still bogus.
>
> I presume you are talking about the ioctl. I have tried to engage you
> and others on what exactly you prefer instead. I have
> - if ((ret + (type == READ)) > 0)
> - dnotify_parent(file->f_dentry,
> - (type == READ) ? DN_ACCESS : DN_MODIFY);
> + if ((ret + (type == READ)) > 0) {
> + struct dentry *dentry = file->f_dentry;
> + if (type == READ)
> +
- if ((ret + (type == READ)) 0)
- dnotify_parent(file-f_dentry,
- (type == READ) ? DN_ACCESS : DN_MODIFY);
+ if ((ret + (type == READ)) 0) {
+ struct dentry *dentry = file-f_dentry;
+ if (type == READ)
+
On Sat, Mar 05, 2005 at 07:40:06PM -0500, Robert Love wrote:
On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote:
The user interface is still bogus.
I presume you are talking about the ioctl. I have tried to engage you
and others on what exactly you prefer instead. I have said
Christoph Hellwig [EMAIL PROTECTED] wrote:
-mm has a list of inodes per superblock, which Andrew said he'd send
along to lines, you should probably use that one.
That was merged a month or two ago.
superblock.s_inodes, linked via inode.i_sb_list, protected by inode_lock.
-
To unsubscribe
Christoph Hellwig writes:
On Sat, Mar 05, 2005 at 07:40:06PM -0500, Robert Love wrote:
On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote:
The user interface is still bogus.
I presume you are talking about the ioctl. I have tried to engage you
and others on what exactly you prefer
On Mon, 2005-03-07 at 01:23 +, Christoph Hellwig wrote:
It means that every re3vision of inotify so far has been buggy in some
respect and ig got dropped from -mm again and again. It should get some
more testing there and not sent firectly for mainline.
It was dropped from 2.6-mm once.
On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote:
> The user interface is still bogus.
I presume you are talking about the ioctl. I have tried to engage you
and others on what exactly you prefer instead. I have said that moving
to a write interface is fine but I don't see how ut is
On Fri, Mar 04, 2005 at 01:37:24PM -0500, Robert Love wrote:
> Below is inotify, diffed against 2.6.11.
>
> I greatly reworked much of the data structures and their interactions,
> to lay the groundwork for sanitizing the locking. I then, I hope,
> sanitized the locking. It looks right, I am
On Fri, Mar 04, 2005 at 01:37:24PM -0500, Robert Love wrote:
Below is inotify, diffed against 2.6.11.
I greatly reworked much of the data structures and their interactions,
to lay the groundwork for sanitizing the locking. I then, I hope,
sanitized the locking. It looks right, I am happy.
On Sun, 2005-03-06 at 00:04 +, Christoph Hellwig wrote:
The user interface is still bogus.
I presume you are talking about the ioctl. I have tried to engage you
and others on what exactly you prefer instead. I have said that moving
to a write interface is fine but I don't see how ut is
On Fri, 04 Mar 2005 13:37:24 -0500, Robert Love <[EMAIL PROTECTED]> wrote:
> Below is inotify, diffed against 2.6.11.
>
> I greatly reworked much of the data structures and their interactions,
> to lay the groundwork for sanitizing the locking. I then, I hope,
> sanitized the locking. It looks
On Fri, 2005-03-04 at 15:38 -0600, Timothy R. Chavez wrote:
Hi, Mr. Chavez.
> Are there plans of reworking the "generic" hooking infrastructure
> (fsnotify.h) to be more like the security hooking framework (+
> stacking)? I think it'd be nice to be able to have a fs_notify struct
> of function
On Fri, 2005-03-04 at 13:37 -0500, Robert Love wrote:
Hey, Andrew.
> I greatly reworked much of the data structures and their interactions,
> to lay the groundwork for sanitizing the locking. I then, I hope,
> sanitized the locking. It looks right, I am happy. Comments welcome.
> I surely
Below is inotify, diffed against 2.6.11.
I greatly reworked much of the data structures and their interactions,
to lay the groundwork for sanitizing the locking. I then, I hope,
sanitized the locking. It looks right, I am happy. Comments welcome.
I surely could of missed something. Maybe even
Below is inotify, diffed against 2.6.11.
I greatly reworked much of the data structures and their interactions,
to lay the groundwork for sanitizing the locking. I then, I hope,
sanitized the locking. It looks right, I am happy. Comments welcome.
I surely could of missed something. Maybe even
On Fri, 2005-03-04 at 13:37 -0500, Robert Love wrote:
Hey, Andrew.
I greatly reworked much of the data structures and their interactions,
to lay the groundwork for sanitizing the locking. I then, I hope,
sanitized the locking. It looks right, I am happy. Comments welcome.
I surely could
On Fri, 2005-03-04 at 15:38 -0600, Timothy R. Chavez wrote:
Hi, Mr. Chavez.
Are there plans of reworking the generic hooking infrastructure
(fsnotify.h) to be more like the security hooking framework (+
stacking)? I think it'd be nice to be able to have a fs_notify struct
of function
On Fri, 04 Mar 2005 13:37:24 -0500, Robert Love [EMAIL PROTECTED] wrote:
Below is inotify, diffed against 2.6.11.
I greatly reworked much of the data structures and their interactions,
to lay the groundwork for sanitizing the locking. I then, I hope,
sanitized the locking. It looks right,
On Fri, 2005-02-18 at 17:24 +, Al Viro wrote:
> Fix the damn locking, already.
Fast as I can.
Robert Love
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, Feb 18, 2005 at 11:40:59AM -0500, Robert Love wrote:
> inotify, bitches
/me does "pick a random function, find a race" again.
> +/*
> + * inode_add_watch - add a watch to the given inode
> + *
> + * Callers must hold dev->lock, because we call inode_find_dev().
> + */
> +static int
On Thu, 2005-02-10 at 13:47 -0500, Robert Love wrote:
> Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify.
Updated patch, fixes a bug.
Robert Love
inotify, bitches
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
arch/sparc64/Kconfig | 13
On Thu, 2005-02-10 at 13:47 -0500, Robert Love wrote:
Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify.
Updated patch, fixes a bug.
Robert Love
inotify, bitches
Signed-off-by: Robert Love [EMAIL PROTECTED]
arch/sparc64/Kconfig | 13
drivers/char/Kconfig
On Fri, Feb 18, 2005 at 11:40:59AM -0500, Robert Love wrote:
inotify, bitches
/me does pick a random function, find a race again.
+/*
+ * inode_add_watch - add a watch to the given inode
+ *
+ * Callers must hold dev-lock, because we call inode_find_dev().
+ */
+static int
On Fri, 2005-02-18 at 17:24 +, Al Viro wrote:
Fix the damn locking, already.
Fast as I can.
Robert Love
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote:
> -inotify.patch
> -inotify-fix_find_inode.patch
>
> I think my version is old, and it oopses.
It is old. I have sent you multiple updates. ;-)
Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify.
This version has
On Thu, 2005-02-10 at 02:35 -0800, Andrew Morton wrote:
-inotify.patch
-inotify-fix_find_inode.patch
I think my version is old, and it oopses.
It is old. I have sent you multiple updates. ;-)
Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify.
This version has numerous
Andrew,
Attached patch is an updated inotify for 2.6-mm. It replaces
inotify.patch and inotify-fix_find_inode.patch.
A bunch of improvements over the current patch:
- Implements a generic notification layer, simple wrappers
to keep the dnotify and inotify hooks in fs/ clean.
Andrew,
Attached patch is an updated inotify for 2.6-mm. It replaces
inotify.patch and inotify-fix_find_inode.patch.
A bunch of improvements over the current patch:
- Implements a generic notification layer, simple wrappers
to keep the dnotify and inotify hooks in fs/ clean.
Hey, Andrew.
Below is an updated inotify patch (e.g. drop-in replacement for the
current patch) for 2.6.11-rc1-mm2.
Primary changes are bugfixes, cleanups, and the much-demanded
dynamic-length filename. Also, this fixes the reported regression in
directory operation performance. More cleanups,
Hey, Andrew.
Below is an updated inotify patch (e.g. drop-in replacement for the
current patch) for 2.6.11-rc1-mm2.
Primary changes are bugfixes, cleanups, and the much-demanded
dynamic-length filename. Also, this fixes the reported regression in
directory operation performance. More cleanups,
64 matches
Mail list logo
