On 2/18/07, Davide Libenzi <davidel@xmailserver.org> wrote:
Clets would execute in userspace, like signal handlers,
or like "event handlers" in cooperative multitasking environments without the Unix baggage
but under the special schedule() handler.
or, better yet, as the next tasklet in the chain after the softirq dispatcher, since I/Os almost always unblock as a result of something that happens in an ISR or softirq
In that way chains happens by the mean of natural C code, and access to userspace variables happen by the mean of natural C code too (not with special syscalls to manipulate userspace memory).
yep. That way you can exploit this nice hardware block called an MMU.
I'm not a big fan of chains of syscalls for the reasons I already explained,
to a kernel programmer, all userspace programs are chains of syscalls. :-)
but at least clets (or whatever name) has a way lower cost for the programmer (easier to code than atom chains),
except you still have the 80% of the code that is half-assed exception handling using overloaded semantics on function return values and a thread-local errno, which is totally unsafe with fibrils, syslets, clets, and giblets, since none of them promise to run continuations in the same thread context as the submission. Of course you aren't going to use errno as such, but that means that async-ifying code isn't s/syscall/aio_syscall/, it's a complete rewrite. If you're going to design a new AIO interface, please model it after the only standard that has ever made deeply pipelined, massively parallel execution programmer-friendly -- IEEE 754.
and for the kernel (no need of all that atom handling stuff,
you still need this, but it has to be centered on a data structure that makes request throttling, dynamic reprioritization, and bulk cancellation practical
no need of limited cond/jump interpreters in the kernel,
you still need this, for efficient handling of speculative execution, pipeline stalls, and exception propagation, but it's invisible to the interface and you don't have to invent it up front
and no need of nightmare compat code).
compat code, yes. nighmare, no. Just like kernel FP emulation on any processor other than an x86. Unimplemented instruction traps. x86 is so utterly the wrong architecture on which to prototype this it isn't even funny. Cheers, - Michael - 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/
