On Wed, 28 Feb 2007, Ingo Molnar wrote:
>
> * Davide Libenzi <davidel@xmailserver.org> 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:
>
> #ifdef CONFIG_COMPAT
>
> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
