linux-kernel - Re: [RFC] Heads up on a series of AIO patchsets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061227162530.GA23000@infradead.org>
Date:	Wed, 27 Dec 2006 16:25:30 +0000
From:	Christoph Hellwig <hch@...radead.org>
To:	Suparna Bhattacharya <suparna@...ibm.com>
Cc:	linux-aio@...ck.org, akpm@...l.org, drepper@...hat.com,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	jakub@...hat.com, mingo@...e.hu
Subject: Re: [RFC] Heads up on a series of AIO patchsets

On Wed, Dec 27, 2006 at 09:08:56PM +0530, Suparna Bhattacharya wrote:
> (2) Most of these other applications need the ability to process both
>     network events (epoll) and disk file AIO in the same loop. With POSIX AIO
>     they could at least sort of do this using signals (yeah, and all associated
>     issues). The IO_CMD_EPOLL_WAIT patch (originally from Zach Brown with
>     modifications from Jeff Moyer and me) addresses this problem for native
>     linux aio in a simple manner. Tridge has written a test harness to 
>     try out the Samba4 event library modifications to use this. Jeff Moyer
>     has a modified version of pipetest for comparison.

The real question here is which interface we want people to use for these
"combined" applications.  Evgeny is heavily pushing kevent for this while
other seem to prefer integration epoll into the aio interface. (1)

I must admit that kevent seems to be the cleaner way to support this,
although I see some advantages for the aio variant.  I do think however
that we should not actively promote two differnt interfaces long term.


(1) note that there is another problem with the current kevent interface,
	and that is that it duplicates the event infrastructure for it's
	underlying subsystems instead of reusing existing code (e.g.
	inotify, epoll, dio-aio).  If we want kevent to be _the_ unified
	event system for Linux we need people to help out with straightening
	out these even provides as Evgeny seems to be unwilling/unable to
	do the work himself and the duplication is simply not acceptable.

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