On Sun, 19 May 1996, Pedro Roque Marques wrote:
[ networking zero copy thoughts ]
> Ingo> does this "merging" stuff make sense?
>
> sense ?! well for the cases where such syscalls were defined it could
> boost performance but it is very very uggly IMHO and not generic enhought
> i believe.
i think i wasnt clear enough what i understand under "merging". Consider
the following model:
we have "basic system calls":
file system calls: - open, create, read, write, writev, close, (many more)
process state system calls: - getpid, getpgrp, (and many more)
memory system calls: - mmap, mmunmap, mprotect, mlock, munlock, mremap
syncronisation calls: - sys_ipc, select, wait4, (and many more)
(and many more, 163 currently)
There are pairings which are often executed after each other:
open + read
fork + wait4
select + read
sys_ipc + read
read + send + listen
recv + write
This was the point where i thought that maybe it makes sense to make these
pairings "effective". No real information flow happens between kernel and
user space between these two calls.
One implementation could be a "system call list" :
sys_execute_stack( list );
, where list is a predefined list of system call numbers and parameters.
The parsing of this list would be about the same mechanism that happens
when ordinary system calls get parsed.
This interface doesnt specify possible information flow between these
system calls. I dont really know what the solution should be. I dont even
know if there is a problem.
-- mingo