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/