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 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 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
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
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
> - 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)
+
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
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
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
14 matches
Mail list logo
