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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
