On Tuesday 13 September 2005 18:51, Bodo Stroesser wrote: > Jeff Dike wrote: > > On Sun, Sep 04, 2005 at 05:02:18PM +0200, Blaisorblade wrote:
> > I would be tempted to leave it in and fix it before 2.6.14. We need > > different ptrace codes so that UML knows how to switch interception > > types, I take it? Yes, that's the idea. > > UML is the only user, so there aren't really any compatibility issues. > > > >>On the host side, instead, supporting both the broken API and the new one > >> is more difficult. > > > > Yeah, and it shouldn't be done. This is one reason I'd like to use the > > same ptrace codes - it doesn't leave a hole in the codes that says there > > was a broken ABI there once. Do you see contiguos codes? We jump from 24 to 31-32 (it was done for something like having a common ABI with 2.4 and 2.6 hosts - don't ask me what filled previous slots, however), so you shouldn't worry for this. > >>What's your opinion on this? The options are: > >>1) merge it as-is > >>2) take it back for now, fix it and merge it for 2.6.15. > > Merge as-is, fix it before 2.6.13, and you get the same thing, except > > a release earlier. I think this shouldn't be a problem, as after the > > floodgates close, you still get to fix things you merged early. This > > came about as a result of feedback received because after it went into > > -mm, and it seems to me that this is a legitimate change for 2.6.14. > >>And then > >>2a) drop the trick, and avoid changing ptrace call numbers. Old UMLs > >>will run fast, but crash with /proc/sysemu (only root-accessible). > > We should drop /proc/sysemu, if it's there at all, since it's only for > > debugging sysemu, and maintain it as a private patch. So this doesn't > > seem like much of an issue. > > Jeff > It would be enough to make /proc/sysemu readonly. Yes, but my main concern is compatibility with existing binaries. They'll work as long as nobody tries to write on /proc/sysemu if the API is changed. However, I've put something together, so I've attached the host patch (I'm also a bit ill this days, so I want to make sure there's at least the possibility for anybody else to fix it). This has not yet been tested (I'm gonna do it) - but it seems that it's little enough to make the new behaviour a ptrace option, if needed. I wouldn't like to break in *anything* behaviour of old binaries, if possible. > But we need to change check_sysemu(). The current implementation will work > with the old API only. Would it refuse using sysemu or refuse to run at all? That's another interesting point. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade
sysemu-new-interface Signed-off-by: Paolo 'Blaisorblade' Giarrusso <[EMAIL PROTECTED]> --- linux-2.6.git-paolo/arch/i386/kernel/ptrace.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletion(-) diff -puN arch/i386/kernel/ptrace.c~sysemu-new-interface arch/i386/kernel/ptrace.c --- linux-2.6.git/arch/i386/kernel/ptrace.c~sysemu-new-interface 2005-07-27 20:38:35.000000000 +0200 +++ linux-2.6.git-paolo/arch/i386/kernel/ptrace.c 2005-07-27 20:40:25.000000000 +0200 @@ -749,7 +749,9 @@ int do_syscall_trace(struct pt_regs *reg send_sig(current->exit_code, current, 1); current->exit_code = 0; } - ret = is_sysemu; + /* The debugger might have changed the syscall intercepting mode. Apply + * this update now, rather than at next syscall. */ + ret = test_thread_flag(TIF_SYSCALL_EMU); out: if (unlikely(current->audit_context) && !entryexit) audit_syscall_entry(current, AUDIT_ARCH_I386, regs->orig_eax, _
