On Wed, 30 May 2007, Ingo Molnar wrote: > > * Linus Torvalds <[EMAIL PROTECTED]> 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?)
I think, as Linus pointed out (as I did a few months ago), that there's confusion about the term "Unification" or "Single Interface". Unification is not about fetching all the data coming from the more diverse sources, into a single interface. That is just broken, because each data source wants a different data structure to be reported. This is ABI-hell 101. Unification is the ability to uniformly wait for readiness, and then fetch data with source-dependent collectors (read(2), io_getvents(2), ...). That way you have ABI isolation on the single data source, and not monster structures trying to blob together the more diverse data formats. AFAIK, inotify works with select/poll/epoll as is. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
