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

[Ingo Molnar]

* Randy Dunlap <randy.dunlap@xxxxxxxxxx> wrote:

> > + [ 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.

ok, fixed.

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

fixed - it's "in 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".

i've changed it to ', and thus user-space has to make sure'.

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

correct - we return a -EFAULT in that case. Should probably do something 
more distinguished though?

> > +	/*
> > +	 * 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()?

They used to initialize kernel-side stuff too, but now they only 
initialize the user-space-head structure: the ring and a 'head stack 
pointer'.

	Ingo
-
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/