On Thu, Apr 30, 2009 at 04:27:11PM +0800, Américo Wang wrote:
>On Sat, Apr 25, 2009 at 11:19:28AM +0200, Renzo Davoli wrote:
>
>>
>>I have successfully tested my paches in various configurations:
>>- patched-kernel running patched-UML
>>- patched-kernel running unpatched-UML
>>- patched-kernel runn
On Sat, Apr 25, 2009 at 11:19:28AM +0200, Renzo Davoli wrote:
>
>UML on UML stopped working long time ago, I wrote a note on it
>on March 8. See:
>http://article.gmane.org/gmane.linux.uml.devel/12085
>Here I am having the same behavior with and without my patches, thus
>(in my opinion) the bug is n
On Fri, Apr 17, 2009 at 04:18:23PM +0800, Am??rico Wang wrote:
> On Tue, Apr 14, 2009 at 12:36:03AM +0800, Américo Wang wrote:
> >Anyway, I will test your patch tomorrow, and will send you more
> >feedbacks soon.
>
> Sorry for the delay.
Me, too!
UML on UML stopped working long time ago, I wrote
On Tue, Apr 14, 2009 at 12:36:03AM +0800, Américo Wang wrote:
>Anyway, I will test your patch tomorrow, and will send you more
>feedbacks soon.
>
Sorry for the delay.
I applied your 2 patches to linus-tree, compile and run, when I run
the same UML binary inside UML, I got:
Locating the bottom of
On Wed, Apr 08, 2009 at 02:18:51PM +0200, Renzo Davoli wrote:
>> > #endif
>> > #ifdef PTRACE_SINGLEBLOCK
>> > case PTRACE_SINGLEBLOCK:
>> > #endif
>> > #ifdef PTRACE_SYSEMU
>> > case PTRACE_SYSEMU:
>> > case PTRACE_SYSEMU_SINGLESTEP:
>> > #endif
>> > case PTRACE_SYSCALL:
>> > case PTRACE_
> > #endif
> > #ifdef PTRACE_SINGLEBLOCK
> > case PTRACE_SINGLEBLOCK:
> > #endif
> > #ifdef PTRACE_SYSEMU
> > case PTRACE_SYSEMU:
> > case PTRACE_SYSEMU_SINGLESTEP:
> > #endif
> > case PTRACE_SYSCALL:
> > case PTRACE_CONT:
> > return ptrace_resume(child, request, 0, data);
> >+/* stat
On Sat, Apr 04, 2009 at 12:17:09PM +0200, Renzo Davoli wrote:
>Dear Cong,
>
>On Mon, Mar 30, 2009 at 12:32:28AM +0800, Américo Wang wrote:
>> On Wed, Mar 25, 2009 at 12:47:53AM +0100, Renzo Davoli wrote:
>> >1- the code is now extremely simple
>> Why adding a new request for ptrace is harder? I do
Dear Cong,
On Mon, Mar 30, 2009 at 12:32:28AM +0800, Américo Wang wrote:
> On Wed, Mar 25, 2009 at 12:47:53AM +0100, Renzo Davoli wrote:
> >1- the code is now extremely simple
> Why adding a new request for ptrace is harder? I don't think so. :)
> >2- if we define a different tag for syscall (e.g
On Wed, Mar 25, 2009 at 12:47:53AM +0100, Renzo Davoli wrote:
>> 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
> 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. Thi
On Tue, Mar 10, 2009 at 10:44:36PM +0100, Renzo Davoli wrote:
>Cong,
>
>I have updated the PTRACE_VM patches.
>The patches have been rebased to linux-2.6.29-rc7 but apply to
>linux-2.6.29-rc7-git3.
>
>The set is composed by two patches.
>The first one is for all those architectures where PTRACE_SY
On Tue, Mar 10, 2009 at 10:44:36PM +0100, Renzo Davoli wrote:
>Cong,
>
>I have updated the PTRACE_VM patches.
>The patches have been rebased to linux-2.6.29-rc7 but apply to
>linux-2.6.29-rc7-git3.
>
>The set is composed by two patches.
>The first one is for all those architectures where PTRACE_SY
Cong,
I have updated the PTRACE_VM patches.
The patches have been rebased to linux-2.6.29-rc7 but apply to
linux-2.6.29-rc7-git3.
The set is composed by two patches.
The first one is for all those architectures where PTRACE_SYSCALL is
managed via tracehook (x86, powerpc etc).
Given the wonderful
13 matches
Mail list logo
