A simpler variant on sys_indirect?

A simpler variant on sys_indirect?

[linux]

I was just thinking, while sys_indirect is an interesting way to add
features to a system call, the argument marshalling in user space is a
bit of a pain.

An alternate idea would be to instead have a "prefix system call" that
sets some flags that apply to the next system call made by that thread
only.  They wouldn't be global mode flags that would mess up libraries.

Maybe I've just been programming x86s too long, but this seems
like a nicer mental model.

The downsides are that you need to save and restore the prefix flags
across signal delivery, and you have a second user/kernel/user transition.

Most of the options seem to be applied to system calls that resolve
path names.  While that is certainly a very important code path, it's
also of non-trivial length, even with the dcache.  How much would one
extra kernel entry bloat the budget?

And if the kernel entry overhead IS a problem, wouldn't you want to
batch together the non-prefix system calls as well, using something like
the syslet ideas that were kicked around recently?  That would
allow less than 1 kernel entry per system call, even with prefixes.

Oh!  That suggests an interesting possibility that solves the signal
handling problem as well:
- Make a separate prefix system call, BUT
- The flags are reset on each return to user space, THUS
- You *have* to use a batch-system-call mechanism for the prefix
  system calls to do anything.

Of course, this takes us right back to the beginning with respect to
messy user-space argument marshalling.  But at least it's only one
indirect system call mechanism, not two.  Wrapping indirect system call
mechanism #1 (to set syscall options) in indirect system call mechanism
#2 (to batch system calls) seems like a bit of a nightmare.

I'm not at all sure that these are good ideas, but they're not obviously
bad ones, to me.  Is it worth looking for synergy between various
"indirect system call" ideas?

Re: A simpler variant on sys_indirect?

[Linus Torvalds]

On Sat, 30 Jun 2007, linux@horizon.com wrote:
> 
> The downsides are that you need to save and restore the prefix flags
> across signal delivery, and you have a second user/kernel/user transition.

Both of these are basically horrible mistakes. 

The first one will almost certainly break things that get clever, like 
strace, and just make things really hard to debug.

The second one means that you are guaranteed to be basically twice as slow 
on any fast system call, since the system call overhead itself is usually 
quite a noticeable cost, often dominating everything else.

> And if the kernel entry overhead IS a problem, wouldn't you want to
> batch together the non-prefix system calls as well, using something like
> the syslet ideas that were kicked around recently?  That would
> allow less than 1 kernel entry per system call, even with prefixes.

The batching has serious problems, not the least of which is that it's a 
fundamentally more complex interface, and introduces issues like "how do 
we pass values from one system call to the next". 

That's why I shot it down for syslets too. 

			Linus

Re: A simpler variant on sys_indirect?

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> The batching has serious problems, not the least of which is that it's a 
> fundamentally more complex interface, and introduces issues like "how do 
> we pass values from one system call to the next". 
> 

Why, we obviously need a Turing-complete language running in kernel 
space (interpreted, of course, to keep it secure.)  Pretty soon we can 
run the whole app in it, and we'll have to have a JIT to make it suck on 
less.  Since it's going to need caffeine, we can call it "Java."

	-hpa