Messages in this thread |  | | Date | Thu, 15 Feb 2007 13:17:14 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [patch 05/11] syslets: core code |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |