On Mon, Sep 14, 2009 at 03:08:15PM -0400, Eric Paris (eparis@xxxxxxxxxx) 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
