just curious

[Peter da Silva]

>     This sounds suspiciously like transaction support.   One could 
>     theoretically bundle several syscall messages together and ask the kernel
>     to act on them atomically.

Actually, I was thinking of the flipside of this (your next paragraph,
about reducing syscall overhead), with the application code being the same
whether the calls were bundled or not (that is, the bundles would be sent
concurrently the next time the application performed a Wait()). I hadn't
thought of making this any more user-visible than that.

But yes, I could see passing a *list* of messages to a port to complete
atomically. Something like:

    initSysWriteMsg(&basemsg, myusercpu->replyport, fd1, buf, bytes);
    initSysWriteMsg(&newmsg, myusercpu->replyport, fd2, buf, bytes);

    basemsg.transactionType = newmsg.transactionType = T_ATOMIC;
    basemsg.nextMessage = &newmsg;

    error = _syscallport->mp_SendMsg(syscallport, &msg);
    if (error == EASYNC) {
        uthread_scheduler_wait_all(&msg);  /* upcall equiv / switch away */
        ... blocks ...
        for(mp = &basemsg; mp; mp = mp->transLink) {
            error = mp->errno;
            if (error) {
                ... unwind transaction ...
            }
        }
    }

    myuserthread->td_errno = error;
    return(msg.retcode);

>     One could also very easily bundle several syscall messages together
>     for the purposes of reducing syscall overhead.  i.e. one transition into
>     the kernel, run N system calls in order, one transition back to userland.

Yeh, this is what I see as the place that microkernel designs have room
for performance wins. It's like RISC processors: you've got more instructions 
(messages) and each does less of the job, but you can schedule them
better and avoid pipeline bubbles.

Which makes the UNIX API emulation sort of like the Crusoe . :)

>     That's a very big deal!  It makes me want to tackle the syscall
>     messaging next, but I'm set on doing DEV first.  Maybe I'll tackle
>     the basic syscall messaging support before I do VFS.

Bear in mind that when you go to messaging syscalls is when you break
existing userland, no? :) Or are you planning on leaving that in place
and eventually feeding it to an emulator?