Re: [patch 05/13] syslets: core, documentation

[Randy Dunlap]

On Wed, 21 Feb 2007 22:15:21 +0100 Ingo Molnar wrote:

> From: Ingo Molnar <mingo@xxxxxxx>
> 
> Add Documentation/syslet-design.txt with a high-level description
> of the syslet concepts.

Just a few comments & questions...

> Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
> Signed-off-by: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
> ---
>  Documentation/syslet-design.txt |  137 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 137 insertions(+)
> 
> Index: linux/Documentation/syslet-design.txt
> ===================================================================
> --- /dev/null
> +++ linux/Documentation/syslet-design.txt
> @@ -0,0 +1,137 @@
> +Syslets / asynchronous system calls
> +===================================
> +
> +the core syslet concepts are:
> +
> +The Syslet Atom:
> +----------------
> +
> +The syslet atom is a small, fixed-size (44 bytes on 32-bit) piece of
> +user-space memory, which is the basic unit of execution within the syslet
> +framework. A syslet represents a single system-call and its arguments.
> +In addition it also has condition flags attached to it that allows the
> +construction of larger programs (syslets) from these atoms.
> +
> +Arguments to the system call are implemented via pointers to arguments.
> +This not only increases the flexibility of syslet atoms (multiple syslets
> +can share the same variable for example), but is also an optimization:
> +copy_uatom() will only fetch syscall parameters up until the point it
> +meets the first NULL pointer. 50% of all syscalls have 2 or less
> +parameters (and 90% of all syscalls have 4 or less parameters).
> +
> + [ Note: since the argument array is at the end of the atom, and the
> +   kernel will not touch any argument beyond the final NULL one, atoms

I would s/final/first/ since one could put many (unneeded) NULL pointers
in the argument array.

> +   might be packed more tightly. (the only special case exception to
> +   this rule would be SKIP_TO_NEXT_ON_STOP atoms, where the kernel will
> +   jump a full syslet_uatom number of bytes.) ]
...

> +Completion of asynchronous syslets:
> +-----------------------------------
> +
> +Completion of asynchronous syslets is done via the 'completion ring',
> +which is a ringbuffer of syslet atom pointers user user-space memory,

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^^^^ ^^^^ ??

> +provided by user-space as an argument to the sys_async_exec() syscall.
> +The kernel fills in the ringbuffer starting at index 0, and user-space
> +must clear out these pointers. Once the kernel reaches the end of
> +the ring it wraps back to index 0. The kernel will not overwrite
> +non-NULL pointers (but will return an error), user-space has to
> +make sure it completes all events it asked for.

Last sentence is actually 2 sentences, so (e.g.) change the comma
to a semi-colon, xor begin the sentence with "Since".

How does the kernel return an error if the ring buffer is full?
Just a syscall negative error return code?


> +int main(int argc, char *argv[])
> +{
> +	unsigned long int fd_out = 1; /* standard output */
> +	char *buf = "Hello Syslet World!\n";
> +	unsigned long size = strlen(buf);
> +	struct syslet_uatom atom, *done;
> +
> +	async_head_init();
> +
> +	/*
> +	 * Simple syslet consisting of a single atom:
> +	 */
> +	init_atom(&atom, __NR_sys_write, &fd_out, &buf, &size,
> +		  NULL, NULL, NULL, NULL, SYSLET_ASYNC, NULL);

init_atom() (was) above.  sys_async_exec(), sys_async_wait() are
new syscalls.  What are async_head_init() and async_head_exit()?


> +	done = sys_async_exec(&atom);
> +	if (!done) {
> +		sys_async_wait(1);
> +		if (completion_ring[curr_ring_idx] == &atom) {
> +			completion_ring[curr_ring_idx] = NULL;
> +			printf("completed an async syslet atom!\n");
> +		}
> +	} else {
> +		printf("completed an cached syslet atom!\n");
> +	}
> +
> +	async_head_exit();
> +
> +	return 0;
> +}


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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/