> On Sun, 19 May 1996, Bryn Paul Arnold Jones wrote:
>
> 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).
>
It's still more syscalls, I'd have no more, that's my point. You'd have
one for each merged syscall (ok, we're being smart, only merging ones
that are commonly done one after the other).
> 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.
>
Ok, ignore the bits saying that the kernel would have to recognise ....,
the same argument holds, but the merging happens in user space (the lib,
or gcc, or whereever), and we only have to tell the kernel stick this
syscall here, (no I don't know how syscalls get passed to the kernel, and
I don't have a syscall man page:(, i'm assumeing that something like a
syscall(number, args, ...) is right ), ie
syscall(number1, various_args1, number2, varous_args2, more_args1, ...)
will work. Oh, thanks for pointing it out, gcc could "cluster" the
syscalls too (more savings, you don't even have to think, just recompile
with a switch on ;).
> 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 :) :(
>
Yep, I saw that sometime (an hour or too) after writing :| ....
> -- mingo
>
>
Bryn
--
PGP key pass phrase forgotten, \ Overload -- core meltdown sequence
again :( | initiated.
/ This space is intentionally left
| blank, apart from this text ;-)
\____________________________________