> Hmm, woulden't makeing this work:
>
> send( 5, read( 4, NULL, 100), 100, 0);
>
> be easyer, better than thousands of new syscalls too (ok NULL is a bad
> value, but I don't know what to but). The kernel would have to recognise
> it's being passed a syscall as an argument, and do them both. It would
> have to be decided wether only one level of syscall's is allowed, or
> multiple. eg wether:
>
> send( 5, read( open( "/whatever", O_RDONLY), NULL, lenfile( "/whatever")), lenfile( "/whatever"), 0);
>
> works or not. It may be longer, but if it ment that we'd only need one
> switch to kernel space .... Ofcourse, if one one part failed, it all
> would. Returning error modes could be a problem, but then we would only
> need to say which part failed, with the approprate errno. I know, bloat,
> but it's not as much as zillions of new syscalls, and if the speedup
> avalable warents it ....
no, i want to avoid extra syscalls. the point was to introduce >one< new
syscall that can handle "multiple syscalls at once". (this new syscalls
needs lots of parameters to signal which syscalls should be executed and
how).
and you example is not correct, syscall translation happens at gcc level,
the kernel simply cant know that those two syscalls are "merged". If we
had such a "merging interface", then gcc probably could optimize by
"clusterising" system calls.
But Alan Cox's comments pointed out that the major advantage - avoiding
copying between user space and kernel space - doesnt really exist, the
viability of such an interface is questionable :) :(
-- mingo