Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support

[Jeremy Fitzhardinge <jeremy@goop.org>]

Ingo Molnar wrote:
> Syslets consist of 'syslet atoms', where each atom represents a single 
> system-call. These atoms can be chained to each other: serially, in 
> branches or in loops. The return value of an executed atom is checked 
> against the condition flags. So an atom can specify 'exit on nonzero' or 
> 'loop until non-negative' kind of constructs.
>
> Syslet atoms fundamentally execute only system calls, thus to be able to 
> manipulate user-space variables from syslets i've added a simple special 
> system call: sys_umem_add(ptr, val). This can be used to increase or 
> decrease the user-space variable (and to get the result), or to simply 
> read out the variable (if 'val' is 0).
>   

This looks very interesting.  A couple of questions:

Are there any special semantics that result from running the syslet
atoms in kernel mode?  If I wanted to, could I write a syslet emulation
in userspace that's functionally identical to a kernel-based
implementation?  (Obviously the performance characteristics will be
different.)

I'm asking from the perspective of trying to work out the Valgrind
binding for this if it goes into the kernel.  Valgrind needs to see all
the input and output values of each system call the client makes,
including those done within the syslet mechanism.  It seems to me that
the easiest way to do this would be to intercept the syslet system
calls, and just implement them in usermode, performing the same series
of syscalls directly, and applying the Valgrind machinery to each one in
turn.

Would this work?

Also, an unrelated question: is there enough control structure in place
to allow multiple syslet streams to synchronize with each other with
futexes?

Thanks,
    J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/