Messages in this thread | | | Date | Tue, 17 Dec 2002 09:55:13 -0800 | From | Ulrich Drepper <> | Subject | Re: Intel P6 vs P7 system call performance |
| |
Linus Torvalds wrote:
> Yeah, it's not very convenient. I didn't find any real alternatives, > though, and you can always just put 0xfffff000 in memory or registers and > jump to that.
Putting the value into memory myself is not possible. In a DSO I have to address memory indirectly. But all registers (except %ebp, and maybe it'll be used some day) are used at the time of the call.
But there is a way: if I'm using
#define makesyscall(name) \ movl $__NR_##name, $eax; \ call 0xfffff000-__NR_##name($eax)
and you'd put at address 0xfffff000 the address of the entry point the wrappers wouldn't have any problems finding it.
> In fact, I suspect that if you actually want to use it in > glibc, then at least in the short term that's what you need to do anyway, > sinc eyou probably don't want to have a glibc that only works with very > recent kernels.
That's a compilation option. We might want to do dynamic testing and yes, a simple pointer indirection is adequate.
But still, the problem is detecting the capable kernels. You have said not long ago that comparing kernel versions is wrong. And I agree. It doesn't cover backports and nothing. But there is a lack of an alternative.
If you don't like the process-global page thingy (anymore) the alternative would be a sysconf() system call.
-- --------------. ,-. 444 Castro Street Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA Red Hat `--' drepper at redhat.com `---------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |