On Thu, Jun 07, 2007 at 01:10:23PM -0700, Linus Torvalds wrote: > What do people think about that kind of approach? It has the advantage > that it does *not* involve multiple kernel entries (just a single entry to > a small wrapper that sets some process state temporarily), and that it > doesn't have any sticky state that might confuse a library (or a signal > handler: even if you end up doing "prctrl(ON) ; syscall(); prctrl(OFF)", a > signal handler that happens in between the prctrl's would see unexpected > behaviour).
First, how does this work in-kernel? Does it set a flag in the thread struct that magically gets used in the actual syscall? Or do we pass flags down to the sys_foo() function in some manner? If the former, there is potential for interaction with asynchronous code running on behalf of the thread, no? Especially if we ever adopt one of the syslet schemes. Second, I think we're likely to run out of flag bits really quickly as this is a good dumping spot for patching up our many slightly brain-damaged APIs (be they POSIX or Linux-specific). Third, can I do sys_indirect(sys_indirect(foo, args), flags1), flags2)? Fourth, can we do sys_indirect(foo, args, flags | ASYNC) and get most of the way to merging this with the syslet proposal? -- Mathematics is the supreme nostalgia of our time. - 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/
