Subject: Re: [RFC][PATCH] inotify 0.10.0
From: John McCutchan <ttb@tentacle.dhs.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Ray Lee <ray-lk@madrabbit.org>, rml@novell.com,
       linux-kernel@vger.kernel.org, gamin-list@gnome.org,
       viro@parcelfarce.linux.theplanet.co.uk, iggy@gentoo.org
In-Reply-To: <20040928120830.7c5c10be.akpm@osdl.org>
References: <1096250524.18505.2.camel@vertex>
	 <20040926211758.5566d48a.akpm@osdl.org>
	 <1096318369.30503.136.camel@betsy.boston.ximian.com>
	 <1096350328.26742.52.camel@orca.madrabbit.org>
	 <20040928120830.7c5c10be.akpm@osdl.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1096404035.30123.22.camel@vertex>
Mime-Version: 1.0
Date: Tue, 28 Sep 2004 16:40:35 -0400
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1474
Lines: 33

On Tue, 2004-09-28 at 15:08, Andrew Morton wrote:
> Ray Lee <ray-lk@madrabbit.org> wrote:
> >
> > The current way pads out the structure unnecessarily, and still doesn't
> > handle the really long filenames, by your admission. It incurs extra
> > syscalls, as few filenames are really 256 characters in length. 
> 
> Why don't you pass a file descriptor into the syscall instead of a pathname?
> You can then take a ref on the inode and userspace can close the file.
> That gets you permission checking for free.
> 

I don't think moving inotify to a syscall based interface is worth it.

First off, on startup, this would require about 2k open() calls,
followed by 2k syscalls to inotify. Not as nice as just 2k ioctl()
calls.

The character device interface right now suits it perfectly. If we used
syscalls we would need to provide a syscall that gives user space a FD
that it can read events on, then more 2 more syscalls to provide the
watch and ignore functionality. Switching to the syscall interface would
also require implementing the idea of the inotify device instance
without the assistance of the char device subsystem. If the ioctl()
based interface is so bad, we could change it to a write() based
interface.

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