DragonFly kernel List (threaded) for 2003-07
Re: just curious
: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 :-).