From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stef Bon Subject: Re: [PATCH] VFS/inotify: send netlink messages when an inotify watch has been set or removed. Date: Sat, 7 Jan 2012 16:03:26 +0100 Message-ID: References: <4F084A4C.6080207@bononline.nl> <20120107143802.GM23916@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Stef Bon , linux-fsdevel@vger.kernel.org, rlove@rlove.org, eparis@parisplace.org To: Al Viro Return-path: Received: from mail-we0-f174.google.com ([74.125.82.174]:40452 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751070Ab2AGPD2 convert rfc822-to-8bit (ORCPT ); Sat, 7 Jan 2012 10:03:28 -0500 Received: by werm1 with SMTP id m1so1736466wer.19 for ; Sat, 07 Jan 2012 07:03:26 -0800 (PST) In-Reply-To: <20120107143802.GM23916@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 2012/1/7 Al Viro : > On Sat, Jan 07, 2012 at 02:36:12PM +0100, Stef Bon wrote: >> from: Stef Bon >> watch has been set (by who, and where, which mask) and when removed >> (pid/fd/wd). > > And what, pray tell, is the recepient to do with the contents of that > packet? =C2=A0Pardon the bluntness, but how the hell is your FUSE fs > supposed to tell that pathname has anything to do with it, nevermind > telling which object would it relate to? =C2=A0Especially when it has > no way to tell at which locations the damn thing happens to be mounte= d > from the caller POV. About bluntness, yes I've received blunt reactions from you in the past. We're working on the same goal here, and nobody is trying to misbehave, sabotage or do other nasty things so please be a bit more gentle. Maybe I'm not that into the kernel programming as you, but that is not a reason to get rude. =46uther, the FUSE fs knows it's own mountpoint. (ignore the submounts on a FUSE fs here), it can filter out the watches which are set on the fs. This is not so hard right? What problems with "no way to tell at which locations the damn thing happens to" you are pointing at?? (When another fs is mounted on a directory part of a FUSE fs this is making things complicated, but not impossible, the fs needs to have a table of all mounted filesystems to determine a watch is set on a inode part of the fs or of another fs). When it is set on an object part of the fs, the fs can then translate the path relative to the mountpoint to an inode used internally by the fs or any other reference used to identify objects. This has to exist. The FUSE fs can then set a backend specific watch on the inode, and report anything back to the kernel when anything "happens", using the fuse_lowlevel_notify_.. calls. I haven't tested this through and through, so I do not know yet the inotify subsystem will pick up the changes reported by the fuse_lowlevel_notify_.. calls. Stef Bon > > NAK. > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdev= el" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.ht= ml -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html