Re: just curious

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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;
:...

   Oh, scary thought... you could 'append' new messages to the linked list
   WHILE the system is running the chain.  The system would return a
   completion of some sort so you would know whether you won or lost the
   race.  This would provide an incredible economy of scale to certain
   specialized applications like web servers by allowing a pipeline of 
   system call requests to be maintained and thus remove ALL unnecessary
   system call overhead during times of heavy load.

: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?

    I've thought about that a bit more, and I think the time we break the
    API is when we have the emulation layer ready to go (and thus we wind
    up not actually breaking the API :-)).  

    Adding the syscall messaging interface itself does NOT need to break the
    API.  In FreeBSD system calls are already implemented by passing a
    structure pointer containing the syscall's arguments (it's basically a
    template based on the stack format of the syscall arguments).  The work
    involved in changing the supplied arguments pointer to a lwkt_msg
    structure is easy.  A lot of typing editing dozens of files, yes, but
    easy.  The existing syscall vec would simply create a pseudo
    'synchronous' message to remain compatible with the new interface, so
    the same system call procedures can be used for both the old AND new
    interfaces during the transition period.  

    Since it costs us nothing to retain the original API until the emulation
    layer is ready, we might as well retain it.  People coming in from 4.x
    will thank us for it because their machines will still be able to boot
    into the new kernel :-).

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>