Re: [uml-devel] SYSEMU getting merged - but I'm in doubt

[Blaisorblade <blaisorblade@yahoo.it>]

[-- Attachment #1: Type: text/plain, Size: 2789 bytes --]

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

[-- Attachment #2: sysemu-new-interface.patch --]
[-- Type: text/x-diff, Size: 932 bytes --]

sysemu-new-interface


Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---

 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,
_