* Davide Libenzi <davidel@xmailserver.org> wrote:
> 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? :)
no, i made the 64-bit and 32-bit structures layout-compatible. This
makes the 32-bit structure as large as the 64-bit ones, but that's not a
big issue, compared to the simplifications it brings.
> > 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 [...]
the thing is, there's almost zero overhead from having those basic
things like conditions and the ->next link, and they make it so much
more capable. As usual my biggest problem is that you are not trying to
use syslets at all - you are only trying to get rid of them ;-) My
purpose with syslets is to enable a syslet to do almost anything that
user-space could do too, as simply as possible. Syslets could even
allocate user-space memory and then use it (i dont think we actually
want to do that though). That doesnt mean arbitrary complex code
/should/ be done via syslets, or that it wont be significantly slower
than what user-space can do, but i'd not like to artificially dumb the
engine down. I'm totally willing to simplify/shrink the vectoring of
arguments and just about anything else, but your proposals so far (such
as your return-value-embedded-in-atom suggestion) all kill important
aspects of the engine.
All the existing syslet features were purpose-driven: i actually coded
up a sample syslet, trying to do something that makes sense, and added
these features based on that. The engine core takes up maybe 50 lines of
code.
Ingo
-
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/
