Re: [patch 05/11] syslets: core code

[Michael K. Edwards]

On 2/18/07, Davide Libenzi <davidel@xxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/