On Wed, 28 Feb 2007, Ingo Molnar wrote:
> * Davide Libenzi <davidel@xmailserver.org> wrote:
>
> > 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.
Do you have a new version to review?
> > > 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.
Ok, we're past the error code in the atom, as Linus pointed out ;)
How about this, with async_wait returning asynid's back to a userspace
ring buffer?
struct syslet_utaom {
long *result;
unsigned long asynid;
unsigned long nr_sysc;
unsigned long params[8];
};
My problem with the syslets in their current form is, do we have a real
use for them that justify the extra complexity inside the kernel? Or with
a simple/parellel async submission, coupled with threadlets, we can cover
a pretty broad range of real life use cases?
- 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/
