On Thu, Mar 18, 2010 at 12:15, Ingo Molnar <mingo@xxxxxxx> wrote:
I didnt say it's glibc's fault - if then it's more of the kernel's fault as most of the complexity is on that side. I said it's due to the fundamental distance between the app that makes use of it, the library and the kernel, and the resulting difficulties in getting a combined solution out.
This is wrong, too. Once there is a kernel patch that has a reasonable syscall interface it's easy enough to hack up the glibc side. Don't try to artificially find an argument to support your thesis. If kernel developers always need an immediate itch which lives inside the kernel walls to make a change this is a failure of the kernel model and mustn't be "solved" by dragging ever more code into the kernel. Aside, you don't need a full-fledged glibc implementation for testing. Especially for AIO it should be usable in much lighter-weight contexts than POSIX AIO. These wrappers are even more easy to hack up (and have been in the few cases where some code has been produced). For AIO the situation isn't that the people interested in working on it don't know or care about the use. Zach (through Oracle's products) is very much interested in the code and knows how it should look like. Face it, AIO is an example of a complete failure of the kernel developers to provide something usable. This was the argument and where you started the misdirection of including other projects in the reasoning.
Attachment:
signature.asc
Description: OpenPGP digital signature
