Messages in this thread | | | Subject | Re: [patch] fastcall-2.3.32-B6, SYSENTER/SYSEXIT support | From | Peter Samuelson <> | Date | 13 Dec 1999 14:16:58 -0600 |
| |
[Richard Gooch <rgooch@ras.ucalgary.ca>] > I propose a much simpler abstraction: set up a global page (which > always appears at a fixed address in user-space), and set up a jump > table. Have one jump vector per system call. That's the ABI. End of > story.
I add my <AOL> to those who have already spoken favorably of this....
> I'm happy with the page mapping idea, but what concerns me is that we > can end up with a kernel which has a fair bit of code data embedded > in it, due to the increasing number of syscall instructions.
We are still talking ia32 only, right? Because the SPARC people would *really* have fun with this sort of proposal....
> Even if it's contained in __init sections, it still bloats the kernel > image. This is a particular problem with embedded systems. Config > options will help here, but we have too many of those already.
Two extra options, the way I see it:
tristate " Set up new system call interfaces dynamically" CONFIG_NEW_SYSCALLS if [ "$CONFIG_NEW_SYSCALLS" != "n" ]; then bool " Optimize only for lowest-common-denomenator CPU type" CONFIG_NEW_SYSCALLS_LCD fi
The second would mean if you compile for 586TSC, the setup code only knows about a 586TSC-compatible jump table -- nothing newer or older.
Red Hat would ship CONFIG_386 and CONFIG_NEW_SYSCALLS_LCD=n.
> 2) have a single module which contains all the code data variants and > writes the appropriate selection to the global page(s)
I vote for this, but it is monolithic-capable (__init) as well.
Peter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |