From mboxrd@z Thu Jan 1 00:00:00 1970 From: Clemens Ladisch Subject: Re: [RFC PATCH 0/3] epoll: read(),write(),ioctl() interface Date: Mon, 03 Feb 2014 10:43:42 +0100 Message-ID: <52EF64CE.90506@ladisch.de> References: <1391393832-8754-1-git-send-email-n1ght.4nd.d4y@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: Nathaniel Yazdani , viro@zeniv.linux.org.uk Return-path: In-Reply-To: <1391393832-8754-1-git-send-email-n1ght.4nd.d4y@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Nathaniel Yazdani wrote: > Using the normal I/O interface to manipulate eventpolls is much neater > than using epoll-specific syscalls But it introduces a _second_ API, which is epoll-specific too, and does not use the standard semantics either. > while also allowing for greater flexibility (theoretically, pipes could > be used to filter access). I do not understand this. > read() simply waits for enough events to fill the provided buffer. The usual semantics of read() are to return a partially filled buffer if it would block otherwise, i.e., blocking is done only if the returned buffer would have been empty. > As timeout control is essential for polling to be practical, ioctl() is > used to configure an optional timeout This is what the timeout parameter of poll() and friends is for. Regards, Clemens