Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757121AbZIOUQX (ORCPT ); Tue, 15 Sep 2009 16:16:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757386AbZIOUQT (ORCPT ); Tue, 15 Sep 2009 16:16:19 -0400 Received: from tservice.ru ([195.178.208.66]:46945 "EHLO tservice.net.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753552AbZIOUQS (ORCPT ); Tue, 15 Sep 2009 16:16:18 -0400 Date: Wed, 16 Sep 2009 00:16:20 +0400 From: Evgeniy Polyakov To: Eric Paris Cc: Jamie Lokier , David Miller , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, viro@zeniv.linux.org.uk, alan@linux.intel.com, hch@infradead.org, torvalds@linux-foundation.org Subject: Re: fanotify as syscalls Message-ID: <20090915201620.GB32192@ioremap.net> References: <20090911.114620.260824240.davem@davemloft.net> <1252697613.2305.38.camel@dhcp231-106.rdu.redhat.com> <20090911204602.GA19371@shareable.org> <1252703626.2305.50.camel@dhcp231-106.rdu.redhat.com> <20090911212731.GA19901@shareable.org> <1252705902.2305.83.camel@dhcp231-106.rdu.redhat.com> <20090912094110.GB24709@ioremap.net> <20090914001759.GB30621@shareable.org> <20090914140720.GA8564@ioremap.net> <1252955295.2246.35.camel@dhcp231-106.rdu.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1252955295.2246.35.camel@dhcp231-106.rdu.redhat.com> User-Agent: Mutt/1.5.13 (2006-08-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1824 Lines: 41 On Mon, Sep 14, 2009 at 03:08:15PM -0400, Eric Paris (eparis@redhat.com) wrote: > Just this week I got another request to look at syscalls. So I did, I > haven't prototyped it, but I can do it with syscalls, they would look > like this: > > int fanotify_init(int flags, int f_flags, __u64 mask, unsigned int priority); ... > Are there demands that I convert to syscalls? Do I really gain anything > using 9 new inextensible syscalls over socket(), bind(), and 8 > setsockopt() calls? In my personal opinion sockets are way much simpler and obvious than syscalls. Also one should not edit hundred of arch-dependant headers conflicting with other pity syscallers. But implementing af_fanotify opens a door for zillions of other af_something which can be implemented using existing infrastructure namely netlink will solve likely 99% of potential usage cases. And frankly I did not find it way too convincing that using netlink is impossible in your scenario if some things will be simplified, namely event merging. Moreover you can implement a pool of working threads and postpone all the work to them and appropriate event queues, which will allow to use rlimits for the listeners and open files 'kind of' on behalf of those processes. But it is quite diferent from the approach you selected and which is more obvious indeed. So if you ask a question whether fanotify should use sockets or syscalls, I would prefer sockets, but I still recommend to rethink your decision to move away from netlink to be 100% sure that it will not solve your needs. -- Evgeniy Polyakov -- 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/