On Wed, 21 Feb 2007 22:15:21 +0100 Ingo Molnar wrote: > From: Ingo Molnar <[EMAIL PROTECTED]> > > Add Documentation/syslet-design.txt with a high-level description > of the syslet concepts.
Just a few comments & questions... > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> > Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]> > --- > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/