[lkml]   [2007]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2 of 4] Introduce i386 fibril scheduling

* Matt Mackall <> wrote:

> On Sat, Feb 03, 2007 at 09:23:08AM +0100, Ingo Molnar wrote:
> > The normal and most optimal workflow should be a user-space ring-buffer
> > of these constant-size struct async_syscall entries:
> >
> > struct async_syscall ringbuffer[1024];
> >
> > LIST_HEAD(submitted);
> > LIST_HEAD(pending);
> > LIST_HEAD(completed);
> It's wrong to call this a ring buffer as things won't be completed in
> any particular order. [...]

yeah, i realized this when i sent the mail. I wanted to say 'array of
elements' - and it's clear from these list heads that it's fully out of
order. (it should be an array so that the pages of those entries can be
pinned and that completion can be manipulated from any context,

(the queueing i described closely resembles Tux's "Tux syscall request"
handling scheme.)

> [...] So you'll need a fourth list head for which buffer elements are
> free. At which point, you might as well leave it entirely up to the
> application to manage the allocation of async_syscall structs. It may
> know it only needs two, or ten thousand, or five per client...

sure - it should be variable but still the array should be compact, and
should be registered with the kernel. That way security checks can be
done once, the pages can be pinned, accessed anytime, etc.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-02-03 11:23    [W:0.235 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site