Re: Syslets, Threadlets, generic AIO support, v6

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > To echo Uli and paraphrase an ad, "it's the interface, silly."
> 
> THERE IS NO INTERFACE! You're just making that up, and glossing over 
> the most important part of the whole thing!
> 
> If you could actually point to something specific that matches what 
> everybody needs, and is architecture-neutral, it would be a different 
> issue. As is, you're just saying "memory-mapped interfaces" without 
> actually going into enough detail to show HOW MUCH IT SUCKS.
> 
> There really are very few programs that would use them. [...]

looking over the list of our new generic APIs (see further below) i 
think there are three important things that are needed for an API to 
become widely used:

 1) it should solve a real problem (ha ;-), it should be intuitive to 
    humans and it should fit into existing things naturally.

 2) it should be ubiquitous. (if it's about IO it should cover block IO,
    network IO, timers, signals and everything) Even if it might look
    silly in some of the cases, having complete, utter, no compromises,
    100% coverage for everything massively helps the uptake of an API, 
    because it allows the user-space coder to pick just one paradigm 
    that is closest to his application and stick to it and only to it.

 3) it should be end-to-end supported by glibc.

our failed API attempts so far were:

 - sendfile(). This API mainly failed on #2. It partly failed on #1 too.
   (couldnt be used in certain types of scenarios so was unintuitive.)
   splice() fixes this almost completely.

 - KAIO. It fails on #2 and #3.

our more successful new APIs:

 - futexes. After some hickups they form the base of all modern 
   user-space locking.

 - splice. (a bit too early to tell but it's looking good so far. Would
   be nice if someone did a brute-force memcpy() based vmsplice to user
   memory, just to make usage fully symmetric.)

partially successful, not yet failed new APIs:

 - epoll. It currently fails at #2 (v2.6.22 mostly fills the gaps but
   not completely). Despite the non-complete coverage of event domains a
   good number of apps are using it, and in particular a couple really
   'high end' apps with massive amounts of event sources - which apps 
   would have no chance with poll, select or threads.

 - inotify. It's being used quite happily on the desktop, despite some
   of its limitations. (Possibly integratable into epoll?)

	Ingo