On Thu, 15 Feb 2007, Linus Torvalds wrote:
>
>
> On Thu, 15 Feb 2007, Linus Torvalds wrote:
> >
> > So I think that a good implementation just does everything up-front, and
> > doesn't _need_ a user buffer that is live over longer periods, except for
> > the actual results. Exactly because the whole alloc/teardown is nasty.
>
> Btw, this doesn't necessarily mean "not supporting multiple atoms at all".
>
> I think the batching of async things is potentially a great idea. I think
> it's quite workable for "open+fstat" kind of things, and I agree that it
> can solve other things too (the "socket+bind+connect+sendmsg+rcv" kind of
> complex setup things).
If you *really* want to allow chains (note that the above could be
prolly be hosted on a real thread, once chains becomes that long), then
try to build that chain with the current API, and compare it with:
long my_clet(ctx *c) {
int fd, error = -1;
if ((fd = socket(...)) == -1 ||
bind(fd, &c->laddr, sizeof(c->laddr)) ||
connect(fd, &c->saddr, sizeof(c->saddr)) ||
sendmsg(fd, ...) == -1 ||
recv(fd, ...) <= 0)
goto
error = 0;
erxit:
close(fd);
return error;
}
Points:
- Keep the submission API to submit one or an array of parallel async
syscalls/clets
- Keep arguments of the syscall being longs (no need for extra pointer
indirection compat code, and special copy_atoms functions)
- No need for the "next" atom pointer chaining (nice for compat too)
- No need to create special conditions/jump interpreters into the kernel
(nice for compat and emulators). C->machine-code that that for us
- Easier to code. Try to build a chain like that with the current API and
you will see what I saying
- Did I say faster? Machine code is faster than sudo-VM interpretation of
jumps/conditions done inside the kernel
- 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/
