Hi!
> > The upcall will setup a frame, execute the clet (where jump/conditions and
> > userspace variable changes happen in machine code - gcc is pretty good in
> > taking care of that for us) on its return, come back through a
> > sys_async_return, and go back to userspace.
>
> So, for example, this is the setup code for the current API (and that's a
> really simple one - immagine going wacko with loops and userspace varaible
> changes):
>
>
> static struct req *alloc_req(void)
> {
> /*
> * Constants can be picked up by syslets via static variables:
> */
> static long O_RDONLY_var = O_RDONLY;
> static long FILE_BUF_SIZE_var = FILE_BUF_SIZE;
>
> struct req *req;
>
> if (freelist) {
> req = freelist;
> freelist = freelist->next_free;
> req->next_free = NULL;
> return req;
> }
>
> req = calloc(1, sizeof(struct req));
>
> /*
> * This is the first atom in the syslet, it opens the file:
> *
> * req->fd = open(req->filename, O_RDONLY);
> *
> * It is linked to the next read() atom.
> */
> req->filename_p = req->filename;
> init_atom(req, &req->open_file, __NR_sys_open,
> &req->filename_p, &O_RDONLY_var, NULL, NULL, NULL, NULL,
> &req->fd, SYSLET_STOP_ON_NEGATIVE, &req->read_file);
>
> /*
> * This second read() atom is linked back to itself, it skips to
> * the next one on stop:
> */
> req->file_buf_ptr = req->file_buf;
> init_atom(req, &req->read_file, __NR_sys_read,
> &req->fd, &req->file_buf_ptr, &FILE_BUF_SIZE_var,
> NULL, NULL, NULL, NULL,
> SYSLET_STOP_ON_NON_POSITIVE | SYSLET_SKIP_TO_NEXT_ON_STOP,
> &req->read_file);
>
> /*
> * This close() atom has NULL as next, this finishes the syslet:
> */
> init_atom(req, &req->close_file, __NR_sys_close,
> &req->fd, NULL, NULL, NULL, NULL, NULL, NULL, 0, NULL);
>
> return req;
> }
>
>
> Here's how your clet would look like:
>
> static long main_sync_loop(ctx *c)
> {
> int fd;
> char file_buf[FILE_BUF_SIZE+1];
>
> if ((fd = open(c->filename, O_RDONLY)) == -1)
> return -1;
> while (read(fd, file_buf, FILE_BUF_SIZE) > 0)
> ;
> close(fd);
> return 0;
> }
>
>
> Kinda easier to code isn't it? And the cost of the upcall to schedule the
> clet is widely amortized by the multple syscalls you're going to do inside
> your clet.
I do not get it. What if clet includes
int *a = 0; *a = 1; /* enjoy your oops, stupid kernel? */
I.e. how do you make sure kernel is protected from malicious clets?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/
