Messages in this thread |  | | Date | Mon, 20 May 1996 00:36:39 -0400 (EDT) | From | Ingo Molnar <> | Subject | Re: Proposal: merged system calls |
| |
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
|  |