From: Pedro Alves <pedro@codesourcery.com>
To: Pavel Emelyanov <xemul@parallels.com>
Cc: Tejun Heo <tj@kernel.org>, Oleg Nesterov <oleg@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alan Cox <alan@linux.intel.com>,
Roland McGrath <roland@hack.frob.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Cyrill Gorcunov <gorcunov@openvz.org>,
James Bottomley <jbottomley@parallels.com>
Subject: Re: [RFC][PATCH 0/3] fork: Add the ability to create tasks with given pids
Date: Tue, 22 Nov 2011 12:04:38 +0000 [thread overview]
Message-ID: <201111221204.39235.pedro@codesourcery.com> (raw)
In-Reply-To: <4ECB8346.8040806@parallels.com>
On Tuesday 22 November 2011 11:11:02, Pavel Emelyanov wrote:
> > Can't we for now allow this for root and then later allow CAP_CHECKPOINT
> > that Cyrill suggested? Or do we want to allow setting pids even w/o CR
> > for NS creator?
>
> I think that systemd guys can play with it. E.g. respawning daemons with predefined
> pids sounds like an interesting thing to play with.
This whole userspace C/R stuff and being able to set the child's pid has potential
of being very useful for GDB too, allowing a much better reimplementation of its
old checkpointing feature [*], and allowing for a faster reverse debugging
implementation, by being able to do faster rewinding -- restore snapshot and replay
instructions up to N (by single stepping or running to breakpoint), rather than
manually undoing the effects of each instruction, one by one.
IOW, root only would be a shame from GDB's perspective.
[*] GDB has an old checkpointing feature ("checkpoint; info checkpoints" commands)
based on forcing the tracee to fork, and holding on the fork child behind the
scenes as a checkpoint. To restore the debugging state to a previous checkpoint,
gdb swaps the current debuggee for the fork child as transparently for the user
as was possible. Obviously this has a bunch of limitations and downsides like
only working on non-threaded programs, and the inferior's pid changing...
--
Pedro Alves
next prev parent reply other threads:[~2011-11-22 12:04 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-17 11:41 [RFC][PATCH 0/3] fork: Add the ability to create tasks with given pids Pavel Emelyanov
2011-11-17 11:42 ` [PATCH 1/3] pids: Make alloc_pid return error Pavel Emelyanov
2011-11-17 11:42 ` [PATCH 2/3] pids: Split alloc_pidmap into parts Pavel Emelyanov
2011-11-17 11:43 ` [PATCH 3/3] pids: Make it possible to clone tasks with given pids Pavel Emelyanov
2011-11-17 15:32 ` Oleg Nesterov
2011-11-17 15:49 ` Pavel Emelyanov
2011-11-17 16:00 ` Oleg Nesterov
2011-11-17 17:28 ` Linus Torvalds
2011-11-17 19:04 ` Oleg Nesterov
2011-11-17 18:36 ` Oleg Nesterov
2011-11-18 10:05 ` Pavel Emelyanov
2011-11-17 15:49 ` [RFC][PATCH 0/3] fork: Add the ability to create " Oleg Nesterov
2011-11-17 16:01 ` Pavel Emelyanov
2011-11-17 16:02 ` Oleg Nesterov
2011-11-18 23:30 ` Tejun Heo
2011-11-21 9:15 ` Pavel Emelyanov
2011-11-21 22:50 ` Tejun Heo
2011-11-22 11:11 ` Pavel Emelyanov
2011-11-22 12:04 ` Pedro Alves [this message]
2011-11-22 15:33 ` Tejun Heo
2011-11-23 16:20 ` Pedro Alves
2011-11-23 16:24 ` Tejun Heo
2011-11-23 17:26 ` Oleg Nesterov
2011-11-23 17:37 ` Tejun Heo
2011-11-23 18:19 ` Pavel Emelyanov
2011-11-23 20:14 ` Pavel Emelyanov
2011-11-24 17:31 ` Oleg Nesterov
2011-11-25 10:14 ` Pavel Emelyanov
2011-11-25 16:22 ` Oleg Nesterov
2011-11-25 16:44 ` Pavel Emelyanov
2011-11-25 16:54 ` Oleg Nesterov
2011-11-25 17:03 ` Pavel Emelyanov
2011-11-25 22:36 ` Pedro Alves
2011-11-27 16:24 ` [RFC][PATCH 0/3] fork: Add the ability to create tasks with?given pids Oleg Nesterov
2011-11-27 9:41 ` [RFC][PATCH 0/3] fork: Add the ability to create tasks with given pids Konstantin Khlebnikov
2011-11-27 17:34 ` Oleg Nesterov
2011-11-27 18:47 ` Tejun Heo
2011-11-28 10:38 ` Pavel Emelyanov
2011-11-28 16:25 ` Tejun Heo
2011-11-22 15:23 ` Tejun Heo
2011-11-22 15:29 ` Tejun Heo
2011-11-22 16:30 ` Pavel Emelyanov
2011-11-22 16:44 ` Linus Torvalds
2011-11-22 19:29 ` Pavel Emelyanov
2012-01-26 23:28 ` Kay Sievers
2011-11-22 21:16 ` Oleg Nesterov
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=201111221204.39235.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=akpm@linux-foundation.org \
--cc=alan@linux.intel.com \
--cc=gorcunov@openvz.org \
--cc=jbottomley@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=roland@hack.frob.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=xemul@parallels.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.