On 06/21, Roland McGrath wrote:
OK, so here's my (hacky) idea:
(1) Forget ptrace-via-utrace. Have utrace be a separate thing. This
way the recent ptrace changes won't matter.
This is what V2 does.
(2) But, what about ptrace co-existing well with utrace? Make them
mutually exclusive
On 06/21/2011 10:25 AM, Oleg Nesterov wrote:
OK, I won't argue. So we need to rework utrace/ptrace in 3.0, then we
should do this again in 3.1. I'll try to do something.
I have a thought here, I'm not familiar enough with utrace internals to
know whether it is a good one or not.
Originally,
OK, so here's my (hacky) idea:
(1) Forget ptrace-via-utrace. Have utrace be a separate thing. This
way the recent ptrace changes won't matter.
(2) But, what about ptrace co-existing well with utrace? Make them
mutually exclusive - a ptraced-process can't be utraced and a
utraced-process
On Tue, Jun 21, 2011 at 05:25:19PM +0200, Oleg Nesterov wrote:
I understand. Once again, it was supposed to be a temporary solution
until fedora switches to 3.1. And the reverted code does not make the
real difference so far, the user-visible changes are minor.
Yeah, I understand, it just
Temporary revert the following patches to keep utrace/utrace-ptrace working:
40ae717d1e78d982bd469b2013a4cbf4ec1ca434
ptrace: fix signal-wait_chldexit usage in
task_clear_group_stop_trapping()
321fb561971ba0f10ce18c0f8a4b9fbfc7cef4b9
ptrace: ptrace_check_attach()
On 06/20, Kyle McMartin wrote:
On Mon, Jun 20, 2011 at 06:07:44PM +0200, Oleg Nesterov wrote:
Temporary revert the following patches to keep utrace/utrace-ptrace working:
huge list of patches here
This obviously reverts some user-visible fixes, but the fixed problems
are very old and
On Mon, Jun 20, 2011 at 12:16:34PM -0400, Kyle McMartin wrote:
On Mon, Jun 20, 2011 at 06:07:44PM +0200, Oleg Nesterov wrote:
Temporary revert the following patches to keep utrace/utrace-ptrace
working:
huge list of patches here
This obviously reverts some user-visible
On 06/20/2011 09:44 AM, Dave Jones wrote:
What benefit is there in continuing to carry this thing at all ?
Utrace has been an absolute disaster from a merging standpoint.
Even Xen didn't take this long to get upstream.
I can't dispute the upstream disappointment, but the obvious benefit is
On Mon, Jun 20, 2011 at 10:18:26AM -0700, Josh Stone wrote:
On 06/20/2011 09:44 AM, Dave Jones wrote:
What benefit is there in continuing to carry this thing at all ?
Utrace has been an absolute disaster from a merging standpoint.
Even Xen didn't take this long to get upstream.
I
On 06/20/2011 10:28 AM, Dave Jones wrote:
On Mon, Jun 20, 2011 at 10:18:26AM -0700, Josh Stone wrote:
On 06/20/2011 09:44 AM, Dave Jones wrote:
What benefit is there in continuing to carry this thing at all ?
Utrace has been an absolute disaster from a merging standpoint.
Even Xen
On Mon, Jun 20, 2011 at 10:43:55AM -0700, Josh Stone wrote:
Packagers are adding these markers of their own accord, and in most
cases are getting them upstream as well. It is only kernel developers
who are so hostile/apathetic/etc.
We only deviate from the upstream kernel to fix bugs,
11 matches
Mail list logo
