Messages in this thread | | | Date | Sat, 19 Oct 2002 06:45:56 +0200 | From | Andi Kleen <> | Subject | Re: [PATCH] linux-2.5.43_vsyscall_A0 |
| |
On Sat, Oct 19, 2002 at 06:10:19AM +0200, Andrea Arcangeli wrote: > On Fri, Oct 18, 2002 at 11:49:59PM -0500, Jeff Dike wrote: > > ak@muc.de said: > > > Guess you'll have some problems then with UML on x86-64, which always > > > uses vgettimeofday. But it's only used for gettimeofday() currently, > > > perhaps it's not that bad when the UML child runs with the host's > > > time. > > > > It's not horrible, but it's still broken. There are people who depend > > on UML being able to keep its own time separately from the host. > > > > > I guess it would be possible to add some support for UML to map own > > > code over the vsyscall reserved locations. UML would need to use the > > > syscalls then. But it'll be likely ugly. > > > > Yeah, it would be. > > > > My preferred solution would be for libc to ask the kernel where the vsyscall > > area is. That's reasonably clean and virtualizable. Andrea doesn't like it > > because it adds a few instructions to the vsyscall address calculation. > > yes, my preferred solution is still a runtime /proc entry that turns off > vsyscalls completely by root so you could trap gettimeofday/time via the > usual ptrace. That would be zero cost. Of course this would be needed
Ok, a sysctl that modifies a variable in the vsyscall page and is tested by the code. That would be an option, I agree.
For the locked TSC code we will need something like that anyways, so that locked TSC can force a syscall.
-Andi - 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/
| |