[lkml]   [2007]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
On Wed, 28 Feb 2007, Ingo Molnar wrote:

> * Davide Libenzi <> wrote:
> > My point is, the syslet infrastructure is expensive for the kernel in
> > terms of compat, [...]
> it is not. Today i've implemented 64-bit syslets on x86_64 and
> 32-bit-on-64-bit compat syslets. Both the 64-bit and the 32-bit syslet
> (and threadlet) binaries work just fine on a 64-bit kernel, and they
> share 99% of the infrastructure. There's only a single #ifdef
> CONFIG_COMPAT in kernel/async.c:
> asmlinkage struct syslet_uatom __user *
> compat_sys_async_exec(struct syslet_uatom __user *uatom,
> struct async_head_user __user *ahu)
> {
> return __sys_async_exec(uatom, ahu, &compat_sys_call_table,
> compat_NR_syscalls);
> }
> #endif

Did you hide all the complexity of the userspace atom decoding inside
another function? :)
How much code would go away, in case we pick a simple/parallel
sys_async_exec engine? Atoms decoding, special userspace variable access
for loops, jumps/cond/... VM engine.

> Even mixed-mode syslets should work (although i havent specifically
> tested them), where the head switches between 64-bit and 32-bit mode and
> submits syslets from both 64-bit and from 32-bit mode, and at the same
> time there might be both 64-bit and 32-bit syslets 'in flight'.
> But i'm happy to change the syslet API in any sane way, and did so based
> on feedback from Jens who is actually using them.

Wouldn't you agree on a simple/parallel execution engine like me and Linus
are proposing (and threadlets, of course)?

- Davide

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-28 22:13    [W:0.272 / U:0.684 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site