DragonFly kernel List (threaded) for 2003-07
Re: You could do worse than Mach ports
:Matthew Dillon wrote:
:> For system calls the foreign address space is the user process's
:> address space. User data pointers come in three forms:
:> (1) They represent a file path
:> (2) They represent a large block of data (e.g. the buffer in a read())
:> (3) They represent a small block of data (e.g. gettimeofday()).
:> (4) They represent the message itself
:What component is responsible for this rewriting?
Probably the syscall code in the kernel. The first thing it would do
is translate the message. This could impose possible stall points
taking the syscall if the smaller blocks of data or the message
page-fault (which is unlike to occur since they were just built by
userland). The big blocks of data would not stall since it is only
figuring out the VM object(s), offsets, and ranges.
: The wrapper or other user code?
: Send() to kernel?
: The receiving system call?
: Something in between?
:Could it be table-driven? If so, then the table could provide a place to
: handle versioning...
All of our syscall entry points are individual procedures and most
of them already do things like copyin smaller arguments. The only
real work we would wind up doing is converting the large block
references to the new UIO scheme (which I'm working on as we speak,
it's a necessary precursor to the DEV work since DEV will no longer
have direct access to userspace).
So, no, making it table driven would take a lot longer to do and
probably not perform as well.