Re: [patch] inotify for 2.6.11-mm1, updated

[Christoph Hellwig]

> > 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 at /sys/class/mem.  The misc. device stuff is exported.

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 should have your own one instead of relying on an onsolete
layer.

> > do you really need a spinlock of your own in every inode?  Inode memory
> > usage is a quite big problem.
> 
> Yah, we do.  For a couple of reasons.  First, by introducing our own
> lock, we never need touch i_lock, and avoid that scalability mess
> altogether.  Second, and most importantly, i_lock is an outermost lock.
> We need our lock to be nestable, because we walk inode -> inotify_watch
> -> inotify_device.  I've tried various rewrites to not need our own
> lock.  None are pretty.
> 
> I can offer to the "inode memory worries me" people that they can always
> disable CONFIG_INOTIFY.

They're bound to use distro kernels unfortunaly..  These people is anyone
doing big-scale fileserving at least.

> +	if ((ret + (type == READ)) > 0) {
> +		struct dentry *dentry = file->f_dentry;
> +		if (type == READ)
> +			fsnotify_access(dentry, dentry->d_inode,
> +					dentry->d_name.name);
> +		else
> +			fsnotify_modify(dentry, dentry->d_inode,
> +					dentry->d_name.name);
> +	}

Arguments two and three are still redudant.

Actually, you fixed that in read_write.c, just compat.c is still missing.
Looks like you forget to fix that one and didn't have a chance to compile-test
the 32bit compat layer?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/