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: <20061227165500.GB10077@elte.hu>
Date:	Wed, 27 Dec 2006 17:55:00 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Christoph Hellwig <hch@...radead.org>
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

* Christoph Hellwig <hch@...radead.org> wrote:

> 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.

i see no fundamental disadvantage from doing both. That way the 'market' 
of applications will vote. (we have 2 other fundamental types available 
as well: sync IO and poll() based IO - so it's not like we have the 
choice between 2 or 1 variant, we have the choice between 4 or 3 
variants)

> (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.

yeah. The internal machinery should be as unified as possible - but 
different sets of APIs can be offered, to make it easy for people to 
extend their existing apps in the most straightforward way.

(In fact i'd like to see all the 'poll table' code to be unified into 
this as well, if possible - it does not really "poll" anything, it's an 
event infrastructure as well, used via the naive select() and poll() 
syscalls. We should fix that naming mistake.)

	Ingo
-
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/