From: Renzo Davoli <renzo@cs.unibo.it>
To: Am??rico Wang <xiyou.wangcong@gmail.com>
Cc: linux-kernel@vger.kernel.org, Jeff Dike <jdike@addtoit.com>,
user-mode-linux-devel@lists.sourceforge.net,
mtk.manpages@gmail.com, Roland McGrath <roland@redhat.com>
Subject: Re: [PATCH 0/2] ptrace_vm: ptrace for syscall emulation virtual machines
Date: Wed, 25 Mar 2009 00:47:53 +0100 [thread overview]
Message-ID: <20090324234753.GH22695@cs.unibo.it> (raw)
In-Reply-To: <20090316074520.GC3360@hack>
> I just finished reading all of them. Good work! :)
> Thanks. Comments below.
I am thanking you, not viceversa!
>
> Why not introduce a new request for PTRACE_VM but use *tags* in 'addr'?
> We are taking risks of breaking the existing code. :)
Yes, there is a minimal risk to break some code. This is a con.
On the other side there are two main pros for this proposal:
1- the code is now extremely simple
2- if we define a different tag for syscall (e.g. PTRACE_VM), we need also
different tags for PTRACE_VM_SINGLESTEP, PTRACE_VM_SINGLEBLOCK and maybe
others in the future.
Using the addr field we don't need this multiplication of tags
(and we could soon delete PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP).
> My question is if there are any other usages of SYSEMU beyond UML?
At this time I have not find any other usage.
>
> Well, since 'addr' is said to be unused, it can have any value beyond
> 0 or 1, we are still having the risks of breaking existing code. :(
True.
>
> >This change would eventually simplify both the kernel code
> >(reducing tags and exceptions) and even user-mode linux and umview.
> >
I forgot to change this sentence
> >The skip-exit feature can be implemented in a arch-independent
> >manner, while for skip_call some simple changes are needed
> >(the entry assembly code should process the return value of the syscall
> >tracing function call, like in arch/x86/kernel/Entry_32.S).
Both features are now arch independent after McGrath work on tracing hooks.
>
> BTW, please always update the corresponding man pages when you change
> any syscall interface. So let's Cc Michael Kerrisk.
You are right, I'll patch the man page as soon as possible.
renzo
next prev parent reply other threads:[~2009-03-24 23:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090204080236.GA17452@cs.unibo.it>
2009-03-10 21:44 ` [PATCH 0/2] ptrace_vm: ptrace for syscall emulation virtual machines Renzo Davoli
2009-03-13 7:42 ` Américo Wang
2009-03-16 7:45 ` Américo Wang
2009-03-24 23:47 ` Renzo Davoli [this message]
2009-03-29 16:32 ` [uml-devel] " Américo Wang
2009-04-04 10:17 ` Renzo Davoli
2009-04-07 17:36 ` Américo Wang
2009-04-08 12:18 ` Renzo Davoli
2009-04-13 16:36 ` Américo Wang
2009-04-17 8:18 ` Américo Wang
2009-04-25 9:19 ` Renzo Davoli
2009-04-30 8:27 ` Américo Wang
2009-05-18 9:45 ` [uml-devel] " Amerigo Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090324234753.GH22695@cs.unibo.it \
--to=renzo@cs.unibo.it \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=roland@redhat.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox