search for: config_syscall_

...ut that tends to produce a net increase in lines of code, as well as duplicating all the function prototypes, which to me seems more error-prone. If the stub versions contained any code, rather than just becoming no-ops, I'd definitely do that. > Another nit may be that we should call this CONFIG_SYSCALL_IOPL or > CONFIG_SYSCALL_IOPERM in keeping with the other CONFIG_SYSCALL_* > naming thread? Again, I don't really care strongly beyond really > wanting to use this new feature! :) I don't feel strongly about the naming. Ingo? > Thanks for working on this! No problem. I look...

...ut that tends to produce a net increase in lines of code, as well as duplicating all the function prototypes, which to me seems more error-prone. If the stub versions contained any code, rather than just becoming no-ops, I'd definitely do that. > Another nit may be that we should call this CONFIG_SYSCALL_IOPL or > CONFIG_SYSCALL_IOPERM in keeping with the other CONFIG_SYSCALL_* > naming thread? Again, I don't really care strongly beyond really > wanting to use this new feature! :) I don't feel strongly about the naming. Ingo? > Thanks for working on this! No problem. I look...

...s well as duplicating all the > function prototypes, which to me seems more error-prone. If the > stub versions contained any code, rather than just becoming no-ops, I'd > definitely do that. > I concur with this style choice. >> Another nit may be that we should call this CONFIG_SYSCALL_IOPL or >> CONFIG_SYSCALL_IOPERM in keeping with the other CONFIG_SYSCALL_* >> naming thread? Again, I don't really care strongly beyond really >> wanting to use this new feature! :) > > I don't feel strongly about the naming. Ingo? It is sort of a special case her...

...copy_io_bitmap(struct task_struct *me, struct task_struct *p) { return 0; } ...remaining functions... #endif /* CONFIG_X86_IOPORT */ But this is entirely a style decision, so I leave it up to the x86 maintainers ... Another nit may be that we should call this CONFIG_SYSCALL_IOPL or CONFIG_SYSCALL_IOPERM in keeping with the other CONFIG_SYSCALL_* naming thread? Again, I don't really care strongly beyond really wanting to use this new feature! :) Thanks for working on this! -Kees > + > static inline int copy_io_bitmap(struct task_struct *me, >...

On the vast majority of modern systems, no processes will use the userspsace I/O syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of

On the vast majority of modern systems, no processes will use the userspsace I/O syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of

The 32-bit and 64-bit versions of copy_thread have functionally identical handling for copying the I/O bitmap, modulo differences in error handling. Clean up the error paths in both by moving the copy of the I/O bitmap to the end, to eliminate the need to free it if subsequent copy steps fail; move the resulting identical code to a static inline in a common header. Signed-off-by: Josh Triplett

The 32-bit and 64-bit versions of copy_thread have functionally identical handling for copying the I/O bitmap, modulo differences in error handling. Clean up the error paths in both by moving the copy of the I/O bitmap to the end, to eliminate the need to free it if subsequent copy steps fail; move the resulting identical code to a static inline in a common header. Signed-off-by: Josh Triplett